Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 1945596

Summary: Can't boot with initramfs generated by dracut-0.53
Product: [Fedora] Fedora Reporter: Viktor Ashirov <vashirov>
Component: dracutAssignee: dracut-maint-list
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 34CC: alexus_m, awilliam, bugzilla, dgilbert, dgilmore, dracut-maint-list, dsanzmor, edgar.hoch, hdegoede, jlayton, john, jonathan, kartochka378, kparal, marc.c.dionne, marc.cortinas, marko.m.kostic, robatino, scorreia, tom, yjog, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-04-07 20:54:58 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:
Bug Depends On:    
Bug Blocks: 1829024    
Description Flags
error on boot
dracut timeout scripts warnings
journal.log none

Description Viktor Ashirov 2021-04-01 11:15:13 UTC
Created attachment 1768240 [details]
error on boot

Description of problem:
After updating F33 to F34, and updating dracut to dracut-053-1.fc34, I can no longer boot using initramfs generated by that version of dracut.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Upgrade F33 with LUKS and LVM to F34
2. Update dracut to dracut-053-1.fc34
3. dracut -f

Actual results:
cryptsetup password prompt doesn't appear. 
See attached screenshot.

Expected results:
cryptsetup password prompt should appear.

Additional info:
Downgrading dracut to 051 and regenerating initramfs makes system bootable again.

Comment 1 Viktor Ashirov 2021-04-01 11:16:09 UTC
Created attachment 1768241 [details]
dracut timeout scripts warnings

Comment 2 Zbigniew Jędrzejewski-Szmek 2021-04-01 12:49:07 UTC
Yep, I saw this too. Downgrading to dracut-051-1.fc34.1.x86_64 "fixed" the issue.

Comment 3 kartochka378 2021-04-01 23:35:39 UTC
Same here, any update? Looked very scary at first time, more like "omg my box is brick now". I suspect trunk dracut already have fix for that boot:#boot substitution.

Comment 4 Chris Murphy 2021-04-02 19:31:04 UTC
Can you reproduce the problem, booting with parameters:

rd.debug rd.timeout=60 

and then extract a journal log:

journalctl -b -o short-monotonic --no-hostname > journal.log

and attach the log to this bug?

This sounds like it could be fixed by this commit: but we need logs to be sure.

Comment 5 Viktor Ashirov 2021-04-02 20:39:23 UTC
Created attachment 1768659 [details]

Please find the log attached.

Comment 6 Chris Murphy 2021-04-03 06:44:32 UTC
Could you edit the non-working GRUB menu entry, and remove the 'rhgb quiet' parameters? You should see text 'Please enter passphrase for disk luks...' and if you enter the luks passphrase there, does the system boot?

Comment 7 Viktor Ashirov 2021-04-03 08:23:36 UTC
I did remove them:
[    0.000000] kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.11.11-300.fc34.x86_64 root=UUID=73a56bc9-d6a9-428b-99c8-a5f7ef88b7f4 ro rd.luks.uuid=luks-f4a5c59c-b893-4b89-af80-20c2f4360103 rd.debug rd.timeout=60

But it doesn't get to that point where it asks for the passphrase.

I can prepare a VM image with the reproducer, if that helps.

Comment 8 Viktor Ashirov 2021-04-03 10:22:25 UTC
VM credentials: root/password
LUKS password: password


Comment 9 Chris Murphy 2021-04-04 02:12:10 UTC
This looks the same as bug 1945901. LVM LVs don't ever get activated, so the crypto devices don't appear and can be unlocked, so we end up at:

[   91.643732] systemd[1]: Dependency failed for Cryptography Setup for luks-f4a5c59c-b893-4b89-af80-20c2f4360103.

What I can't figure out in either case is why are the LV's not being activated? I've got a dracut 053 VM has the other layout possible LUKS->LVM and in that case it all works, so does LVM by itself. So yeah confused.

Comment 10 Chris Murphy 2021-04-04 02:20:10 UTC
If you get a chance and are willing to take the risk can you try making the changes in

