Bug 1310520

Summary:	dracut fails to identify and populate /etc/crypttab with all necessary btrfs devices.
Product:	Red Hat Enterprise Linux 7	Reporter:	Kyle <mr_hankeys8rd>
Component:	dracut	Assignee:	Lukáš Nykrýn <lnykryn>
Status:	CLOSED WONTFIX	QA Contact:	qe-baseos-daemons
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	7.4	CC:	dracut-maint-list, extras-qa, harald, jonathan, lmiksik, mbanas, zbyszek
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1224499	Environment:
Last Closed:	2020-12-15 07:40:14 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:
Bug Depends On:
Bug Blocks:	1289485, 1313485

Description Kyle 2016-02-22 05:34:45 UTC

Description of problem:
My root is on btrfs on luks. I recently added two spare drives using luks whole disk encryption to the btrfs and rebalanced to RAID1. I added the two new drives to crypttab. When I run dracut -f, only the first line of my crypttab is added to initramfs. Furthermore, dracut ignores a specific request to add the file directly (e.g. install_items+="/etc/crypttab"). On a positive note, it does refer to crypttab, as it picks up file edits (Bug #1224499).

Real crypttab:
9770 UUID=4d80beaf-e11e-4fbe-ac62-c67d9dcf270b
0972 UUID=ef7acfb9-5c0e-481e-90d6-f1c54a7e0802
5929 UUID=53291923-a9e5-4aef-97e5-ee59ff15f0a9

initramfs crypttab:
9770 UUID=4d80beaf-e11e-4fbe-ac62-c67d9dcf270b


Version-Release number of selected component (if applicable):
dracut-033-360.el7_2.x86_64

Additional info:
As I have seen suggested, I tried adding the devices to fstab:
UUID=09a56426-fb31-43ad-9daf-1912f234b939 /     btrfs   device=/dev/mapper/9770,device=/dev/mapper/0972,device=/dev/mapper/5929,subvol=root
Thankfully, that was not needed. Rather, it didn't prompt dracut to include the additional disks. Once the disks are unlocked the fs is recognized and the device= options are not needed to mount /.

Is there some magic spell that I need in order to get dracut to recognize that all of the disks are needed?


On a side note, it would have been extremely handy if dracut could add or remove files directly to/from an existing image (e.g. --inject). 
Currently, I have to edit the CMDLINE in grub and add rd.break=pre-mount. Then, open the disks manually and exit.


+++ This bug was initially created as a clone of Bug #1224499 +++

Comment 2 Kyle 2016-02-23 16:23:36 UTC

A few more things. I was slightly wrong about needing device= in /etc/fstab. As the ramdisk does not even have an fstab, it will find the btrfs as soon as all of the disks are decrypted, but after the switch, the disks need to be unlocked again, and without device=, the boot stalls. 

I've added rd.luks.uuid= declarations for the three drives to grub. No need to use rd.break, but of course I need to enter the password three times(actually 5, twice after the switch). I believe the reason only the two need to be unlocked is because the first is properly placed at /dev/mapper/9770. The other two are at /dev/mapper/luks-uuid. Easy fix, but is should not be a problem if /etc/crypttab were correct.

Removing rd.luks.uuid altogether does not work because /etc/crypttab is not complete. How does dracut determine which lines to pull from the real crypttab?

Also, I was not immediately aware of where the initial rd.luks.uuid was located. Does anaconda put this in /etc/default/grub? I would probably consider this a secondary bug that needs to be reconciled when adding luks devices to the root fs.

Comment 6 RHEL Program Management 2020-12-15 07:40:14 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.