Bug 1000454 - hardcoded devices in /etc/crypttab
hardcoded devices in /etc/crypttab
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
x86-64 Other
: P4 - Low : Enhancement (vote)
: ---
Assigned To: YaST Team
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2016-09-22 14:23 UTC by Michal Suchanek
Modified: 2018-04-23 18:24 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

dracut log (98.46 KB, text/plain)
2016-09-22 14:23 UTC, Michal Suchanek

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Suchanek 2016-09-22 14:23:48 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.
Comment 1 Michal Suchanek 2016-09-22 15:58:51 UTC
this turns out to be due to hardcoded devices in /etc/crypttab
Comment 2 Bernhard Wiedemann 2016-10-01 06:03:55 UTC
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?
Comment 3 Arvin Schnell 2016-10-01 11:24:13 UTC
By the LUKS UUID. I have that in mind for YaST storage-ng.
Comment 4 Chris Scheible 2017-07-26 01:22:05 UTC
(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.
Comment 7 Arvin Schnell 2017-07-26 12:11:04 UTC
Once management wanted to use by-id. I see this now as a feature
request to use the LUKS UUID instead.
Comment 8 Chris Scheible 2017-07-28 01:33:19 UTC
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)
Comment 9 Arvin Schnell 2018-04-23 18:24:40 UTC
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

Closing as fixed (based on comment #1 and #7 but not comment #0).