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
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?
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>
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.
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?
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?
# 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.
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.
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.
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.
(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.