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.
Created attachment 332484 [details] CORRECT initrd generated during second update
Created attachment 332485 [details] Log messages during both updates
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.
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.
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.