Red Hat Bugzilla – Bug 1310520
dracut fails to identify and populate /etc/crypttab with all necessary btrfs devices.
Last modified: 2017-08-21 04:34:03 EDT
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 +++
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.