And see if that fixes the problem? You would need to rebuild+replace the *bad* initramfs for this change to get incorporated.

Comment 11 Sergio Correia 2021-04-04 03:33:25 UTC
(In reply to Chris Murphy from comment #10)
> If you get a chance and are willing to take the risk can you try making the
> changes in
> 7fcc4955884355c3943d6c41e459b4b983a818f4

I tried a bisect between 51 and 53, and found as the first bad commit.
It wasn't trivial to just revert it because there were other changes, then I saw this your comment and after a quick check, it wasn't trivial to revert it either, due to it being on top of other changes not present in 053.

Then I checked the tip of the tree (, and it worked, so yeah, at least it's currently fixed, but we are not sure yet about what fixed it -- perhaps the commit you mentioned.
I then bisected again, now between 053 and the tip of the tree, and found this as the first bad (or good, in this case) commit: Fortunately it was now very simple to try it out hah :)

By the way, thanks Viktor for providing the VM. Applying the change in seems to resolve the issue for me.

Comment 12 Chris Murphy 2021-04-04 03:56:03 UTC
>Applying the change in seems to resolve the issue for me.

Same for me, and unexpected.

Comment 13 Chris Murphy 2021-04-04 04:07:42 UTC
See bug 1946074 which is specifically resulting in failure to boot following a clean install, and thus a final release blocker for Fedora 34.

I think the others  bug 1945901, bug 1945950, bug 1945530 are probably dups of bug 1945596 (this bug) but I'm just going to leave them alone for now and hopefully they get tagged with the eventual dracut that fixes this.

Comment 14 Viktor Ashirov 2021-04-04 07:02:49 UTC
(In reply to Chris Murphy from comment #12)
> >Applying the change in seems to resolve the issue for me.
> Same for me, and unexpected.

Can confirm too, it solves the issue for me, both on my laptop and VM.
I did a copr build for testing:

Thank you!

Comment 15 Tom Siewert 2021-04-04 08:08:40 UTC
*** Bug 1946002 has been marked as a duplicate of this bug. ***

Comment 16 Justin M. Forbes 2021-04-05 21:35:39 UTC
*** Bug 1946222 has been marked as a duplicate of this bug. ***

Comment 17 Dr. David Alan Gilbert 2021-04-06 08:23:06 UTC
*** Bug 1945530 has been marked as a duplicate of this bug. ***

Comment 18 Edgar Hoch 2021-04-06 17:58:26 UTC
I confirm that including your copr repo by including the line

repo --baseurl

into kickstart file for a fresh Fedora 34 nightly build 20210405 system solves the problem of hanging during boot with messages "running start job for .." both root and swap file systems.

I think this bug should be a blocker bug, or it should be related (or blocks?) bug 1946074 ?

Comment 19 Fedora Blocker Bugs Application 2021-04-07 05:27:34 UTC
Proposed as a Blocker for 34-final by Fedora user chrismurphy using the blocker tracking app because:

 Beta: For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed. 
* The upgraded system must meet all release criteria.

Post-install requirements
Expected installed system boot behavior

Fails all three bullets in this section because it doesn't boot, unless the user intervenes and a footnote in this section says "the boot should proceed without any unexpected user intervention"

This bug is the "upgrade" version of bug 1946074.

Comment 20 Kamil Páral 2021-04-07 05:50:56 UTC
> This bug is the "upgrade" version of bug 1946074.

Bug 1946074 is already an accepted blocker, shouldn't we just merge this to that one?

Comment 21 Chris Murphy 2021-04-07 06:09:47 UTC
Doesn't matter to me. It's the same basic bug, but the clean install bug is easier to reproduce which is why I created a fifth bug report :P

Comment 22 Justin M. Forbes 2021-04-07 14:33:34 UTC
*** Bug 1946989 has been marked as a duplicate of this bug. ***

Comment 23 Adam Williamson 2021-04-07 20:54:58 UTC
If it's the same bug with the same fix, let's use that.

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