Created attachment 517667 [details]
dmesg output from failed boot
Description of problem:
This might be related to bug 726905, but the symptoms are different enough that I thought I would file a separate bug report.
I am including a dmesg report of the boot process since I got a shell prompt that allowed me to mount file systems despite the boot not succeeding.
The last part of dmesg output before I got the fallback shell prompt was:
[ 15.157398] dracut: luksOpen /dev/md13 luks-4c784093-1d94-4285-8178-206baee45
[ 16.426048] dracut: luksOpen /dev/md14 luks-ab1ed7c7-d153-4d85-aff7-b852dfc93
[ 40.139326] dracut Warning: No root device "block:/dev/mapper/4c784093-1d94-4
I have used the 2.6.40-4.fc15 and 220.127.116.11-2.fc15 kernels successfully on another f15 machine with a similar raid set up using version 0.90 arrays without a problem.
Version-Release number of selected component (if applicable):
The problem happens every boot on the affected machine.
Steps to Reproduce:
I was seeing some script errors reported on kernel updates, that I had forgotten about and the problem may really be related to that. I am currently running kernel-18.104.22.168-34.fc15.x86_64, but I thought there were some kernels after that one, but predating the 2.6.40 kernels that I also have trouble with. So this may be a case where I or a test update have put my system into a bad state.
I just did a reinstall and am still getting the scripting error that I was seeing before I went on vacation and forgot about. So this is alomost certainly something that broken on my machine and not a general problem. So I'll just close this one, though I may add a note later after I figure out what needed fixing.
Installing : kernel-22.214.171.124-2.fc15.x86_64 1/1
Non-fatal <unknown> scriptlet failure in rpm package kernel-126.96.36.199-2.fc15.x86_64
warning: (null) scriptlet failed, exit status 1
I tracked down the problem and it was user error. At some point I manually fixed up my grub.conf and managed to leave out 'luks-' from the root device name and that bad configuration was copied forward as I updated kernels.
Fixing the entry and rerunning the update script to write the initramfs fixed the problem.