Bug 486246

Summary: Failed initrd creation for 2.6.29-0.124.rc5.fc11.x86_64, nash fails to load libnash.so.6.0.77
Product: [Fedora] Fedora Reporter: Juliano F. Ravasi <bugs+fedora>
Component: mkinitrdAssignee: Peter Jones <pjones>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: hdegoede, katzj, pjones, wtogami
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-19 20:40:24 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
BROKEN initrd generated during first update
none
CORRECT initrd generated during second update
none
Log messages during both updates none

Description Juliano F. Ravasi 2009-02-19 00:31:36 UTC
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-19 00:35:06 UTC
Created attachment 332484 [details]
CORRECT initrd generated during second update

Comment 2 Juliano F. Ravasi 2009-02-19 00:36:25 UTC
Created attachment 332485 [details]
Log messages during both updates

Comment 3 Hans de Goede 2009-02-19 07:07:53 UTC
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 20:33:27 UTC
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 20:40:24 UTC
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.