New opensuse update won’t let me get pass through decrypting swap partition

These two problems seems to be connected. Plymouth is dumping core. As described above, disabling plymouth removes the 30 seconds wait for some and also lets decrypt partitions.

Tumbleweed 20241122 snapshot didn’t fix the issue, at least mine, as (I guess) it has no plymouth update related.

I still think keyboard language may have something to do because I have another computer with decryption password with only numbers and letters and it decrypts and boots just fine. In the “problematic one” password has alphanumeric characters.

Kinda curious if some chad already reported this issue on opensuse Bugzilla? Because if none maybe that’s the reason why we haven’t get any plymouth update.

What stops you from doing it?

See this post. It is already reported…

1 Like

I don’t have account. How about you?

So create one. And you do not even need to do it - it is the same user/password as here.

That’s not how things work. You have the problem, you are interested in solving it, you can provide additional information, you can test the proposed fix. I am not your personal assistant to relay between developers and you.

If I could reproduce it I would open bug report. I cannot.

None of bug reports mentioned so far matches this topic. Plymouth does not crash, password prompt appears, console password agent is not even started (and 1233373 is not a bug in any case).

Where my earlier boots did show a crash/segmentation fault my later boots do not show that but I run into the problem that I cannot decrypt my home folder when running plymouth.

Not sure how the Opensuse development process works but it seems quite some people have this problem so one option is to roll back the update of plymouth.

There’s new snapshot released let’s try that snapshot to see if that fixed our problem.

Stab in the dark - could somebody who has this problem show /etc/vconsole.conf in the root filesystem and in the initrd? To get from initrd:

lsinitrd /boot/initrd-6.11.8-1-default etc/vconsole.conf
> cat /etc/vconsole.conf
# Written by systemd-localed(8) or systemd-firstboot(1), read by systemd-localed
# and systemd-vconsole-setup(8). Use localectl(1) to update this file.
KEYMAP=us
FONT=eurlatgr.psfu
FONT_MAP=
FONT_UNIMAP=
XKBLAYOUT=us
XKBMODEL=pc105+inet
XKBOPTIONS=terminate:ctrl_alt_bksp

> sudo lsinitrd /boot/initrd-6.11.8-1-default etc/vconsole.conf
# Written by systemd-localed(8) or systemd-firstboot(1), read by systemd-localed
# and systemd-vconsole-setup(8). Use localectl(1) to update this file.
KEYMAP=us
FONT=eurlatgr.psfu
FONT_MAP=
FONT_UNIMAP=
XKBLAYOUT=us
XKBMODEL=pc105+inet
XKBOPTIONS=terminate:ctrl_alt_bksp

I.e. they are 1:1 the same for me after booting without “splash=silent quiet”

Try commenting out or removing all XKB* lines and regenerate initrd

dracut --regenerate-all --force

Does it make any difference?

1 Like

That works like a charm, problem solved!

> sudo lsinitrd /boot/initrd-6.11.8-1-default etc/vconsole.conf
# Written by systemd-localed(8) or systemd-firstboot(1), read by systemd-localed
# and systemd-vconsole-setup(8). Use localectl(1) to update this file.
KEYMAP=us
FONT=eurlatgr.psfu
FONT_MAP=
FONT_UNIMAP=
# XKBLAYOUT=us
# XKBMODEL=pc105+inet
# XKBOPTIONS=terminate:ctrl_alt_bksp

No, it is not solved. Because I also tested adding XKBLAYOUT and it did work (even with KEYMAP=us and XKBLAYOUT=de). And I tested your vconsole.conf and again have no problem entering passwords.

But apparently some configurations are interpreted incorrectly. May be it depends on the characters used in password. I believe someone mentioned that pure alphanumeric passphrase worked … yes, here: New opensuse update won’t let me get pass through decrypting swap partition - #42 by Xuxo. Although “alphanumeric” is by definition “only numbers and letters”, so it is still unclear what exactly did not work.

Yes, solved is not the right word, but I can not correct anymore, a nice work-around (for me) is I think a better description.

I was quite amazed that this patch did work for me as I did not see the password dialog pop up even so I can not see how this is related to the actual password, it looks more to me some component of plymouth did no longer like these XKB* settings. As this is X specific, maybe as some fall-out of a Wayland related change?

I found DebuggingPlymouth and reverted the changes in vconsole.conf. /etc/vconsole.conf was already reverted by the system (not surprisingly given the comments at the top of the file) but I did re-run dracut to regenerate initrd

Then edited the boot line and added plymouth:debug after quiet and booted. That resulted in a graphical spinner although I saw also a full-screen console flashing by. After some spinning I did hit the Escape key and got the full-screen console with a password prompt. Typed the password and hit enter but it was not accepted. Typed again and noticed the dot appearing with every character and found that it missed quite some characters if typed too fast, sometimes I had to wait > 1 second before typing the next character otherwise no dot would be displayed. Doing it this slowly the password was accepted and the boot completed.

The good news is that there is now a plymouth denug log for this problem run.

https://paste.opensuse.org/pastes/640ca8d7765a

Hi,

I’ve made available a possible fix for this problem. I’m looking for testers. The repository is mentioned at 1233532 – plymouth-start.service: Failed to start Show Plymouth Boot Screen.

I’m also experiencing the same problem on all my Luks encrypted drive after the 24/10/2024 update on Tumbleweed-SlowRoll. I intially made a post about it in Reddit, before being proposed that the problem is already mentioned here: Reddit Post

To not make my post long, the Reddit post there contains the problem and how rolled back to before the update using Timeshift(I also needed to boot into the older kernel). It also contains the list of updated package that preceeded the problem happening.

Plymouth related packages and plugin are what stand to me as the possible cause of the problem based on the provided update package list.

Kindest regards,

I misspoke.

I meant that password has numbers, letters and other kind of characters. This password is causing decryption problem in the computer that has it, while other with only numbers and letters isn’t (in another computer).

Sorry for the confusion.