    |
 Splash-ScreenDerzeit beschäftige ich mich ernsthaft damit, den Splash-Screen unter meiner Ubuntu Hardy Installation zum Laufen zu kriegen. Dabei gibt es mehrere Punkte, an denen der Splash-Screen zerstört wird und eine normale Kernel-Ausgabe erfolgt. Eines dieser Probleme, die den Splash-Screen zerstören, ist das Kernel-Modul "padlock". Das Problem sollte nur bei verwendeter Festplattenverschlüsselung auftreten. Hier versucht der Kernel, die Hardwareverschlüsselung mit dem "padlock" Modul zu aktivieren, was bei Fehlen dessen in einem Fehler ziemlich zu Beginn des Bootvorgangs resultiert, der den Splash unterbricht. Gelöst wird dieses Problem einfach, indem dem Kernel gesagt wird, er möge statt dem Modul "padlock" das Modul "sha256_generic" für das Modul "sha256" verwenden. sudo -s Anschließend muss das InitRAMFS neu gebaut werden, damit die geänderten Konfigurationsdateien auch dort berücksichtigt werden. sudo update-initramfs -u -k all UpdateEinen weiteren Stolperstein auf dem Weg zu einem funktionierenden Splash-Screen insbesondere in rundum Festplatten-verschlüsselten Umgebungen stellen fehlerhafte "resume" Einstellungen dar. Offenbar dazu gedacht, schlafengelegte Rechner mit einem alten Speicherabbild aus dem Swap-Bereich wieder zum Leben mit selben Zustand wie vor dem Herunterfahren zu erwecken, benötigen sie gleiche Swap-Partitionsangaben in Form von UUIDs in den Dateien "/etc/fstab" und "/etc/initramfs-tools/conf.d/resume", die beim Ausfindigmachen des RAM-Abbildes behilflich sein sollen. Ungünstig gestaltet sich dieses Verhalten dann, wenn aufgrund von Swap-Verschlüsselung sich die UUID der Swap-Partitionen bei jedem Boot-Vorgang ändert. Dann ist es nicht möglich, diese Werte mit der tatsächlichen, von "sudo blkid" zurückgegebenen UUID der Swap-Partition syncron zu behalten, das System wankt, "usplash" verhaspelt sich in einem Speicherzugriffsfehler (Segfault), stirbt daraufhin und der Splash-Screen verschwindet. Die Lösung ist denkbar einfach und besteht aus dem Löschen bzw. Umbenennen der Datei "/etc/initramfs-tools/conf.d/resume". Achtung: Das Löschen der Datei erfolgt auf eigene Gefahr! Mir ist kein negativer Nebeneffekt bekannt, ich kann einen solchen aber nicht ausschließen und keine Haftung für irgendeine Art von Folgeschäden übernehmen!sudo rm /etc/initramfs-tools/conf.d/resume Anschließend sollte der Boot-Splash beim Hochfahren nichtmehr an dieser Stelle zusammenbrechen. Update 2Probleme bereitet die Verschlüsselung ebenso beim Einbinden der übrigen verschlüsselten Laufwerke (/home, ...). Auch hier wird der Splash-Screen gestört und man findet sich auf einem Termin wieder. Eine Lösung für dieses Problem scheint allerdings derzeit noch in weiter Ferne, da grundlegende Probleme bei der Verarbeitung von Passwörtern im Splash-Screen-Programm "usplash" in Verbindung mit der Startprozedur bestehen, die dazu führen, dass das Passwort im Klartext in der Konsole erscheint. Wen das nicht sonderlich stört, der kann sein System mit einem Patch so manipulieren, dass der Splash-Screen auch an dieser Stelle wieder funktioniert. Der Patch funktioniert allerdings in den Situationen nicht, wo vorher eine Datenträgerüberprüfung mit "fsck" durchgeführt wird. Weitere Informationen zu diesem Thema gibt es hier: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/139363 Das fehlerhafte Verhalten und die Ausgabe des Passworts im Klartext auf die Konsole konnte ich bei mir nicht nachvollziehen. Der Patch lässt sich ziemlich einfach anwenden: wget http://launchpadlibrarian.net/15877400/cryptdisks.functions.patch Anschließend sollte beim nächsten Boot-Vorgang alles problemlos verlaufen und das Splash-Screen an dieser Stelle nichtmehr versagen. |
|
|