System bootet nicht mehr nach Crash

C

cabriofahrer

Well-Known Member
Frischinstallation von FreeBSD 10.1 auf einen Notebook, alles lief einwandfrei, bis während des Betriebs der Akku leer ging und das Notebook natürlich sofort ausging. Seitdem bootet das System nicht mehr, auch nach mehreren fsck bekomme ich immer nur das hier (siehe Bilder):
 

Anhänge

  • pic1.jpg
    pic1.jpg
    768,8 KB · Aufrufe: 319
  • pic2.jpg
    pic2.jpg
    754,4 KB · Aufrufe: 299
Nun, offensichtlich ist der Kernel auf der Platte kaputt. Von vorne anfangen, Du weißt ja nicht was sonst noch so kaputt ist.
 
Mittlerweile bin ich nochmal in den Single User Mode gegangen, und habe dort ein "fsck -f" durchgeführt und alle Fragen mit "y" beantwortet. Danach kam die Meldung "Filesystem still dirty, run another fsck" oder so ähnlich. Nachdem ich dann nochmal "fsck -f" durchgeführt habe, kam dann schließlich die Meldung "Filesystem marked clean" und das System bootet wieder korrekt. Habe aber bis jetzt noch nicht verifiziert, ob irgendetwas verloren gegangen ist oder nicht mehr funktioniert.

Gibt es nicht auch die Möglichkeit, diesen gründlichen fsck in der rc.conf standardmäßig einzustellen? Warum ist das nicht sowieso der Fall? Wäre das nicht von Vorteil für den Fall, dass ein unerfahrener Benutzer den PC handhaben muss? Nur aus Neugier: Wie reagiert denn Windows/NTFS bei einem plötzlichen Ausbleiben der Stromversorgung?
 
Ja, das kannst Du einstellen, aber was der Default ist hängt von der Partition ab. Nur bei / ist ein Foreground-fsck voreingestellt. Auch bei mir sind eigentlich immer 2 Durchgänge nötig, deshalb ist das Blödsinn.

Du kannst übrigens fsck -y verwenden damit Du nicht jede Frage einzeln abnicken musst. Was will man da auch sonst machen? Am wichtigsten ist immer das Backup.
 
Nichts. Die etwas pauschalisierte Sache ist: UFS ist in all seinen Flavors darauf angewiesen, dass die Hardware die Wahrheit sagt. Das also "Ich habe alles auf Festplatte geschrieben" (müsste in FreeBSD BIO_FLUSH sein) auch genau das bedeutet und nicht, dass die Daten doch noch in irgendwelchen Caches rumoxidieren. Softupdates überleben lügende Hardware meist relativ gut, es gibt beim fsck halt nur Gemecker. Journaled Softupdates sind extrem anfällig. Das System denkt die Dateisysteme seien nach dem Rückspielen des Journal konsistent, in Wirklichkeit sieht es ein wenig anders aus. Die Folge sind dann Panics. gjournal war der Versuch ein weitgehend dateisystemagnostisches Journaling zu implementieren. Für es gilt im Prinzip das gleiche wie für Journaled Softupdates, nur das es statt ausschließlich Metadaten auch noch Nutzdaten zerschießen kann.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben