Sie sind hier: Startseite / Busybox: Unable to find a medium containing a live file system (initramfs)

Unable to find a medium containing a live file system (initramfs)

Beobachtung

Der Bootloader (in meinem Fall GRUB) funktioniert nach dem Starten des Computers noch einwandfrei. In seltenen Fällen (vielleicht 1 von 10) startet auch das System völlig normal. Das ist aber eher die Ausnahme, denn häufiger folgt nach der Auswahl des Betriebssystems der lila Bootsplash von Ubuntu, ohne dass danach noch großartig etwas passieren würde. Nach einiger Zeit kommt dann (auch nicht immer) eine Fehlermeldung à la:
BusyBox <$version> built in shell (<$shell>)
Enter 'help' for a list of built-in commands.
(initramfs) Unable to find a medium containing a live file system
Diese Fehlermeldung gibt es noch in leicht abweichender Form, mit Angabe der gesuchten, aber eben nicht gefundenen UUID der Festplatte(npartition).

Race-Conditions?

Der Start im Recovery Mode offenbart weitere interessante Angaben. Neben diversen Angaben findet sich etwas von nicht antwortenden Geräten:
Device not ready
Dieser Eintrag wiederholt sich ggf. mehrmals. Nach etwa 30 Sekunden taucht die oben notierte Fehlermeldung auf. Rund fünf Sekunden später meldet sich das gewünschte Gerät mit dem darauf befindlichen "live file system" mit etwa folgender Zeile zu Wort:
ata3: link is slow to respond, please be patient
Offenbar braucht das an ata3 angeschlossene Gerät zu lang, um auf eine Anfrage des System zu reagieren, sodass ein Timeout einsetzt. Und in wenigen Fällen meldet sich das Gerät eben kurz vor diesem Timeout. In diesem seltenen Fall startet das System dann völlig normal. Offenbar liegen hier Race-Conditions zwischen Timeout und der Antwortzeit des Geräts vor.

Mögliche Lösung

Eine gezielte Suche nach derartigen Problemen fördert neue Beiträge aus der Netzwelt zu Tage. Um den Geräten etwas mehr Zeit zu geben, müsse man den timeout Parameter höher setzen. Dazu wird in den Bootoptionen ein zusätzlicher Wert angegeben: rootdelay=XX, wobei XX die Sekunden sind, die man auf eine Antwort warten möchte. Ich habe 75 gewählt, da auch bei 60 hin und wieder noch der Fehler auftritt - bei 75 aber bislang nicht.

Ich hoffe und wünsche, dass Vielen diese Erfahrung erspart bleibt, denn es ist frustrierend, wenn das System eigentlich laufen müsste, es aber partout nicht machen will und nach und nach die Schrauben ausgehen, an denen man noch drehen könnte.

Update / Nachtrag

Da mir 75 Sekunden warten nicht so recht gefallen hatten und auch das neue Blu-Ray Laufwerk (LG CH10LS20) bisher nicht zur Arbeit bewegt werden konnte, habe ich weiter recherchiert. Dabei bin ich schließlich auf diesen Bug gestoßen. Hier hilft bei einigen Nutzern die Angabe des Bootparameters libata.force=X:nohrst (X ist durch den Port des störenden Gerätes zu ersetzen, in meinem Fall also 3, da ata3 das fehlerproduzierende Gerät ist). "Warum nicht?" dachte ich mir und habe es einmal ausprobiert. Statt also rootdelay=75 habe ich lediglich libata.force=3:nohrst eingestellt. Und in der Tat, sowohl das Boot up als auch das Laufwerk funktionieren seitdem reibungslos.
Reklame