FreebSD - Super block critical error -> Dateisystem wird nicht gemounted

serie300

Well-Known Member
Hallo

ich habe eine Dualboot Maschine (FreeBSD und Win auf einer SSD), die seit fast einem Jahr einwandfrei funktioniert hat. Nach dem jetzt erfolgten Windows 24H2 Update - Win hat dabei an der Maschine "rumrepariert" , das Troubleshooting Dnges aus Win, weil es Win11 nach dem Setup beim erstenmal nicht booten konnte - kann ich FreeBSD nicht mehr durchbooten.
Fehler: "Critical Superblock error" , wenn der Boot Prozess versucht das Dateisystem zu mounten.
Also: Maschine bootet via UEFI Bootselector in den FreeBSD Splash Screen, der Boot geht dann auch los und wenn er versucht "/" zu mounten kommt der Superblock error.
Wenn ich dann "ufs:/dev/nda0p6" (wie im Log angegeben) eingebe, gibt es den gleichen Fehler (Dateisystem ist UFS". FreeBSD an sich ist dann ohne mein / Filesystem gebooted. Ich bekomme z.B. die entsprechende (Treiber) Meldung, wenn ich ein USB Gerät einstecke. Das Intel SSD Beschleunigung Dingens (VMD) ist im BIOS abgeschaltet.

Was könnte da passiert sein und wie kann ich wieder booten ?

HW: Laptop mit Intel "Pentium 8085 8505" SOC und dessen integrierter HW
 
Zuletzt bearbeitet:
Hallo

ich habe eine Dualboot Maschine (FreeBSD und Win auf einer SSD), die seit fast einem Jahr einwandfrei funktioniert hat. Nach dem jetzt erfolgten Windows 24H2 Update - Win hat dabei an der Maschine "rumrepariert" , das Troubleshooting Dnges aus Win, weil es Win11 nach dem Setup beim erstenmal nicht booten konnte - kann ich FreeBSD nicht mehr durchbooten.
Fehler: "Critical Superblock error" , wenn der Boot Prozess versucht das Dateisystem zu mounten.
Also: Maschine bootet via UEFI Bootselector in den FreeBSD Splash Screen, der Boot geht dann auch los und wenn er versucht "/" zu mounten kommt der Superblock error.
Wenn ich dann "ufs:/dev/nda0p6" (wie im Log angegeben) eingebe, gibt es den gleichen Fehler (Dateisystem ist UFS". FreeBSD an sich ist dann ohne mein / Filesystem gebooted. Ich bekomme z.B. die entsprechende (Treiber) Meldung, wenn ich ein USB Gerät einstecke. Das Intel SSD Beschleunigung Dingens (VMD) ist im BIOS abgeschaltet.

Was könnte da passiert sein und wie kann ich wieder booten ?

HW: Laptop mit Intel "Pentium 8085" SOC und dessen integrierter HW

Am schnellsten hilft wohl: Das Image der SSD, welches man vor dem H2 Update gemacht hat, wieder einspielen ;)
Sollte das aus welchen Gründen auch immer nicht möglich sein: Probier mal von nem LifeStick die UFS Partition zu mounten. Ich denke eigentlich nicht, dass Win fremde Partitionen anfasst.
 
Kannst du von nem Live-System boooten und versuchen die Patition zu mounten?

Welches Dateisystem und welche verschlüsselung hat die FreeBSD / Partition?

Kannst du aus dem Windows-Log herausprökeln was da wie versucht wurde zu reparieren?

Was hat Windows da genau gemacht? Es gibt ja verschiedene "Dinge" die Windows da evtl. teil-automatisiert macht (War da ein eingreifen von dir selbst erforderlich?

Hast du damals beim Partitionieren dadrauf geachtet das die partition als FreebSD in der GPT magiert ist? Ist es überhaupt GPT oder noch MBR?

HW: Laptop mit Intel "Pentium 8085" SOC und dessen integrierter HW
Etwas nitpicking, aber google kennt keinen Pentium 8085 und spuckt den hier aus: https://de.wikipedia.org/wiki/Intel_8085 :)
 
Anscheinend wurde der Superblock von UFS beschädigt (wodurch auch immer). Zum Glück gibt es vom Superblock Kopien.
Wenn Du ein bootbares FreeBSD-Medium (Install-Medium) zur Hand hast, kannst Du ja mal davon booten und dann in die Kommandozeile wechseln und ein fsck auf dem betroffenden Medium machen:
fsck_ufs /dev/nda0p6

Sollte das auch nicht funktionieren und er die alternativen Superblock-Kopien nicht automatisch finden, kannst Du sie auch dezidiert angeben. Man muss dann natürlich wissen, wo die sind. newfs zeigt die Blocknummern an, wenn man ein UFS-Dateisystem anlegt. Neu anlegen wollen wir natürlich nicht, Aber mit dem Parameter -N kann man ein Neuanlegen simulieren:
newfs -N /dev/nda0p6

Dann gibt er einem die Blöcke aus, wo die Superblock-Kopien gespeichert sind. Da probiert man halt durch und versucht erneut ein fsck:
fsck_ufs -b 12345 /dev/nda0p6
(für 12345 natürlich die entsprechende Blocknummer eingeben)

Das fixt zumindest die Superblock-Geschichte. Dann bleibt nur zu hoffen, das das das war und nicht noch mehr kaputt ist.

btw: empfiehlt sich immer ein Image zu machen, bevor man Reparaturversuche startet, weil Reparaturversuche potentiell was kaputt machen können und dann ist es gut, wenn man einen Schritt zurück gehen kann.
 
Danke für die Antworten. habe gerade kein Install medium, da ich unterwegs bin... Dauert also ein bisschen, bis ich weiteres vermelden kann Ist ein Pentium 8505 und nicht 8085...
 
So , bin jetzt einen Schritt weiter.
Mit der Angabe ufs:/dev/nda0p5 (stur durchprobieren ist auch eine Lösung) bootet der Rechner. Irgendwas ist da anscheinend an den partitionen verschoben / gelöscht worden...

Wie bringe ich das jetzt dem Bootloader bei ? ( sodaß ich es nicht jedesmal von Hand eingeben muß)
 
Normalerweise sucht sich der Loader automatisch die passende Partition. Deshalb war ich auch gar nicht davon ausgegangen, das die Partition lediglich "verschoben" ist.
Wie sieht den die Partition-Tabelle aus? (gpart show)
 
gpart show zeigt natürlich, was nun ist und nicht, wie es zuvor gewesen war.
Wie es zuvor gewesen war, wäre nun aber echt hilfreich zu wissen.

Mir fällt auf, dass es mehrere ms-recovery-Partitionen gibt.
Mein Win10 in einer VM hatte damit massive Probleme, dass es bei irgendeinem Update diese Partition benutzen wollte und sie zu klein geraten war. In der VM konnte ich relativ leicht mittels diskpart und co (Anleitung im Netz gefunden), die Partitionsgröße anpassen, bzw die Partitionen insgesamt.
Bei dir vermute ich, dass unterschiedliche Updates unterschiedliche Partitionen angelegt haben und das ist in meinen Augen sehr ungescheit.

Deshalb denke ich auch, dass
Schau mal, ob der Mountpoint für / in der fstab korrekt angegeben ist. IMHO hat nicht der loader ein Problem, sonst würde er den Kernel nicht finden.
am ehesten zu deinem Problem passt und nicht wirklich das Dateisystem korrupt ist, was die Fehlermeldung ja eigentlich sagt. Es ist wohl eher so, dass dort, wo nachgeschaut wird, gar kein UFS liegt und deshalb natürlich dieses auch als korrupt erkannt wird.

Aus FreeBSD-Sicht, würde ich deshalb in der fstab UUIDs statt Device-Einträgen nutzen oder lieber noch geom-labels. Das ist stabiler gegenüber Machenschaften anderer Betriebssysteme, die einfach mal Partitionstabellen ändern.
Aus Windows-Sicht würde ich die vielen recovery-Partitionen in eine einzige überführen, groß genug, am Ende der Tabelle und die Zwischenlösungen einfach löschen.
Achtung: Dabei droht natürlich Datenverlust!!!

Viel bequemer in meinen Augen ist es jedoch, gar kein Dual-Boot zu benutzen, sondern nur noch FreeBSD (meine Sicht, steht aber für ein einziges System, egal welches) und alle weiteren Systeme einfach in einer Virtuellen Maschine zu platzieren.
 
Danke für die Unterstützung.
Habe jetzt die fstab angepasst und es läuft wieder.
:ugly:
Naja, Miniweich ist anscheinend der Ansicht meine Platte gehört ihnen und irgendwelche Meldungen sind nur Zeitverschwendung.
 
Ich würde da gar nichts manipulieren, es muss ja einen Grund haben, warum sich das Partitionsschema geändert hat.
das wissen wir zunächst bisher ja noch gar nicht, vielleicht ist es ja von "Anbeginn der Zeiten" immer schon so gewesen.
In meinem Fall in einer VM hatte sich Windows 10 so verhalten, dass es zunächst eine kleine recovery-Partition angelegt hatte und als die nicht ausreichte, streikte es.
Das heißt, das war eine VM mit Legacy-Boot.
Eine andere, in der ich EFI eingerichtet hatte, wurde bei dem gleichen Update einfach zerlegt, ich war also nicht mehr in der Lage, diese zu benutzen.
Im Fazit blieb ich auf Legacy und dann ist es deutlich komplexer, beliebig zusätzliche Partitionen anzulegen und ich bin da nicht zum ersten Mal darüber gestolpert, dass der Update Mechanismus von Windows recht dumm und blind agiert.
Legt man Hand an, ist er durchaus mit "besserer" Aufteilung der Platte in Partitionen zufrieden und nutzt diese dann auch. Oder eben nicht, denn eigentlich braucht man keine recovery-Partition für Windows und es läuft trotzdem.

Aus meiner bescheidenen Erfahrungen heraus lohnt es sich, hier zu experimentieren, natürlich unter angesagter Vorsicht gegenüber Daten- und System-Verlust.
 
Also normal ist das nicht, was ihr hier mit Windows schildert.

Ich kenne so einige ecken und kanten dieses doch recht eigenartigen Betriebsystems (Naja ich verdiene ja auch zt mein Geld als Windows-Admin) - und einfach so irgendwas am Partitionsschema wechseln ist mir da bislang noch nicht untergekommen.

Schau doch mal in das Windows-LOG was da genau passiert ist, damit sich so ein Fehler evtl. nicht wiederholt.
 
Habe mit jetzt die Win "Ereignisanzeige" (oder wie das heißt) angeschaut. Ich finde nichts mit Bezug zu Partitionen, außer das im Log beim Update mehrere Partitionen als "Gut" geprüft weden.
 
Zurück
Oben