Bug 1945596 - Can't boot with initramfs generated by dracut-0.53
Summary: Can't boot with initramfs generated by dracut-0.53
Status: CLOSED DUPLICATE of bug 1946074
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 34
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
: 1945530 1946002 1946222 1946989 (view as bug list)
Depends On:
Blocks: F34FinalBlocker
TreeView+ depends on / blocked
Reported: 2021-04-01 11:15 UTC by Viktor Ashirov
Modified: 2021-04-07 21:11 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-04-07 20:54:58 UTC
Type: Bug

Attachments (Terms of Use)
error on boot (10.83 KB, image/png)
2021-04-01 11:15 UTC, Viktor Ashirov
no flags Details
dracut timeout scripts warnings (49.17 KB, image/png)
2021-04-01 11:16 UTC, Viktor Ashirov
no flags Details
journal.log (911.53 KB, text/plain)
2021-04-02 20:39 UTC, Viktor Ashirov
no flags Details

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: https://github.com/dracutdevs/dracut/commit/7fcc4955884355c3943d6c41e459b4b983a818f4 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.lvm.lv=fedora_localhost-live/root 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
> https://github.com/dracutdevs/dracut/commit/
> 7fcc4955884355c3943d6c41e459b4b983a818f4

I tried a bisect between 51 and 53, and found https://github.com/dracutdevs/dracut/commit/c17c5b7604c8d61dd1c00ee22d44c3a5d7d6dfee 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 (https://github.com/dracutdevs/dracut/commit/2d83bce21bfc874b29c1fb99e8fabb843f038725), 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: https://github.com/dracutdevs/dracut/commit/ba4bcf5f4f11ad624c647ddf4f566997186135e7. Fortunately it was now very simple to try it out hah :)

By the way, thanks Viktor for providing the VM. Applying the change in https://github.com/dracutdevs/dracut/commit/ba4bcf5f4f11ad624c647ddf4f566997186135e7 seems to resolve the issue for me.

Comment 12 Chris Murphy 2021-04-04 03:56:03 UTC
>Applying the change in https://github.com/dracutdevs/dracut/commit/ba4bcf5f4f11ad624c647ddf4f566997186135e7 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 https://github.com/dracutdevs/dracut/commit/ba4bcf5f4f11ad624c647ddf4f566997186135e7 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: https://copr.fedorainfracloud.org/coprs/vashirov/dracut-bz1945596/

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 --name=copr:copr.fedorainfracloud.org:vashirov:dracut-bz1945596 --baseurl https://download.copr.fedorainfracloud.org/results/vashirov/dracut-bz1945596/fedora-34-x86_64/

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 ***

Note You need to log in before you can comment on or make changes to this bug.