TW20241125 Update Issue
Hi there, Today's update using 'zypper dup' immediately reboots and the machine hangs "forever" (AMD Ryzen 7 PRO, KDE Plasma 6.2.3 with Wayland). Seems to be related to the posttrans(dracut-059+suse.665.gd2af7028-1.1.x86_64) script. Anyone else seeing this? Any idea? Thx. Regards, Frank
On Tuesday 2024-11-26 22:25, Knurpht-openSUSE wrote:
This is a reaallly weird one. # zypper up 'plym*' (I did not choose dracut because of your report) This threw me back to tty1 nevertheless, where the splash animation showed. I was able to go to tty2 (where I had set up kmscon), but not tty3-6 (just empty), dunno yet. tty7 with Xorg was also still live. zypper is still running (heh?), so here is a process trace (ps xaf) showing what's going on (or not). \_ zypper up plym* \_ /usr/bin/systemd-inhibit --what=sleep:shutdown:idle --who=zypp --mode=block --why=Zypp commit running. /usr/bin/cat | \_ /usr/bin/cat \_ /usr/libexec/zypp/zypp-rpm \_ /usr/bin/systemd-inhibit --what=sleep:shutdown:idle --who=zypp-rpm --mode=block --why=Zypp commit running. /usr/bin/cat | \_ /usr/bin/cat \_ bash /usr/lib/systemd/systemd-update-helper system-reload-restart \_ systemctl reload-or-restart --marked more to follow
On Tuesday 2024-11-26 22:50, Jan Engelhardt wrote:
Also ps: <ps xaf output is ordered by start time(!)> xyz zypper up plym* xyz \_ ... 37874 ? S 0:00 /usr/sbin/plymouthd --mode=boot --pid-file=/run/plymouth/pid --attach-to-session 37879 ? Ss 0:00 /usr/bin/plymouth --wait journal: systemd[1]: Reload requested from client PID 37813 ('systemctl') (unit session-1.scope)... systemd[1]: Reloading... systemd[1]: /usr/lib/systemd/system/plymouth-start.service:15: Unit uses KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update the service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed. systemd[1]: Reloading finished in 191 ms. systemd[1]: Queuing reload/restart jobs for marked units… systemd[1]: systemd-ask-password-plymouth.path: Deactivated successfully. systemd[1]: Stopped Forward Password Requests to Plymouth Directory Watch. systemd[1]: Stopping Forward Password Requests to Plymouth Directory Watch... systemd[1]: plymouth-quit-wait.service: Deactivated successfully. systemd[1]: Stopped Hold until boot process finishes up. systemd[1]: Stopping Hold until boot process finishes up... systemd[1]: plymouth-read-write.service: Deactivated successfully. systemd[1]: Stopped Tell Plymouth To Write Out Runtime Data. systemd[1]: Stopping Tell Plymouth To Write Out Runtime Data... systemd[1]: Starting Tell Plymouth To Write Out Runtime Data... systemd[1]: plymouth-start.service: Deactivated successfully. systemd[1]: Stopped Show Plymouth Boot Screen. systemd[1]: Stopping Show Plymouth Boot Screen... systemd[1]: Starting Show Plymouth Boot Screen... plymouthd[37874]: 11:34:58.805 ../src/main.c:2036:check_logging : checking if console messages should be redirected and logged plymouthd[37874]: 11:34:58.805 ../src/main.c:2048:check_logging : logging will be enabled! plymouthd[37874]: 11:34:58.805 ../src/main.c:2122:initialize_environment : source built on Nov 15 2024 systemd[1]: Finished Tell Plymouth To Write Out Runtime Data. systemd[1]: Started Show Plymouth Boot Screen. systemd[1]: Started Forward Password Requests to Plymouth Directory Watch. systemd[1]: Starting Hold until boot process finishes up... "Hold" is probably the reason for all the problems observed: - zypper waiting forever - `systemctl start getty@tty3` hangs - `systemctl start cups` does _not_ hang Killing process 37879 (plymouth --wait) makes the system unstuck. zypper completes, as does the pending request for getty@tty3, or VT-activation of tty4. So yeah, plymouth was restarted, causing the splash screen to force itself and inhibit a bunch of unit activations.
On Tuesday 2024-11-26 23:00, Jan Engelhardt wrote:
As long as (plymouthd --mode=boot) is running, it listens for ESC key events. It does so even when the user has gone back to Xorg/tty7 to resume the session; pressing ESC in Xorg throws the users back to tty1.
Hi Am 27.11.24 um 09:41 schrieb Axel Braun:
There's a plymouth update pending that hopefully resolves the crash during startup. https://build.opensuse.org/request/show/1226800 IDK if that is related to the dracut issue. Best regards Thomas
Cheers Axel
-- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
On Wed, Nov 27, 2024 at 11:52 AM Thomas Zimmermann via openSUSE Factory <factory@lists.opensuse.org> wrote:
TBH I think that the last plymouth update simply has to be reverted, it causes far too many different problems (it crashes, it does not show password prompt or it corrupts entered password and now it additionally hangs on update).
Hi Am 27.11.24 um 10:34 schrieb Andrei Borzenkov:
I agree with that. Best regards Thomas -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Hi everyone, This plymouth update is for almost sure causing some issues for luks enabled boot drives too. See here if it is interesting for you: https://forums.opensuse.org/t/new-opensuse-update-won-t-let-me-get-pass-thro... And here too: https://www.reddit.com/r/openSUSE_Slowroll/comments/1gzpj3g/luks_broken_afte... Many say that they can't reproduce the error. However I experienced too, and thankfully I have a Timeshift Snapshot in place to revert. I have a busy week but I'll try to detail the next step to reproduce it if I can this weekend. Kindest regards On Wed, 27 Nov 2024 at 19:30, Frank Krüger via openSUSE Factory < factory@lists.opensuse.org> wrote:
worst situation on an machine with encrypted disks. boots, I can decrypt the boot loader, but then when is to decrypt the partitions in Plymouth screen, only one seems to be decrypted and mounted... then drops me in some rescue shell... from where I can seem to be able to decrypt and mount as expected... also since I am on normal fs no rollback possible. Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.re/ ______________________________________________________________________ On Tue, 26 Nov 2024 at 21:25, Knurpht-openSUSE <knurpht@opensuse.org> wrote:
On Wed, 27 Nov 2024 11:00:45 +0000, Alin Marin Elena <alinm.elena@gmail.com> wrote:
Exactly the same situation here. Postponing reboot now as long as possible
-- H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
On Tue, Nov 26, 2024 at 11:20 PM Frank Krüger via openSUSE Factory <factory@lists.opensuse.org> wrote:
I had a GUI crash but not reboot, with CTRL+Backspace it recovered. Although since snapshot 20241119 plymouth segfaults on boot (still happening). I was left on a boot screen with the spinning wheel but after pressing CTRL+F2 got a mouse pointer on a black screen. Login worked after CTRL+Backspace and the next reboot was ok but with plymouth still crashing (and delaying the boot). Maybe they are related.
Same problem here, although I didn't realize it was just showing the boot screen with the system still running, so I switched it off. Finally went back to the snapshot before updating to 20241125. I also noticed plymouth crashes since updating to 20241119. Am 26.11.24 um 22:25 schrieb Stratos Zolotas:
-- PGP Public Key available at https://pgp.mit.edu/ Key fingerprint = 3264 280C 05B1 572F 3F0B 42B8 1E7B 2D9D 063B D507
Hi, On 26/11/2024 22.00, Frank Krüger via openSUSE Factory wrote:
Hi there,
Today's update using 'zypper dup' immediately reboots and the machine hangs "forever" (AMD Ryzen 7 PRO, KDE Plasma 6.2.3 with Wayland). Seems to be related to the posttrans(dracut-059+suse.665.gd2af7028-1.1.x86_64) script.
The %posttrans in dracut only calls the %{regenerate_initrd_posttrans} macro to rebuild the initrd. This macro is also used by other packages, but checking the latest Tumbleweed snapshots dracut should've been the first one issuing an initrd rebuild since the plymouth update in 20241118. The changes in dracut are minor and seem unrelated. I'd try to rollback to an old snapshot, `zypper addlock plymouth*` and `zypper dup` from there.
I gave it a try, and indeed, the issue with the interruption during %posttrans was omitted. However, the issue with decrypting after reboot persisted. I tried hitting esc before the password prompt gui comes up, and with the tui password prompt, I also got a brief error message like this: Bluetooth: Malformed vendor event: 0x02. Reading supported feature failed (-16). I have no idea why bluetooth driver problems would interfere with swap decryption, but the message came up in the same moment as the password prompt appeared. Could be coincidence, but maybe it helps tracking the source of the issue (as it is not only plymouth apparently).
seems to be a workaround for the decryption issue. add plymouth.enable=0 to kernel book. the bt message you see i think is a red herring there is some discussion in here https://forums.opensuse.org/t/new-opensuse-update-won-t-let-me-get-pass-thro... workaround was suggested in that thread too. Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.re/ ______________________________________________________________________ On Thu, 28 Nov 2024 at 05:07, <0zark@chaospott.de> wrote:
I gave it a try, and indeed, the issue with the interruption during %posttrans was omitted. However, the issue with decrypting after reboot persisted. I tried hitting esc before the password prompt gui comes up, and with the tui password prompt, I also got a brief error message like this: Bluetooth: Malformed vendor event: 0x02. Reading supported feature failed (-16). I have no idea why bluetooth driver problems would interfere with swap decryption, but the message came up in the same moment as the password prompt appeared. Could be coincidence, but maybe it helps tracking the source of the issue (as it is not only plymouth apparently).
Hi there, same here, after ’dup’ machie reboots and hangs. Best regards, Niclaas -------- Ursprüngliche Nachricht -------- Von: Frank Krüger via openSUSE Factory <factory@lists.opensuse.org> Antwort an: Frank Krüger <fkrueger@mailbox.org> An: openSUSE Factory Mailing List <factory@lists.opensuse.org> Betreff: TW20241125 Update Issue Datum: 26.11.2024 22:00:45 Hi there, Today's update using 'zypper dup' immediately reboots and the machine hangs "forever" (AMD Ryzen 7 PRO, KDE Plasma 6.2.3 with Wayland). Seems to be related to the posttrans(dracut-059+suse.665.gd2af7028-1.1.x86_64) script. Anyone else seeing this? Any idea? Thx. Regards, Frank
Hi PSA: plymouth has been rolled back to the version before 20241119. https://build.opensuse.org/package/show/openSUSE:Factory/plymouth Best regards Thomas Am 26.11.24 um 22:00 schrieb Frank Krüger via openSUSE Factory:
-- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
On Tuesday 2024-11-26 22:25, Knurpht-openSUSE wrote:
This is a reaallly weird one. # zypper up 'plym*' (I did not choose dracut because of your report) This threw me back to tty1 nevertheless, where the splash animation showed. I was able to go to tty2 (where I had set up kmscon), but not tty3-6 (just empty), dunno yet. tty7 with Xorg was also still live. zypper is still running (heh?), so here is a process trace (ps xaf) showing what's going on (or not). \_ zypper up plym* \_ /usr/bin/systemd-inhibit --what=sleep:shutdown:idle --who=zypp --mode=block --why=Zypp commit running. /usr/bin/cat | \_ /usr/bin/cat \_ /usr/libexec/zypp/zypp-rpm \_ /usr/bin/systemd-inhibit --what=sleep:shutdown:idle --who=zypp-rpm --mode=block --why=Zypp commit running. /usr/bin/cat | \_ /usr/bin/cat \_ bash /usr/lib/systemd/systemd-update-helper system-reload-restart \_ systemctl reload-or-restart --marked more to follow
On Tuesday 2024-11-26 22:50, Jan Engelhardt wrote:
Also ps: <ps xaf output is ordered by start time(!)> xyz zypper up plym* xyz \_ ... 37874 ? S 0:00 /usr/sbin/plymouthd --mode=boot --pid-file=/run/plymouth/pid --attach-to-session 37879 ? Ss 0:00 /usr/bin/plymouth --wait journal: systemd[1]: Reload requested from client PID 37813 ('systemctl') (unit session-1.scope)... systemd[1]: Reloading... systemd[1]: /usr/lib/systemd/system/plymouth-start.service:15: Unit uses KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update the service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed. systemd[1]: Reloading finished in 191 ms. systemd[1]: Queuing reload/restart jobs for marked units… systemd[1]: systemd-ask-password-plymouth.path: Deactivated successfully. systemd[1]: Stopped Forward Password Requests to Plymouth Directory Watch. systemd[1]: Stopping Forward Password Requests to Plymouth Directory Watch... systemd[1]: plymouth-quit-wait.service: Deactivated successfully. systemd[1]: Stopped Hold until boot process finishes up. systemd[1]: Stopping Hold until boot process finishes up... systemd[1]: plymouth-read-write.service: Deactivated successfully. systemd[1]: Stopped Tell Plymouth To Write Out Runtime Data. systemd[1]: Stopping Tell Plymouth To Write Out Runtime Data... systemd[1]: Starting Tell Plymouth To Write Out Runtime Data... systemd[1]: plymouth-start.service: Deactivated successfully. systemd[1]: Stopped Show Plymouth Boot Screen. systemd[1]: Stopping Show Plymouth Boot Screen... systemd[1]: Starting Show Plymouth Boot Screen... plymouthd[37874]: 11:34:58.805 ../src/main.c:2036:check_logging : checking if console messages should be redirected and logged plymouthd[37874]: 11:34:58.805 ../src/main.c:2048:check_logging : logging will be enabled! plymouthd[37874]: 11:34:58.805 ../src/main.c:2122:initialize_environment : source built on Nov 15 2024 systemd[1]: Finished Tell Plymouth To Write Out Runtime Data. systemd[1]: Started Show Plymouth Boot Screen. systemd[1]: Started Forward Password Requests to Plymouth Directory Watch. systemd[1]: Starting Hold until boot process finishes up... "Hold" is probably the reason for all the problems observed: - zypper waiting forever - `systemctl start getty@tty3` hangs - `systemctl start cups` does _not_ hang Killing process 37879 (plymouth --wait) makes the system unstuck. zypper completes, as does the pending request for getty@tty3, or VT-activation of tty4. So yeah, plymouth was restarted, causing the splash screen to force itself and inhibit a bunch of unit activations.
On Tuesday 2024-11-26 23:00, Jan Engelhardt wrote:
As long as (plymouthd --mode=boot) is running, it listens for ESC key events. It does so even when the user has gone back to Xorg/tty7 to resume the session; pressing ESC in Xorg throws the users back to tty1.
Hi Am 27.11.24 um 09:41 schrieb Axel Braun:
There's a plymouth update pending that hopefully resolves the crash during startup. https://build.opensuse.org/request/show/1226800 IDK if that is related to the dracut issue. Best regards Thomas
Cheers Axel
-- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
participants (15)
-
0zark＠chaospott.de -
Alin Marin Elena -
Andrei Borzenkov -
Antonio Feijoo -
Axel Braun -
Frank Krüger -
GMX -
H.Merijn Brand -
Hakim Maghraoui -
Jan Engelhardt -
Javier Llorente -
Knurpht-openSUSE -
Oliver Schwabedissen -
Stratos Zolotas -
Thomas Zimmermann