Bug 486481
Summary: | kernel panic 2.6.27.15 /bin/nash error while loading shared libraries | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nivag <gavinflower> |
Component: | mkinitrd | Assignee: | Peter Jones <pjones> |
Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | low | ||
Version: | 10 | CC: | cebbert, hdegoede, katzj, kernel-maint, pjones, quintela, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-02-22 22:05:04 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: |
Description
Nivag
2009-02-19 23:00:09 UTC
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. |