Bug 2227983 - encrypted root fs not mounted on /sysroot before pivot
Summary: encrypted root fs not mounted on /sysroot before pivot
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-08-01 04:23 UTC by Bruno Wolff III
Modified: 2023-08-09 01:31 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-09 01:31:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Bruno Wolff III 2023-08-01 04:23:48 UTC
The pivot-root operation fails because nothing is mounted on /sysroot. I can still boot vmlinuz-6.5.0-0.rc2.20230721gitf7e3a1bafdea.20.fc39.x86_64, but I'm not sure exactly when things broke. I didn't see anything that indicated a mount attempt on /sysroot failing, but it might not be obvious if "sysroot" wasn't part of a message indicating the failure.

Reproducible: Always

Steps to Reproduce:
1. Boot recently created boot entry.
2.
3.

Comment 1 Bruno Wolff III 2023-08-01 13:50:48 UTC
I downgraded to 59-8 and reinstalled the latest kernel and that didn't fix things. So likely the change that broke things is not in dracut itself.

Comment 2 Bruno Wolff III 2023-08-01 14:54:37 UTC
I tried downgrading systemd (including systemd-udev) to 254~rc2-4.fc39 and reinstalling the latest kernel and that didn't fix things.

Comment 3 Bruno Wolff III 2023-08-01 15:19:35 UTC
I tried downgrading the kernel to kernel-core-6.5.0-0.rc2.20230719gitccff6d117d8d.18.fc39.x86_64 and that didn't fix the problem.

Comment 4 Bruno Wolff III 2023-08-08 20:52:53 UTC
I just upgraded another system from before the mass rebuild, that I was holding back for issues to get cleared up. It does not have a problem booting. While the hardware is different, I suspect something that bollixed up in one of the intermediate updates and isn't getting fixed by further updates. I'm going pursue that line of investigation. For now, there probably isn't much you guys can do unless you hear about someone else running into this who figured out how to fix it.

Comment 5 Bruno Wolff III 2023-08-09 01:31:56 UTC
This was caused by /etc/default/grub having a bad kernel line. I think it got messed up when I was playing around trying to figure out why kernel updates were failing around the time of the mass rebuild. I was confused when fixing it, because it looks like root= is supposed to go there, but in grubby the root= gets pulled out. So I ended up without root= being set in /etc/default because I just copied over what showed as args in grubby. Without root= there was no root filesystem to mount.


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