Bug 1081841

Summary: Rawhide boots hanging (probably dependent on storage configuration)
Product: [Fedora] Fedora Reporter: Bruno Wolff III <bruno>
Component: dracutAssignee: dracut-maint-list
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: awilliam, bruno, dracut-maint-list, harald, jcarpenter, jonathan, vpvainio
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-17 17:53:20 UTC Type: Bug
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
log information
none
dmesg output
none
journalctl output
none
Logs from x86_64 machine
none
dmesg output for x86_64
none
journalctl output for x86_64 none

Description Bruno Wolff III 2014-03-28 04:38:06 UTC
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:

Comment 1 Bruno Wolff III 2014-03-28 04:38:47 UTC
Created attachment 879740 [details]
dmesg output

Comment 2 Bruno Wolff III 2014-03-28 04:39:39 UTC
Created attachment 879741 [details]
journalctl output

Comment 3 Bruno Wolff III 2014-03-28 04:40:58 UTC
I'm also seeing the same issue on an x86_64 machine with a similar setup.

Comment 4 Bruno Wolff III 2014-03-28 18:19:49 UTC
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.

Comment 5 Bruno Wolff III 2014-03-28 18:20:28 UTC
Created attachment 879981 [details]
dmesg output for x86_64

Comment 6 Bruno Wolff III 2014-03-28 18:21:15 UTC
Created attachment 879982 [details]
journalctl output for x86_64

Comment 7 Bruno Wolff III 2014-03-28 19:18:47 UTC
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.

Comment 8 Harald Hoyer 2014-04-01 06:43:10 UTC
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

Comment 9 Bruno Wolff III 2014-04-01 14:25:16 UTC
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?

Comment 10 Harald Hoyer 2014-04-01 15:38:53 UTC
(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).

Comment 11 Adam Williamson 2014-04-17 17:24:53 UTC
This is the same as https://bugzilla.redhat.com/show_bug.cgi?id=1084766 , right?

Comment 12 Adam Williamson 2014-04-17 17:53:20 UTC

*** This bug has been marked as a duplicate of bug 1084766 ***

Comment 13 Bruno Wolff III 2014-04-17 19:12:59 UTC
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.

Comment 14 Adam Williamson 2014-04-18 04:55:53 UTC
frankly, I'd say it's a bug in both, having looked at the code. see the other bug.