Bug 486246 - Failed initrd creation for 2.6.29-0.124.rc5.fc11.x86_64, nash fails to load libnash.so.6.0.77
Failed initrd creation for 2.6.29-0.124.rc5.fc11.x86_64, nash fails to load l...
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2009-02-18 19:31 EST by Juliano F. Ravasi
Modified: 2009-02-19 15:40 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-19 15:40:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
BROKEN initrd generated during first update (2.88 MB, application/octet-stream)
2009-02-18 19:31 EST, Juliano F. Ravasi
no flags Details
CORRECT initrd generated during second update (3.40 MB, application/octet-stream)
2009-02-18 19:35 EST, Juliano F. Ravasi
no flags Details
Log messages during both updates (7.15 KB, text/plain)
2009-02-18 19:36 EST, Juliano F. Ravasi
no flags Details

  None (edit)
Description Juliano F. Ravasi 2009-02-18 19:31:36 EST
Created attachment 332483 [details]
BROKEN initrd generated during first update

When updading to 2.6.29-0.124.rc5.fc11.x86_64, mkinitrd created a broken initrd, that failed to load /bin/nash during boot time ("error load shared library 
libnash.so.6.0.77" or something).

After removing the kernel and reinstalling (through the exact same procedure), the new initrd is ok and boots correctly.

Attached are the broken and the correct initrds, and log messages from both updates.
Comment 1 Juliano F. Ravasi 2009-02-18 19:35:06 EST
Created attachment 332484 [details]
CORRECT initrd generated during second update
Comment 2 Juliano F. Ravasi 2009-02-18 19:36:25 EST
Created attachment 332485 [details]
Log messages during both updates
Comment 3 Hans de Goede 2009-02-19 02:07:53 EST
Judging from the messages you attached you were hitting an selinux problem during the first time you installed the kernel, this issue has somehow sorted itself out (relabel at reboot perhaps?)

In any case this was not an mkinitrd issue, closing.
Comment 4 Juliano F. Ravasi 2009-02-19 15:33:27 EST
Sorry, I can't agree.

Mkinitrd fails to create a proper initrd; no idea what was the real error, but it was not signaled and the kernel rpm installation simply succeeded. The user ends up with an non-bootable system as a result, needs special procedure to repair (and emphasis on "special", since GRUB is shipping with timeout=0, making it difficult to select a different kernel) and that is not a bug?

There is clearly a problem somewhere. Either mkinitrd should have succeeded in creating the initrd for the first time, or it should have detected the problem and properly signaled that the kernel rpm failed. It is extremely user-unfriendly situation that should be investigated before it hits real users in the final release.

If the problem is not with mkinitrd, but with selinux, then the bug should be reassigned and then investigated, so no other users are harmed in the same situation in the future. Instead, no effort was even considered in trying to understand what happened.
Comment 5 Hans de Goede 2009-02-19 15:40:24 EST
Considering that the problem was gone a second run of mkinitrd, the selinux problem whatever it was is clearly fixed now. So there is no use in re-assigning this to selinux, as you can no longer reproduce this.

If you see this a second time with the next kernel update I'll gladly investigate this, until that time: Welcome to rawhide.

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