Skip to content

Fehlersuche beim Linux-Kernel (Bootprobleme)

Vor nicht allzu langer Zeit sass ich entspannt bei einem Kaffee und wollte meinen Rechner starten. Einschaltknopf gedrückt und der Bildschirm lächelte mich mit einer Fehlermeldung an:

error: unexpectedly disconnected from boot status daemon
Begin: Waiting for root file system ...

grml, warum muss das ausgerechnet jetzt passieren? Sehr schnell war klar, dass ich an dieser Stelle nicht weiter komme. Also bootete ich einen alten, funktionierenden Kernel und änderte meine grub-Einstellungen entsprechend. Damit lebte ich einige Zeit gut, bis mir mal wieder der Workaround auffiel. Jetzt wollte ich das Problem mal genauer angehen.

Beispielansicht eines Plymouth-Bootscreen

Die Fehlermeldung, die irgendwas von dem Boot Status Daemon erzählte, schien auf plymouth hinzudeuten. Der Sinn der Software ist es, den Bootprozess zu verschönern. Das heißt, es macht schicke Bildchen anstatt der Kernelmeldungen.

Der Bugtracker von Debian hatte einen Eintrag zu meiner Meldung. Die in dem Bugreport genannten Einstellungen änderten bei mir nichts am Problem. In meinem nächstem Versuch wollte ich plymouth deinstallieren. Aber da gab es eine winzige Abhängigkeit zu mountall(8). Der Zufall führte mich zu einem angepasstem Paket, mit dem plymouth deinstalliert werden kann. In freudiger Erwartung startete ich den Rechner neu. Aber es wäre nur zu schön gewesen, wenn sich das Problem so leicht lösen ließe.

Zu diesem Zeitpunkt kam mir in den Sinn, die Bootoptionen quiet und splash zu entfernen. Siehe da, ein wenig mehr kam zum Vorschein:

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Waiting for root file system ...

Warten, warten und nochmal warten. Oh, nun noch eine BusyBox-Shell:

(initramfs) Gave up waiting for root device. Common problems:
...
ALERT! /dev/disk/by-uuid/.... does not exist. Dropping to a shell!

Nebenbei stellte ich dann fest, dass die Meldung mit dem Boot Status Daemon nur bei einer speziellen Kernelversion auftrat. Die Meldung oben konnte ich mit jeder Standard-Ubuntu-Kernelversion größer als 2.6.32-20 erzeugen. Für mich wäre es viel wichtiger zu erfahren, woher denn diese Meldung stammt!

Ein Hinweis brachte mich dann zu den Mainline-Builds. Das sind spezielle Pakete des Ubuntu Kernelteams, die recht nahe am Original-Kernel sind. Ich versuchte wieder diverse Versionen. Alle brachten mir die Fehlermeldung. Na gut, dann baue ich eben einen eigenen Kernel.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cp /boot/config-2.6.32-24-generic /usr/src/linux-2.6/.config
make oldnoconfig
make deb-pkg
dpkg -i ../linux*.deb
reboot

Beim ersten Reboot startete der Kernel tatsächlich korrekt. Sollte Ubuntu wirklich einen Bug in den eigenen Kernel eingebaut haben? Plötzlich fiel mir ein, dass die Zeile im grub einen kleinen, aber feinen Unterschied zu den restlichen Einträgen aufwies. Ich hatte root=/dev/sda1 angegeben. Alle anderen Einträge trugen root=UUID=.... Also versuchte ich die Änderung bei den anderen Kerneln und es klappte. Jede Kernelversion bootete mit dieser Änderung.

Jetzt muss ich nur noch herausfinden, warum das nicht klappt und ich bin wieder ein glücklicher Mensch. :-)

Das Bild stammt vom Blog Linux und ich

Mammutaufgabe Nummer 2 für 2010

Vor einer Woche tagte das letzte Gremium und auch hier gab es einen eindeutigen Beschluss: Mein Lehrauftrag für das Wintersemester 2010/11 wird genehmigt. Also startet bald mein nächstes Großprojekt, die eigene Vorlesung. Ich werde zusammen mit einem weiteren Professor des Lehrstuhls für Informatik die Vorlesung IT-Sicherheit halten und bin sehr auf diese neue Erfahrung gespannt.

Die ursprüngliche Idee für diese Vorlesung kam aus der Studentenschaft. Während der Proteste anfangs des letzten Semesters monierten Studenten das fehlende Thema. Über diverse Iterationsstufen kam der Vorschlag schließlich bei mir an und der Stein ins Rollen. Ich halte schon seit vielen Jahren Seminare. Zu Beginn waren es hauptsächlich Finanzthemen, genauer Devisen- und Wertpapierhandel. Später schwenkte ich auf den Softwaresektor um. Anfangs war Java der Hauptinhalt, später erweiterte ich mein Angebot auf GNU/Linux (Zertifizierung, Administration etc.), IT-Sicherheit (BSI Grundschutz) und Datenschutzthemen. Die letzteren Felder beackere ich auch in praktischer Tätigkeit. Daher wurde mir das nötige Wissen und die Fähigkeit zur Schulung anerkannt. Die diversen zuständigen Gremien gaben ihre Zustimmung und nun kann es losgehen.

Wenn es soweit ist, berichte ich über die Inhalte und eventuell interessante Begebenheiten aus der Vorlesung. Seit gespannt!

"Your IP address seems to have changed"-Meldungen im Tor-Log

Hast du dich gewundert, dass in der Logdatei von Tor viele Meldungen der Art [notice] Your IP address seems to have changed to 1.2.3.4.Updating. enthält? Dann könntest du einem Fehler in der Software aufgesessen sein. Ein Tor-Server, bei dem keine IP-Adresse fest eingestellt ist (Option Address) und dessen Hostname nicht/falsch auflöst, ermittelt seine IP-Adresse auf eigenwillige Weise. Es werden vier Byte aus dem Speicher ausgelesen und als IP-Adresse verwendet. Der Fehlerbericht 1269 hat eine Beschreibung. Mit Version 0.2.1.24 wurde das Verhalten wieder korrigiert.

Adios Festplatte

Wenn man untenstehendes im Syslog liest, ist es wohl Zeit, sich von der Festplatte zu verabschieden:

kernel: ide: failed opcode was: 0xb0
kernel: ide: failed opcode was: unknown
kernel: hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
cronjob