After distro update, tumbleweed won’t boot. Stalls after cryptography setup — no request for password.
My usual solution to boot issues is to run the tumbleweed installer in update mode, but this fails also. Installer asks for encryption password, offers opportunity to select partition to update and then fails with a Yast installer error when attempting to mount partitions.
The problem does not seem to be with the encrypted partitions. I can boot a live USB openSUSE, then via Dolphin mount and view the encrypted partitions.
Any suggestions how I can fix whatever’s wrong in the boot process without reformatting? I have encrypted partitions for /var, /srv, and /home — I would prefer not to wipe them. Also, machine is a dual boot with Win10, so I’d rather not repartition/reformat.
As the data is intact, I might just throw in a new drive for a new Linux install (and I do have most data backed up) but I’d prefer not to have to completely rebuild this server, which runs my Nextcloud, VPN, etc.
Could be relevant, though my boot/root partition is not encrypted, as is the one described in the bug report. I better not install updates on my other encrypted computer (which is still bootable)!
After studying the bug link you provided, it seems likely that the initrd was rebuilt during the update process missing a module or modules. Unlike the user in that bug report, I don’t know how to to figure out what is missing or how to use dracut to fix it.
He does report that after fixing it the one time, future kernel updates continued to work, so if I figure out those steps I may be back in business.
Thank you for the “plymouth.enable=0” command, I did not know it. I was then able to provide the password at the command prompt during boot. Oddly enough, I was not able to enter the password at the command prompt during boot by hitting [ESC] to toggle the splash screen. This used to work in the past. Plymouth has been working for me for a few iterations, but in the past it was quite buggy. This time around, the boot sequence is apparently waiting for the password from the splash screen dialog box. However, the splash screen is not providing a dialog box, nor was the command line active and waiting for the password when I toggled the splash screen off. However, running with the plymouth.enable=0 option, I was able enter the password – and everything else in the boot process proceeded normally.
That might be a plymouth bug. I think plymouth was updated in a recent update.
I normally don’t use plymouth, but it is still installed. I will try booting with plymouth, to see if I get the password handoff. However, I am encrypting root, so that might behave differently here. But worth some tests.