|
Bugzilla – Full Text Bug Listing |
| Summary: | hardcoded devices in /etc/crypttab | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Michal Suchanek <msuchanek> |
| Component: | Basesystem | Assignee: | YaST Team <yast-internal> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Enhancement | ||
| Priority: | P4 - Low | CC: | aschnell, bwiedemann, coolo, forgotten_j1laPII4MP, lnussel |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| URL: | https://trello.com/c/6GTME5aS/1617-tumbleweed-1000454-hardcoded-devices-in-etc-crypttab | ||
| See Also: | http://bugzilla.opensuse.org/show_bug.cgi?id=904987 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | dracut log | ||
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). |
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.