RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1310520 - dracut fails to identify and populate /etc/crypttab with all necessary btrfs devices.
Summary: dracut fails to identify and populate /etc/crypttab with all necessary btrfs ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dracut
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1289485 1313485
TreeView+ depends on / blocked
 
Reported: 2016-02-22 05:34 UTC by Kyle
Modified: 2020-12-15 07:40 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1224499
Environment:
Last Closed: 2020-12-15 07:40:14 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.