Bugzilla – Bug 1000454
hardcoded devices in /etc/crypttab
Last modified: 2018-04-23 18:24:40 UTC
Created attachment 693643 [details] dracut log The BIOS on that device is somewhat difficult so I took a disk, installed system on the disk in KVM, verified the disk boots in KVM, put disk in device. The system does not boot. Report attached. Examining the logs a bit it seems the disk is accessible but the LVM volumes are not assembled.
this turns out to be due to hardcoded devices in /etc/crypttab
On one laptop here I have a crypttab with /dev/disk/by-id/ata-...-part6 yes, that is specific to a certain disk, but flexible enough to still work when you swap cables of sda and sdb. How else should it find its partition?
By the LUKS UUID. I have that in mind for YaST storage-ng.
(In reply to Arvin Schnell from comment #3) > By the LUKS UUID. I have that in mind for YaST storage-ng. System-changed /dev/by-id/ partitions during an OpenSuse 42.2 patch (!) update led to an unbootable system for me as /etc/crypttab still had old /dev/by-id/ entries. I have explained this and my fun with getting things working again in Bug 904987. Having the entries in /etc/crypttab by UUID instead would have easily avoided this. To fix the issue on my own system, I didn't bother with the UUID and instead used the direct partition number from /dev . Changing broken /dev/by-id entries to UUID in text-mode rescue shell is not practical for me.
Once management wanted to use by-id. I see this now as a feature request to use the LUKS UUID instead.
Just saw that a patch was released for the /dev/by-id/ issue in related Bug 1048679. That patch fixes the /dev/by-id/ renaming issue by restoring the original /dev/by-id/ names. While the patch fixes the specific bug, it does not really address the root cause, that the /dev/by-id/ naming is volatile. For the options of referring to encrypted devices in /etc/crypttab, I really think that /dev/by-id/ is the least preferable choice. /dev/by-uuid/ is unique and not volatile to hardware enumeration bugs/naming changes. Other Linux distributions use the LUKS UUID in /etc/crypttab as their default (see e.g. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/apcs04s06.html)
storage-ng uses the LUKS UUID in /etc/crypttab. Here is the configuration from a new installation (standard encrypted LVM with Tumbleweed 2018-04-20): # cat /etc/crypttab cr_sda2 UUID=b28a758c-3d7f-47ba-9d27-ea407fdf3e1a # cryptsetup luksUUID /dev/sda2 b28a758c-3d7f-47ba-9d27-ea407fdf3e1a Closing as fixed (based on comment #1 and #7 but not comment #0).