Boot freezes after encrypted volumes target after zypper up

I have a bit strange issue. I’ve build new machine with AMD Threadripper 1920 (not sure if it’s important) and I’m trying to install openSUSE Leap 15 on it. I’m creating boot partition with BTRFS and encrypted partition which I add to LVM and create swap and root in LVM. It installs, reboots and everything works fine, I’ve even tried several reboot and it works.
Then I do zypper up and reboot and after it it hangs after “Reached target Encrypted volumes”
When I do the install from network repositories, so everything is up to date immediately, it hangs after first boot. I’ve tried to not use LVM and have root and swap each on encrypted partition and it also hangs.
And also when setup finds this encrypted volume it asks for the password, but it doesn’t accept it and asks again and again. It looks like that something in update repo breaks the encrypted partition completely. Any idea what it can be?

And also tried to boot with previous kernel and it also hangs, so it doesn’t seem to be kernel issue.

And after some time this appears:

So another note. When I boot Kali Linux, I can unlock and see the content of the disk, so LUKS doesn’t seem to be broken. It’s something in the system.

I am only guessing here.

Possibility 1: There is a missing driver that is needed for you to be able to give encryption key.

I have had this happen, though not recently. I think it was back at Leap 42.1.

However, I don’t think this is your problem. When that happened to me, I did not get repeated prompts for password. The system just sat there waiting.

Possibility 2: The drivers are fine, but you are giving the wrong password for encryption. From what you describe, this sounds most likely.

There have been some bug reports about language encodings, though I have not closely followed those. So maybe the handling of language encodings has changed just enough that what you enter as password is now used with a different encoding from when you created it. So the password never matches.

How to test this: I suggest that you create a new password for your encrypted disk. And make sure that new password uses only basic characters that won’t change with whatever language encoding you use. And then see if that solves your problem.

If you still have the DVD install media or the NET install media, boot that into the rescue system. You should get a command line prompt where you can login as root (password not needed).

Then open your encrypted LVM at the command line:

cryptsetup luksOpen /dev/sdaX cr_sdaX

NOTE: change that “sdaX” to whatever is appropriate. The last parameter is just a symbolic name, and not important at this stage.

The main purpose of opening your LVM, is to make sure that the key you know does work. Because you will need that to work.

Next create a new key (an additional key)

cryptsetup luksAddKey /dev/sdaX

Use same device name that worked to open it. You should be prompted for a new key. And that’s where you carefully set a key that will avoid encoding problems.

Your encrypted LVM will now have two keys. In theory both should work. But currently one doesn’t work, so your hope is that the new one will work during future boots.

Good idea, but unfortunately it’s not it. I’ve tried to add very simple passwords and it’s still the same. What can be the issue with the drivers? I had repeated prompts only in setup, during boot it asks once and then hangs. What driver can be missing?

Try running

mkinitrd -A

You may have to boot from rescue system, unlock and mount disks (say at “/mnt”), then:

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

Then you can “chroot” into your system with

chroot /mnt

Hmm, if you are using “btrfs” then you also need to mount the subvolumes. I’m not using “btrfs” here. After the “chroot” you might try

mount -a

to see if that mounts the subvolumes.

And then run the “mkinitrd -A”. That is supposed to put all possible drivers into the “initrd”. If that works, then you will know that it is a driver problem.

mkinitrd -A

makes it even worse, it doesn’t even ask for luks password and tries to search for lvm directly.
I’ve also tried just



mkinitrd -f 'block dmraid dm iscsi kpartx luks lvm2 md multipath network usb vendor'

and and in both cases I’ve got 2 lines further to “reached target basic system” and it hanged afterwards.

Is your root on btrfs? Please boot without “quiet” and with “plymouth.enable=0” on kernel command line, this may give some more hints where it hangs. With btrfs it is possible that it starts some jobs when it is mounted, it may give appearance that it “hung”.

Yes, I’m on btrfs, but it’s not doing anything, disk is not blinking. I’ve booted with splash=verbose and there was no message after “reached target basic system”, only after long time (more then 10 minutes) there was something like this again. There is something missing in initrd, but I don’t have any idea what it is.

That did it, thanks a lot.