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?
mit dem 39 ist bekannt (siehe EN-forum) die alten gehen aber.
udev 169-1 ist der bösewicht. #627446
greetz
devil
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?
genau, ja. oder auf udev 170 warten.
greetz
devil
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?
Reinchrooten und updaten sollte helfen:
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.
richtig, und funktioniert
greetz
devil
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.
Quote from: "DonKult"...dann "einfach" den 'exit 0' Trick anwenden...
Erklär mal genauer
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?
RoEn,
Quote
...dann "einfach" den 'exit 0' Trick anwenden...
das ist relativ böse und sollte imho hier nicht ausgeführt werden
greetz
devil
;) 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?
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
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
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.
@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.
im irc hat jemand das gleiche problem, ich schau da noch nicht durch.
hilft ein fsck denn weiter? (fsck.ext4 -c -v /dev/sdxy)
greetz
devil
Danke devil, zu wissen dass ich mit dem Problem nicht alleine dasteh is schon mal etwas aufbauend.
Nun, welche Partition sollte ich denn testen?
Ich hab insgesamt 13 davon, darunter auch ntfs, wofür es meines Wissens nach kein fsck gibt?
Ich hab mal lediglich sämtlich ntfs-3g Partitionen aus der fstab auskommentiert, vfat und ext dringelassen - auf diese Weise bootet er durch.
Offenbar können die ntfs Partitionen während des Bootens nicht gemountet werden.
@DonKult im Zusammenhang mit debian hab ich das noch nicht gebraucht. Und ja Du hast recht - aber wie heisst es so schön: "Du hast es kaputtgemacht, sieh zu wie Du es wieder hinkriegst." Vieles von dem, was ich schon 10 - 20 Jahre nicht mehr gebraucht habe, kommt durch Linux langsam wieder ins Bewusstsein zurück.
Mein Gott, merkt das hier keiner, dass udev und initscripts experimental gemeint sind: Einfach hold. Schluss und kein Ärger. Das testing Repo aktivieren und warten bis diese Pakete dort aufschlagen. Aptitude kann man leicht so konfigurieren, dass man es sofort sieht, wenn dies passiert. Kann man doch sicherlich auch per Paket in den preferences für apt-get konfigurieren?
So würde ich mir auch ein benutzerfreundliche Rollin' vorstellen. Das was Aptosid/Sidux eigentlich schon lange sein sollte.
Quote from: "ralul"Mein Gott, merkt das hier keiner [..]
Und wie krieg ich dadurch meine ntfs-Partitionen während des Bootens wieder gemountet?
phen, Tschuldigung ich war gar nicht auf Dich eingegangen, sondern auf das allgemeine Gestöhne über udev ....
Ich habe irgendwo in den letzten Tagen (ich glaube Tumbleweed openSUSE) gelesen, dass ntfs jetzt irgendwo explizit eingetragen werden muss. Das war so eine Liste von Dateisystemen:
ext4
btrfs
vfat
ntfs
Schöne Idee, ralul!
Google brachte direkt entsprechende Einträge, also hatte ich mein System angepasst - nur geholfen hatte es leider nicht. Dieser Ansatz betrifft wohl wirklich nur bei externen USB Platten.
Dann sah ich udev 170, installiert, aber noch immer dasselbe Spiel.
Abschließend hatte ich meine ntfs-Partitionen noch mit Win7 geprüft, scheinbar alles in Ordnung (und da Arch ebenfalls keine Probleme hat glaub ich dem auch).
Da mir das alles allmählich ordentlich gegen den Strich ging hab ich nun formatiert und bin nun dabei ein noch recht aktuelles Backup zurückzusyncen. Hoffentlich komm ich da reibungsfrei durch und kann dieses Thema bald abhaken.
Danke nochmal für Eure Hilfe.
EDIT:
Offenbar hätte ich meine Zeit nicht effizienter verschwenden können. Backup wiederhergestellt, über Umwege grub wieder ans Laufen gekriegt, das MegaD-U gefahren, und.. schon wieder genau derselbe Schlunz.
Vorerst hab ich die Schnauze gestrichen voll, und so werd ich mich nun erstmal auf meine Arch Install konzentriern.