Univention Bugzilla – Bug 28287
Plymouth gibt die Konsole nicht wieder frei
Last modified: 2012-12-12 21:10:43 CET
Ab 3.1 gibt plymouth die Konsole beim Boot nicht wieder frei (kein X installiert). Der Bootsplash wird ewig angezeigt und steht (keine Animation mehr) aber es kommt nie ein Login Prompt. Zusätzlich kann sich noch folgendes anschauen: Wenn man das System startet (ohne X) kommt nach dem Bootsplash noch die Meldung Starting univention-network-common. done. bevor der Login Prompt angezeigt wird. In rc2 sieht die Reihenfolge so aus ... S91apache2 S97univention-maintenance S97univention-s4-connector S99plymouth S99rc.local S99rmnologin S99stop-bootlogd S99univention-network-common Vielleicht kann man univention-network-common auf S98 setzen (alle notwendigen Dienste sollte hier bereits gestartet sein), dann sieht man diese Meldung nicht mehr.
Mit einem strace auf plymouthd in /etc/init.d/hwclock.sh sieht man, dass plymouthd abschmiert beim Versuch /dev/tty1 zu öffnen, mit plymouthd assert failure: plymouthd: ply-event-loop.c:736: ply_event_loop_watch_fd: Assertion `fd >= 0' failed. Leider konnte ich herausfinden warum, es passiert ab und zu, machmal aber auch nicht. Als ich /etc/init.d/x11-common und /etc/init.d/console-screen.sh beim booten deaktiviert hatte, schien es nicht mehr zu passieren, aber was do drin genau der Auslöser für dem plymouthd Absturz war, bleibt unklar. Eine neue plymouth Version zu bauen scheint zu aufwendig (braucht debhelper und dpkg-dev Version aus wheezy). Es wurde jetzt ein "Workaround" in /etc/init.d/plymouth eingebaut (patch gegen plymouth). Dort wird beim Start plymouthd nun wieder gestartet, falls er nicht läuft und der Bootsplash aktiviert, dann funktioniert das nachfolgende quit auch wieder und der Bootsplash wird beendet. Das ganze darf aber nur gemacht werden, wenn kein X läuft, da dann der Bootsplash auch ihne laufenden plymouthd beendet wird. > S99univention-network-common Das init Skript von univention-network-common wird nun auf S98univention-network-common, bei diesem Update wird das alte S99univention-network-common aus den Runleveln gelöscht.
*** Bug 28469 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > *** Bug 28469 has been marked as a duplicate of this bug. *** Siehe Beschreibung an Bug #28469.
Durch den abstürzenden plymouthd verbleibt die Konsole (sehr wahrscheinlich) in einem Zustand, wo verschiedene Terminal-Einstellungen (echo, cooked-mode, 8-bit, etc,) noch so geändert sind, das es für die grafische Ausgabe passt, aber eben nicht mehr für eine normale Text-Konsole. <http://www.lafn.org/~dave/linux/terminalIO.html> Ein ähnliches Problem plagt whiptail an Bug 17722.
Ursache für den Absturz von plymouthd scheint das Problem aus Bug #23748 zu sein. init stiehlt beim Wechsel der Runlevel die Konsole (tty1) und damit kommt plymouth nicht klar. Letzte strace Meldung von plymouthd ist plymouthd assert failure: plymouthd: ply-event-loop.c:736: ply_event_loop_watch_fd: Assertion `fd >= 0' failed. Dort wird versucht das tty zu öffnen, was nicht funktioniert und zum Absturz von plymouthd führt. Siehe auch http://comments.gmane.org/gmane.comp.freedesktop.plymouth/378 Auch mit einer aktuelleren Version von plymouth tritt dieses Problem auf. Warum der Absturz nur auf amd64 reproduziert werden kann, ist unklar. Bei Mandriva ist ähnliches aufgefallen. Dort wird das "(void)ioctl(f, TIOCSCTTY, 1);" in init.c nicht aufgerufen http://rpmfind.net/linux/RPM/mandriva/2011/x86_64/media/main/release/sysvinit-2.87-11.x86_64.html https://abf.rosalinux.ru/import/sysvinit/blame/master/sysvinit-2.87-speedboot-ioctl.patch http://mandriva.598463.n5.nabble.com/Bug-58488-initscripts-NEW-x11-eating-all-CPU-due-to-fastboot-td608899.html Dies wurde nun in sysvinit/init.c übernommen. Der plymouth Workaround wurde entfernt. OK - cryptsetup OK - Filesystem Check auf / -> sulogin OK - boot auf amd64 OK - Wechsel zw. Splash und Console mit ESC OK - Verhalten aus bug #28469 konnte nicht mehr beobachtet werden (Passwort Echo) OK - Boot ohne Splash OK - Boot in das Single User Runlevel In der QA bitte die obigen Punkte testen und versuchen irgendwie die Konsole kaputt zu bekommen. Der init Patch sorgt dafür, das init tty nicht mehr so wie früher initialisiert. Wir sollten schauen, ob das negative Auswirkungen auf das Bootverhalten/Runlevel-Wechsel/Konsole hat.
Falls jetzt noch etwas auffällt, kann man den Patch vielleicht so anpassen, das "(void)ioctl(f,TIOCSCTTY, 1);" in init.c nur ausgelassen wird, wenn plymouthd läuft.
*** Bug 23748 has been marked as a duplicate of this bug. ***
OK: Changelog svn14860 OK: sysvinit svn10854 OK: plymoud svn10855 (der Patch ist doppelt vorhanden, aber einmal deaktiviert: <https://billy.knut.univention.de/websvn/listing.php?repname=patches&path=%2Fplymouth%2F3.1-0-0-ucs%2F0.8.3-9.1%2F&#a23e18d35fc9cbb5b0cf1b97cb4583334> OK: cryptsetup <http://wiki.univention.de/index.php?title=Talk:Festplattenverschl%C3%BCsselung_w%C3%A4hrend_der_UCS-Installation> Man wird grafisch nach dem Passwort gefragt. FAIL: Startet man allerdings direkt aus Grub in den Recovery-Modus, so kann man das Passwort nicht eingeben: Jeder Tastendruck schließt anscheinend sofort die Eingabe ab. Ändert man in grub das "splash" in "nosplash" kann man sich einloggen.
Der überflüssige plymouth Patch wurde entfernt. > FAIL: Startet man allerdings direkt aus Grub in den Recovery-Modus, so kann man > das Passwort nicht eingeben: Jeder Tastendruck schließt anscheinend sofort die > Eingabe ab. Ändert man in grub das "splash" in "nosplash" kann man sich > einloggen. Hier scheint der plymouth irgendwie zu laufen, obwohl man das an der Ausgabe nicht erkennt. Selbst wenn ich den init Patch so anpasse, dass er "(void)ioctl(f,TIOCSCTTY, 1);" nur macht, wenn plymouthd nicht läuft, habe ich das gleiche Verhalten. -> Workaround, wir deaktivieren den Bootsplash für den recovery mode. Das ist wahrscheinlich eh eine gute Idee, da dieser Mode in "Notfällen" gebraucht wird und dann eyecandy eh nur verwirrt und stört (zumal man ja auch nur die Konsole gesehen hat).
FYI: In plymouth-0.8.3/src/main.c:617#plymouth_should_show_default_splash() findet eine Überprüfung der Kernel-Command-Line statt: taucht darin 'single', '1', 's' oder '-s' auf, wird statt dem 'default'-Splash-Screen der 'detailed'-SS angezeigt (das ist das was man per ESC umschaltet). Im Gegensatz dazu wird bei einem "nosplah" (bzw. bei fehlendem "splash") direkt der Aufruf von plymouthd bereits durch das Init-Skript übergangen. FYI: Man kann neben "debug" auf der Kommandozeile auch mit ' plymouth:debug' über die Kernel-Command-Line die Debugausgabe von plymouthd aktivieren. Das zeigt, das plymouthd ein eigenes Pseudo-Terminal öffnet und dieses von den init-Skripten genutzt wird, damit Plymouth deren Ausgabe abfangen und auf den Splash-Screen weiterleiten kann. sulogin öffnet vermutlich direkt das Controlling-tty zum Lesen des Passwortes, was natürlich dann mit der Verwendung von tty1 durch Plymouth für den grafischen Splash-Screen kollidiert. FYI: plymouthd hat einen Crash-Handler src/main.c:1755#on_crash(), der nur für SIGABRT und SIGSERV aufgerufen wird. Falls das Problem des abstürzenden plymouthd erneut auftritt sollte ggf. überlegt werden, ob man den Handler nicht noch an mehr Stellen aktiviert. OK: Der start in den Recovey-Modus funktioniert: Die splash-Option wird nur noch per GRUB_CMDLINE_LINUX_DEFAULT hinzugefügt, nicht bei GRUB_CMDLINE_LINE, was auch für beide und damit auch für den Recovery-Eintrag verwendet wird. OK: Bei einem fehlschlagenden File-System-Check des Root-Dateisystems bekommt man ein funktionierendes sulogin: sed -i '/FSCKCODE/s/\$?/exit 4/' /etc/init.d/checkroot.sh echo u >/proc/sysrq-trigger echo s >/proc/sysrq-trigger debugfs -w -R 'rmdir /lost+found' /dev/vg_ucs/rootfs echo s >/proc/sysrq-trigger echo b >/proc/sysrq-trigger OK: ChangeLog svn14880 OK: plymouth_0.8.3-9.1.9.201209190912
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".