Bug 2227983

Summary:	encrypted root fs not mounted on /sysroot before pivot
Product:	[Fedora] Fedora	Reporter:	Bruno Wolff III <bruno>
Component:	dracut	Assignee:	dracut-maint-list
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	bruno, dracut-maint-list, jamacku, lnykryn, pvalena
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-08-09 01:31:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.