Bugzilla – Bug 1000454
hardcoded devices in /etc/crypttab
Last modified: 2018-04-23 18:24:40 UTC
Created attachment 693643 [details]
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.
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
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
# cryptsetup luksUUID /dev/sda2
Closing as fixed (based on comment #1 and #7 but not comment #0).