Bootfreeze: "Mounting local filesystems..."

[phen]

Tach allerseits,

seit gestrigem D-U will mein 64bit aptosid nicht mehr booten, weder mit dem frischen 39er Kernel noch mit nem vorherigen, wobei der Bootvorgang bei "Mounting local filesystems..." einfriert.

Tja, was könnte ich denn tun um das wieder zu richten?

[devil]

mit dem 39 ist bekannt (siehe EN-forum) die alten gehen aber.
udev 169-1 ist der bösewicht.  #627446

greetz
devil

[phen]

Nen Unterschied zwischen dem 39er und nem 38er kann ich in dieser Hinsicht nicht feststellen, zumindest hatte ich auch bei letzterem den Bootvorgang bei selbigem Stand nach etwa 5min abgebrochen.

Wie kann ich denn udev downgraden?
Per live-cd und irgendwie über chroot?

[devil]

genau, ja. oder auf udev 170 warten.

greetz
devil

[phen]

Downgrade auf udev aus testing hat nichts geändert, erneutes D-U (ebenfalls per chroot), was u.a. sysvinit und initscripts aktualisiert hatte ebenfalls nicht.

Ich hatte versucht den 39er Kernel zu deinstalliern, allerdings scheitert das da Erstellen eines symlinks auf initrd in /boot nicht möglich sei. Liegt an chroot?

Nun, noch weitere Ideen oder Vorschläge, mal von ner Neuinstallation abgesehn?

EDIT:
fstab ändern so dass nix gemountet wird, macht das Sinn in Hinsicht aufs Hochfahren?

[agaida]

Reinchrooten und updaten sollte helfen:

Code Select Expand


Hole:1 http://aptosid.com/debian/ sid/fix.main libudev-dev amd64 169-1+c0.aptosid.1 [57,4 kB]
Hole:2 http://aptosid.com/debian/ sid/fix.main udev amd64 169-1+c0.aptosid.1 [474 kB]
Hole:3 http://aptosid.com/debian/ sid/fix.main libudev0 amd64 169-1+c0.aptosid.1 [123 kB]
Hole:4 http://aptosid.com/debian/ sid/fix.main libgudev-1.0-0 amd64 169-1+c0.aptosid.1 [109 kB]

Da im fix.main so viel nicht auftaucht und slh in debian bugs schon einen Patch aufgezeigt hat, sollte der wohl da drin sein. Schwein gehabt, nichts von gemerkt.

[devil]

richtig, und funktioniert

greetz
devil

[DonKult]

udev mit dem Patch den slh ausgegraben hat fixed das Problem (für mich). Ist wie angemerkt bereits in aptosid's fix.main.

Wenn das Kind im Brunnen gelandet ist hat mir folgendes "Häckerle" geholfen:
Im "kaputten" System warten bis der Maintainershell kommt, mit root Passwort anmelden und dpkg downgraden:
dpkg -i /var/cache/apt/archives/*udev*168-2*.deb
Eventuell macht der postinst von udev zicken, dann "einfach" den 'exit 0' Trick anwenden.
Anschließend die initramfs für den Kernel neubauen:
update-initramfs -u
(das fehlerhafte udev befindet sich sonst noch im initramfs)

Ich musste übrigens auch noch
mount -t tmpfs tmpfs /dev
/etc/init.d/udev start
durchführen um an mein /var/cache/apt zu kommen, da die auf einer anderen Platte liegt...
Danach sollte man allerdings auch Netzwerk haben, sodass man auch aus dem Internet laden kann, wenn nix mehr im archive ist.

[RoEn]

...dann "einfach" den 'exit 0' Trick anwenden...

Erklär mal genauer

[agaida]

Mal ne ganz doofe Frage - bei der letzten udev-Attacke waren ja eigentlich alle am Arsch. Diesmal hab ich von der ganzen Sache nichts mitbekommen. Das hätte meinen Hauptrechener, mein Laptor, meinen Testserver und eine weitere Testinstallation betreffen müssen. Alles grundverschiedene Hardware.

Alle Maschinen wurden nach dem Update neu gestartet, bei keiner gabs Probleme. Ich erinnere mich noch daran, dass ich bei mir gedacht habe: "Wenn das mal gut geht!" - Als meine Archinstallationen dann auf 170 hochgingen, dachte ich wieder: "Was wird, wenn das in debian aufschlägt?" - Nichts passiert - hat man mich verschont, weil ich so laut und ausdauernd fluchen kann?

[devil]

RoEn,

...dann "einfach" den 'exit 0' Trick anwenden...

das ist relativ böse und sollte imho hier nicht ausgeführt werden

greetz
devil

[agaida]

hierzu auch noch einen Frage - ohne den gekannt zu haben, find ich gut, ich bin aber noch nie in die Situation gekommen, das so übersteuern zu müssen. Reicht nicht ein alles forcieren aus?

[devil]

wenn es im postinst hängt, bringt das nichts.

ansonsten könnte man gerade meinen, es gäbe einen preis zu gewinnen: gegen udev 169-1 gibt es gerade 4 RC Bugs.
das ist wirklich preisverdächtig.
627446, 627487, 627500 und 627513

greetz
devil

[phen]

Code Select Expand


dpkg -i /var/cache/apt/archives/*udev*168-2*.deb
initramfs

Tja, das hatte ich auch gemacht, aber geholfen hatte es nicht.

Dann hatte ich mal aus meiner fstab alles ausser das root Verzeichnis rausgenommen, daraufhin verlief das Booten wie gewünscht. Dann wieder die gestutzte fstab durch die ursprüngliche fstab ausgetauscht und nach

Code Select Expand

mount -awaren ordnungsgemäss alle Partitionen gemountet.
Desweiteren hatte ich dann udev auf die aktuellste aus fix.main aktualisiert. Nur leider klappt das Booten einfach nicht, bleibt noch immer bei "Mounting local filesystems..." hängen.

Ist ja nicht so als hätte ich in den letzten Wochen, oder auch Monaten was an meiner fstab geändert. Aber offensichtlich hab ich mit der Datei irgendnen Problem.

PS: Achja, an meinen Partitionen wirds wohl auch nicht liegen, hier im Arch werden alle sauber eingebunden.

[DonKult]

@agaida: Mein Problem war udev's Meldung "Resource temporary unavailable" -- was "klar" auf ein Timingproblem hinweist. Vorallem weil ich udev's mount später ja händisch ausführen konnte. Gibt einfach zu viele, die viel zu viel Glück haben.
An der postinst Geschichte kann man nichts erzwingen - der Script ist entweder erfolgreich oder eben nicht. Er sollte aber besser erfolgreich sein... Einfach so was zu verändern ist nicht immer eine gute Idee: Man muss da schon wissen was man da verbricht...

@RoEn: Ich hab das 'exit 0' nicht weiter ausgeführt, weil das im generellen nichts für schwache Nerven ist: Man kann dadurch durchaus sich noch tiefer in Probleme reiten als man schon ist und wie ich schrieb auch nur 'eventuell' überhaupt nötig -- schien in meinen Tests auch ein Timingproblem zu sein.