Comment # 30 on bug 1051354 from Lee Martin

(In reply to Lee Martin from comment #26)

Following the proposal in comment #14, I reverted to the udev-228-32.2, rebuilt
and initrd and dropped into dracut at boot, so I did some checking.

dracut:
# ls -l /dev/disk/by-id/
lrwxrwxrwx 1 root 0    15 Aug 20 23:57 -20025385b61502108-part1 ->
../../nvme0n1p1
lrwxrwxrwx 1 root 0    15 Aug 20 23:57 -20025385b61502108-part2 ->
../../nvme0n1p2
lrwxrwxrwx 1 root 0    15 Aug 20 23:57 -20025385b61502108-part3 ->
../../nvme0n1p3
lrwxrwxrwx 1 root 0    13 Aug 20 23:57 nvme-20025385b61502108 -> ../../nvme0n1
lrwxrwxrwx 1 root 0    13 Aug 20 23:57
nvme-Samsung_SSD_960_PRO_2TB_S3EXNCAHB01257A -> ../../nvme0n1
lrwxrwxrwx 1 root 0    15 Aug 20 23:57
nvme-Samsung_SSD_960_PRO_2TB_S3EXNCAHB01257A-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root 0    15 Aug 20 23:57
nvme-Samsung_SSD_960_PRO_2TB_S3EXNCAHB01257A-part2 -> ../../nvme0n1p2
lrwxrwxrwx 1 root 0    15 Aug 20 23:57
nvme-Samsung_SSD_960_PRO_2TB_S3EXNCAHB01257A-part3 -> ../../nvme0n1p3
lrwxrwxrwx 1 root 0    13 Aug 20 23:57 nvme-eui.0025385b61502108 ->
../../nvme0n1
lrwxrwxrwx 1 root 0    15 Aug 20 23:57 nvme-eui.0025385b61502108-part1 ->
../../nvme0n1p1
lrwxrwxrwx 1 root 0    15 Aug 20 23:57 nvme-eui.0025385b61502108-part2 ->
../../nvme0n1p2
lrwxrwxrwx 1 root 0    15 Aug 20 23:57 nvme-eui.0025385b61502108-part3 ->
../../nvme0n1p3


My LVM partition is LUKS encrypted, and after upgrading to udev-228-32.2 I
never got the LUKS password entry, but instead the error described in this bug.

I only installed my 42.3 a few days ago using the initial udev-228-27.2 from
the ISO, which created the following /etc/crypttab:

 # cat /etc/crypttab
cr_-Samsung_SSD_960_PRO_2TB_S3EXNCAHB01257A-part3
/dev/disk/by-id/-Samsung_SSD_960_PRO_2TB_S3EXNCAHB01257A-part3 none       none


Now, if I compare that crypttab to the disk id's I see in dracut, I notice that
the device name is missing completely, well, more exactly, all the NVMe devices
now have an "nvme" prefix, whereas during install with udev-228-27.2 they
apparently did not have the "nvme" prefix.

So, now with a corrected crypttab and the standard udev-228-32.2 I'm fine. 

HOWEVER this indicates to me that this Leap 42.3 update around udev is changing
many device names at boot versus the ISO installation, so anything dependent on
specific device names (like LUKS) is at risk of not working after this update.
Therefore a fix of somekind is necessary since imagine LUKs setups to be
relatively common on the desktop.

Regarding LVM on a non-encrypted system, like Francois, I wondered if LVM maybe
has a fixed list of device names somewhere, and maybe the device name changes
in dracut are causing LVM some grief? For LVM, I came across
/etc/lvm/archive/*.vg which lists the LVM configuration, and guess what, there
is a physical_volumes section which contains specific device names.

Francois, maybe you want to check/list the device names you see in dracut with
different versions of udev, and then compare them with the LVM configuration
files I mention above. Since my LVM sites on top of LUKS, the physical volume
is the same, but assuming your device names at boot in dracut have now changed,
then that might explain why your VG is not activating automatically?

Richard, maybe you can also check your LVM config and dracut device names and
give feedback.

Hope that helps.
Lee