Qbi's Weblog

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.

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

Das Dateisystem ext4 ist einer der neuen Stars am Linuxhimmel. Es ist der Nachfolger von ext2/3 und wird seit 2006 entwickelt. Da ich letzte einen Laptop neu installieren wollte, kam ich auf die Idee ext4 zu probieren. Also bei der Installation von Ubuntu 9.04 die Partition mit der entsprechenden Option formatiert und losgelegt. Für vernünftiges Arbeiten brauche ich die Inhalte verschiedener git- bzw. Subversion-Repositorys. Subversion nutze ich dabei mittels git-svn. Während der Rechner dabei ist, verschiedene neue Pakete zu installieren, Repositorys zu clonen etc., bleibt er plötzlich stehen. Keine Reaktion auf Tasten oder auf die Magic SysRq (Magische S-Abf-Taste). Bei der Suche nach dem Fehler war es ganz klar, dass es am Befehl git-svn in Verbindung mit dem Dateisystem ext4 lag. Die Suche in diversen Bug-Datenbanken brachte mich nicht viel weiter. Also fragte ich direkt bei den ext4-Entwicklern. Theodore Tso antwortete mir:

This sounds like the classic Ubuntu Jaunty’s default kernel freezes when deleting large numbers of files. It didn’t occur with stock mainline 2.6.28, nor with stock mainline 2.6.29, and it bisected to one of Ubuntu’s ext4 patch backports. No one was able to debug it further, and I was never able to replicate it on my test systems, so we ultimately just told people to use a mainstream kernel or a Karmic beta kernel for people who wanted to use ext4 with Ubuntu Jaunty.

In der Tat seit dem Upgrade auf Kernelversion 2.6.31 gibt es keine Probleme. Solltest du also ähnliches erfahren, versuche einen Upgrade und alles wird gut.

Auch wenn der erste Apriltag schon fast eine Woche vorbei ist, muss ich doch meine Worte dazu loswerden. Bei den Stammtischen der LUG Jena werden hin und wieder auch mal verrückte Ideen diskutiert. Im Rahmen der verschiedenen Aprilscherze kam uns mal die Idee, einen eigenen zu kreieren.

In der Prozessliste finden sich u.a. auch Kernelprozesse, deren Name mit “k” beginnt. Dazu gehören beispielsweise kacpid, kjournald, ksnapd sowie einige mehr. Daneben hat auch KDE die Angewohnheit, Programme mit dem Anfangsbuchstaben “k” zu versehen. Man denke an kate, kicker, kopete und andere. Wir wollten nun mit einem Kernelpatch Verwirrung erzeugen, der sich um die Rechte der armen GNOME-Nutzer kümmert und die Prozessnamen umbenennt. Diese Idee wird bei uns regelmäßig nach dem ersten April wieder diskutiert. Jedes Mal stellen wir fest, dass wir das wieder mal vergessen haben. Doch hnaz hat diesmal dran gedacht:

More and more GNOME users (especially Ubuntu) get confused by their process list showing several process names that seem to indicate KDE-related services.

To settle things down a bit on the bugtrackers, this patch renames all offending kernel threads into something that goes better with GNOME-based systems.

Ich fand die Aktion klasse und es schien auf der LKML auch Anklang zu finden.

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 }

Nach einer Meldung bei Golem hat es ein Programmierer geschafft, den Ur-Linux-Kernel so zu verändern, dass er sich mit dem aktuellen GCC übersetzen lässt. Abdel Benamrouche stellt Images zum Download bereit und beschrieb auf der Kernel-Mailingliste, wie das Image in qemu zu starten ist. Das ist doch eine respektable Leistung.