Bug 1310520 - dracut fails to identify and populate /etc/crypttab with all necessary btrfs devices.
dracut fails to identify and populate /etc/crypttab with all necessary btrfs ...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dracut (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Lukáš Nykrýn
Release Test Team
Depends On:
Blocks: 1289485 1313485
  Show dependency treegraph
Reported: 2016-02-22 00:34 EST by Kyle
Modified: 2018-03-02 11:30 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1224499
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kyle 2016-02-22 00:34:45 EST
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):

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 11:23:36 EST
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.

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