I've installed Leap 42.3 on two relatively new systems. Both have the same problem. During installation, unencrypted /boot/efi and /boot partitions and an encrypted volume containing / and swap are created on a gpt disk. After installation, the kernel is 4.4.67. At this point, the system works. It will reboot, present the prompt to decrypt the disk, present the login prompt and all is well. Also after installation, an update to zypper and numerous subsequent updates are waiting. These take the kernel to 4.4.90. After that, it loses the ability to decrypt the LVM volume. It never presents the disk decryption password prompt. It simply spins through startup until it finally errors out because the root partition is unavailable. Dropping back to the older kernel at boot time does not fix the problem. Whatever has changed through the updates affects it also.

It does not matter if I disable UEFI and create a new MBR partition table on the disk. The installation boots and installs to MBR but the behavior is the same. The systems do need firmware updates for their Intel processors, but applying these separately before update does not help.

I have an older system without UEFI running Leap 42.2 installed in a similar way, with an encrypted volume. That one has been upgraded steadily and currently runs the 4.4.90 kernel successfully. Installing 42.2 on the newer systems does not help, however. They still to lose access to the encrypted volume after the first batch of updates.

I've looked through the startup messages, trying to find something helpful. I do see /dev/mapper/system-root presented as a kernel startup parameter. It just doesn't work.

openSUSE is the only LInux distribution that meets all of my requirements for a working laptop. If I can't make this work, I'm going to have to revert to Windows and work through all the problems that come with that. Any way I can avoid that will be most appreciated.