Created attachment 879739 [details] log information Description of problem: The last initramfs image that boots for me is from 3.14.0-0.rc7.git1.2.fc21.i686+PAE. Later ones result in a hang part way through boot (before I get asked for luks passwords). It will eventually timeout, but the boot won't continue. Since I haven't seen lots of other people noticing this, I suspect it is related to my storage set up (ext4 on luks on md raid 1 for / and /home, no luks for /boot). Version-Release number of selected component (if applicable): dracut-037-3.git20140320.fc21 How reproducible: Happens every rawhide boot. (The same kernels work in F20.) Additional info:
Created attachment 879740 [details] dmesg output
Created attachment 879741 [details] journalctl output
I'm also seeing the same issue on an x86_64 machine with a similar setup.
Created attachment 879980 [details] Logs from x86_64 machine In order to help find a common pattern, I'm attaching info from my x86_64 machine to contrast with that from the i686 machine I already provided.
Created attachment 879981 [details] dmesg output for x86_64
Created attachment 879982 [details] journalctl output for x86_64
I downgraded to dracut-036-16.git20140206.fc21 and rebuilt an initramfs image that hadn't been working and it worked. This makes it seem pretty likely that it is a change in dracut that is triggering the problem.
Your kernel command line: ro root=/dev/mapper/luks-9a976b86-8aaa-40d9-8039-89d710eac5c9 SYSFONT=latarcyrheb-sun16 LANG=en_DK.UTF-8 KEYTABLE=us radeon.agpmode=-1 noreplace-smp slub_debug=- nmi_watchdog=2 enforcing=0 is missing the rd.luks.uuid=<LUKS-UUID> parameter. To see the required parameter, run: # dracut --print-cmdline
OK. That should let me fix things. There wasn't anything about this change in the change log that I saw, so it was hard for me to guess what I needed to do. Is this something that the kernel update script should be running so that people don't have to worry about the change? Does fedup handle this change?
(In reply to Bruno Wolff III from comment #9) > OK. That should let me fix things. There wasn't anything about this change > in the change log that I saw, so it was hard for me to guess what I needed > to do. > Is this something that the kernel update script should be running so that > people don't have to worry about the change? Does fedup handle this change? normally anaconda adds this to the kernel command line at installation time I am not sure, if I will remove the auto cmdline generation in dracut (current state) or, if I reintroduce it (F20 state).
This is the same as https://bugzilla.redhat.com/show_bug.cgi?id=1084766 , right?
*** This bug has been marked as a duplicate of bug 1084766 ***
Sort of. This one was filed against rawhide. However, it isn't clear that it is really a bug for rawhide, as much as it is a change. (Assuming that upgrades from earlier verions got handled somehiw.) However in f20 this would be a real bug since it causes problems for existing system.
frankly, I'd say it's a bug in both, having looked at the code. see the other bug.