Bug 804453

Summary: libfreebl3.[chk | so] in /usr/lib64 mis-linked to ../../
Product: [Fedora] Fedora Reporter: Kirk C Aune <kaune>
Component: nss-softoknAssignee: Elio Maldonado Batiz <emaldona>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: dennis, emaldona, kengert, me, oleg.kochkin, rrelyea, vascom2
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: nss-softokn-3.13.3-2.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-17 02:22:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Diffs from last released
none
Don't create symlinks to relative paths rrelyea: review+

Description Kirk C Aune 2012-03-18 21:50:08 UTC
Description of problem:


Version-Release number of selected component (if applicable):Fedora 16
Package nss-softokn-freebl  (Not in the list above)

How reproducible: The update caused the problem.  Manually placing the two files back in /usr/lib64 corrected the problem.  yum reinstall nss-softokn-freebl made the system inoperable again.  


Steps to Reproduce:
1.Apparently update the nss-softkn-freebl to the current latest
2.
3.
  
Actual results:  Using quiet rhgb, a boot stops forever.   With much time expended, I finally got the boot to be successful with a runlevel1.  Whereupon allowing it to go employing networking in level 3 or 5, it froze.  I finally isolated it to libfreebl3.so and libreebl3.chk which had softlinks pointing to the"ether".   By stealing the files from a Fedora 17 installation, all was well.

I believe the above package has an installation error in it and I assume blows everyone away.


Expected results:


Additional info:

Comment 1 Elio Maldonado Batiz 2012-03-19 15:49:57 UTC
Created attachment 571168 [details]
Diffs from last released

I did a git log that shows me
commit d71f1330f7d826afacfae2069ae1271f3dc701c4
Author: Elio Maldonado Batiz <emaldona>
Date:   Sat Mar 10 10:32:17 2012 -0800

    Update to NSS_3_13_3_RTM
    
    - Selective merge from f17 to skip /usrmove related changes
    - Don't install everything in /usr nor add filesystem guard
    - patch updated for rebase
    - nss-split-softokn script now copies crypto-only tests and support library

commit 6905191eff6b369976079ec29e3d95143e0e9f93
Merge: 50733a0 d63e2bc
Author: Elio Maldonado <emaldona>
Date:   Fri Dec 30 14:51:54 2011 -0800

    Merge branch 'master' into f16

commit d63e2bcec060be760e870391f96419e8163e6b2e
Author: Elio Maldonado <emaldona>
Date:   Fri Dec 30 14:40:31 2011 -0800

    - Bug 770999 - Fix segmentation violation when turning on fips mode

So I compared current versus last one before the merge with
git diff d63e2bcec060be760e870391f96419e8163e6b2e > \
git-diff-from-last-stable.patch
which I am attaching.

I don't see any changes in installation phase for nss-softokn.spec.

Comment 2 Elio Maldonado Batiz 2012-03-20 22:16:51 UTC
Now I see it. Things like
  ln -sf ../../%{_lib}/libfreebl3.so $RPM_BUILD_ROOT/%{_libdir}/libfreebl3.so
          ^^^^
are the cause of this problem. Odd that we didn't receive any reports earlier. On F17 and above with /usr/move that won't be an issue. I'll fix it for f16 and f15. Pproposed fix to the .spec file coming soon.

Comment 3 Elio Maldonado Batiz 2012-03-20 23:14:45 UTC
Created attachment 571561 [details]
Don't create symlinks to relative paths

Comment 4 Bob Relyea 2012-03-21 00:12:49 UTC
Comment on attachment 571561 [details]
Don't create symlinks to relative paths

r+ rrelyea

Comment 5 Fedora Update System 2012-03-21 01:27:32 UTC
nss-softokn-3.13.3-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/nss-softokn-3.13.3-2.fc16

Comment 6 Fedora Update System 2012-03-22 01:57:34 UTC
Package nss-softokn-3.13.3-2.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nss-softokn-3.13.3-2.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-4412/nss-softokn-3.13.3-2.fc16
then log in and leave karma (feedback).

