Bug 486481 - kernel panic 2.6.27.15 /bin/nash error while loading shared libraries
kernel panic 2.6.27.15 /bin/nash error while loading shared libraries
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
10
x86_64 Linux
low Severity urgent
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-19 18:00 EST by Nivag
Modified: 2009-02-22 17:05 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-22 17:05:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nivag 2009-02-19 18:00:09 EST
Description of problem:
Update to latest kernel via yum.
Rebooted
selected kernel 2.6.27.15 from menu
Immediately after the message 
    "Write protecting the kernel read-only data:4748k"
got the following lines
    "/bin/nash: error while loading shared libraries: libnash.so.6.0.71: cannot open
    shared object file: No such file or directory
    Kernel panic - not syncing: attempted to kill init"

Note that I was able to successfully reboot into the previous kernel 2.6.27.12, and initiate this bug.

Version-Release number of selected component (if applicable):
kernel 2.6.27.15

How reproducible:
every time (tried 3 times)

Steps to Reproduce:
1.reboot
2.select kernel 2.6.27.15 from menu
3.
  
Actual results:
Kernel panic

Expected results:
Successful boot & user selection menu appears

Additional info:
AMD 4200+
4 Gig RAM
applied all updates offered by yum
Comment 1 Chuck Ebbert 2009-02-19 18:15:23 EST
The latest version of mkinitrd for Fedora 10 is 6.0.52. How did you get 6.0.71, or at least parts of it, installed?
Comment 2 Nivag 2009-02-19 19:10:43 EST
I did nothing explicit to install a new version of mkinitrd, I think it must have come as part of a regular yum update.

I did 
    grep mkinitrd /var/log/yum.log
and got:
    Jan 09 23:35:15 Updated: mkinitrd-6.0.71-3.fc10.x86_64
(I'm in New Zealand, which is currently 13 hours ahead of GMT.)

Is there a safe way to revert to 6.0.52, this is the main box in the house and the gateway to the Internet, so my life would not be worth living if I stuffed it up...  <worried grin>
Comment 3 Nivag 2009-02-19 19:32:20 EST
I note that 
    ftp://fedora.tu-chemnitz.de/pub/linux/fedora/linux/updates/10/x86_64/
has
    mkinitrd-6.0.71-3.fc10.x86_64.rpm. . . . . . Dec 22 19:28.


Also that
    ftp://fedora.tu-chemnitz.de/pub/linux/fedora/linux/releases/10/Fedora/x86_64/os/Packages
has
    mkinitrd-6.0.71-2.fc10.x86_64.rpm. . . . . . . . . . . . . . . . Nov 12 23:34 


I don't know which mirror yum used originally.
Comment 4 Chuck Ebbert 2009-02-20 02:01:10 EST
Sorry, I must have been looking at Fedora 9... I think this is a bug in mkinitrd and/or nash?

Is the package nash-6.0.71-3 installed, and is the file 
/usr/lib64/libnash.so.6.0.71 on disk?
Comment 5 Hans de Goede 2009-02-20 02:41:21 EST
This feels very familiar to a same problem we've been seeing with libparted missing from the initrd.

Can you please do:
ls -l /lib64/libnash*
ls -l /usr/lib64/libnash*

And paste the output here?
Comment 6 Nivag 2009-02-20 03:23:32 EST
# ll /lib64/libnash*
ls: cannot access /lib64/libnash*: No such file or directory


# ll /usr/lib64/libnash*
-rwxr-xr-x 1 root root 125496 2008-12-09 07:44 /usr/lib64/libnash.so.6.0.71*


# alias ll
alias ll='ls -lF'


# locate libnash
/bulk/neptune-20090216-usr/usr/lib64/libnash.so.6.0.71
/usr/lib64/libnash.so.6.0.71


(/bulk/neptune-20090216-usr is a backup directory of my son's machine 'neptune', my machine is 'jupiter')

I installed Fedora 10 this year, and the only update is to mkinitrd-6.0.71-3, hence the Jan 09 date of the yum update log.
Comment 7 Hans de Goede 2009-02-22 09:22:32 EST
Nivag, can you try regenerating the trouble some mkinitrd like this:

KERNVER=2.6.27.15-####.x86_64
mkinitrd -f /boot/initrd-$(KERNVER).img $(KERNVER)

And thry booting the new kernel again? If that does not work can you try again with selinux out of the way:

setenforce 0
KERNVER=2.6.27.15-####.x86_64
mkinitrd -f /boot/initrd-$(KERNVER).img $(KERNVER)


Note that the #### in the KERNVER= line needs to be filled in by you, do an ls /boot to see what it should be.
Comment 8 Nivag 2009-02-22 14:50:04 EST
I used the following commands:

export KERNVER=-2.6.27.15-170.2.24.fc10.x86_64
mkinitrd -f /boot/initrd-$KERNVER.img $KERNVER

rebooted (shutdown -r now)
selected kernel 2.6.27.15
reboot halted after 
    Starting smartd
reran my NVidia driver creation procedure

rebooted
selected kernel 2.6.27.15
got into my GNOME session

I'm now typing this...


N.B. I had to remove the round brackets from 
   mkinitrd -f /boot/initrd-$(KERNVER).img $(KERNVER)
not sure if the 'export' was required, but it is my normal practice

Thanks!

Curious, this work around is new to me, why was it necessary this time?  I normally upgrade to the latest kernel from yum as soon as it is available.
Comment 9 Nivag 2009-02-22 14:57:12 EST
Note that I run with SELinux Disabled - had too many problems with it on my box.

So I can't comment on whether your selinux commands may be required in some situations.
Comment 10 Hans de Goede 2009-02-22 17:05:04 EST
(In reply to comment #8)
> I used the following commands:
> 
> Curious, this work around is new to me, why was it necessary this time?  I
> normally upgrade to the latest kernel from yum as soon as it is available.

Yes and that should work just fine, you hit some sort of glitch, what you did is *exactly* the same as what the kernels post install script does. Weird!

I'm going to close this, but I'll keep an eye out to similar bugs.

Note You need to log in before you can comment on or make changes to this bug.