Bug 1948063

Summary:	FC34 no longer booting from LUKS partition
Product:	[Fedora] Fedora	Reporter:	Niki Guldbrand <niki.guldbrand>
Component:	dracut	Assignee:	dracut-maint-list
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	34	CC:	dracut-maint-list, jonathan, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-04-11 06:59:44 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:

Description Niki Guldbrand 2021-04-09 22:03:23 UTC

Description of problem:

After rebooting in connection with an update to kernel 5.11.11-300.fc34 my system will no longer boot into the root fs (ext4) on a LVM volume which is located on a LUKS partition.

I have just updated to kernel 5.11.12-300.fc34, and the problem still persists, but 5.11.7-300-fc34 can still boot the system without issues, I missed the .8 to .10 kernel, so I can't give any status that time frame.

Both in the booting an none booting cases plymouth asks for the password to the partition, and proceeds, but in the non booting case the boot stops after finishing the cryptsetup job, and seems to be waiting for devices to show up, which might be LVM related

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


How reproducible:
Always


Steps to Reproduce:
1. Boot
2. Select a none booting kernel setup in grub
3. Enter password for partition when prompted
4. Booting stops

Actual results:
System will not boot

Expected results:
System will boot


Additional info:
This laptop was originally installed with F32, then updated to F33, and now for some months F34.

Comment 1 Niki Guldbrand 2021-04-11 06:59:22 UTC

Just updated dracut to 53-2, and rebuild the initrd images for 5.11.11-300 and 5.11.12-300 and both of them is now booting.

Comment 2 Niki Guldbrand 2021-04-11 06:59:44 UTC


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