Comment 7 Kirk C Aune 2012-03-22 19:44:45 UTC
I performed the suggested update per your suggestion.  That seemed to go just fine.  However, I believe my problem stems from the package "nss-softokn-freebl". I recognize that /lib64 is a symbolic pointer to /usr/lib64.   To be functioning I had placed copies of libfreebl3.[chk,so] in /usr/lib64.  Since your update did not change that situation, I decided to try the same command for the "nss-softokn-freebl" package with the exception that since the Fedora 17 (chk,so) files were in this Fedora 16 installation already, I did a yum reinstall --enablerepo... nss-softokn-freebl .

When I did that, instead of a pointer which points to the non-existent ../../lib64 ... , the two pointers in /usr/lib64 point to themselves but are non-existent.  In otherwords, there is a pointer in /usr/lib64 having the value:
libfreebl3.so -> /usr/lib64/libfreebl3.so    and similarly for the .chk file.

The existing files were deleted and replaced with the self-referential link.

Thank you for your efforts.   Is this problem stemming from /lib64 now pointing to /usr/lib64 ?   I noticed that /bin is now pointing to /usr/bin and /sbin is pointing to /usr/sbin also.   We old-time Unix users are wondering why these changes to fundamental Unix structures are occuring now??

Comment 8 Elio Maldonado Batiz 2012-03-22 21:24:19 UTC
(In reply to comment #7)
> I performed the suggested update per your suggestion.  That seemed to go just
> fine.  However, I believe my problem stems from the package
> "nss-softokn-freebl". I recognize that /lib64 is a symbolic pointer to
> /usr/lib64.   


Yes, but but only on f-17 and above. Things remain the same on f-16 and /lib64 is real. I just addressed the removal of relative paths the symbolic links had in their targets.


> To be functioning I had placed copies of libfreebl3.[chk,so] in
> /usr/lib64.  Since your update did not change that situation, 

No manual copying of files should be needed. 

> I decided to try
> the same command for the "nss-softokn-freebl" package with the exception that
> since the Fedora 17 (chk,so) files were in this Fedora 16 installation already,
> I did a yum reinstall --enablerepo... nss-softokn-freebl .

> 
> When I did that, instead of a pointer which points to the non-existent
> ../../lib64 ... , the two pointers in /usr/lib64 point to themselves but are
> non-existent.  In otherwords, there is a pointer in /usr/lib64 having the
> value: 
> libfreebl3.so -> /usr/lib64/libfreebl3.so    and similarly for the .chk file.
> 
> The existing files were deleted and replaced with the self-referential link.
> .....Is this problem stemming from /lib64 now pointing
> to /usr/lib64 ?   

No, that's on f-17 only and the nss-softokn.spec ahs been modified to account for this, thanks to the release engineering folks. I haven't seen this and I was looking for such problems when I learned about the usr/move changes and saw that the changes made to the spec file.

No manual intervention needed, nor recommended, on f16 nor on f17, 

> I noticed that /bin is now pointing to /usr/bin and /sbin is
> pointing to /usr/sbin also.   We old-time Unix users are wondering why these
> changes to fundamental Unix structures are occuring now??

I'll rather not get into the merits here, been discussed at length elsewhere :)
As I have been updating my f17 VM's many problems seem to have been sorted out.

Comment 9 Kirk C Aune 2012-03-22 22:47:43 UTC
Elio,
  Thank you for the explanations.  It would appear that I somehow stumbled onto a problem that although was not right, it was not severely affecting others and may have been particular to me only.  Nevertheless, it would seem such a correction needed to be made long-term.  Now that I understand what is happening with my system, I can go forward.  I have been maintaining the Fedora 16 and 17 alpha as separate bootable systems, but from your explanation, somehow my Fedora 16 structure found itself looking like 17 prematurely.  I am not aware of having done anything to cause that for I only yesterday noticed that symbolic links were now being used for those important directories in Fedora 17 and somehow in my Fedora 16.  I guess it is a good thing that 17 Beta is here soon and the final release in a little over a month.

  You have been very efficient and I thank you for all you do.  I have been a Linux user since Kernel 0.98 and I continue to be fascinated with the quality of support for such a useful system by people generally only connected by email and faceless conferences.

Best wishes

Comment 10 Oleg Kochkin 2012-04-20 11:59:36 UTC
Repeated bug in nss-softokn-freebl-3.13.4-1.fc16.x86_64.

Comment 11 Fedora End Of Life 2013-01-17 02:06:09 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping