FreeBSD bootfest machen

B

bananenBrot

Well-Known Member
Ich habe ein Problem und zwar fährt FreeBSD nach einem Stromausfall nicht mehr von alleine hoch.
Beim Booten erhalte ich ein
Code: 
WARNING: / was not properly dismounted
init: /bin/sh on /etc/rc terminated abnormally, going to single user mode
Enter full pathname of shell or RETURN for /bin/sh:
Danach muss ich manuell ein fsck durchführen und kann dann wieder booten.

Das Problem: Der Server wird später ca 400km weit weg stehen und da kann ich nicht mal eben ein Konsolenkabel anschließen.

Ich habe bereits in der rc.conf den Eintrag
Code: 
fsck_y_enable=YES
gesetzt, aber der bewirkt scheinbar nichts.

Kann man FreeBSD irgendwie sagen, dass - sofern er meint, dass FS sei nicht nicht ok - selbst ein fsck durchführt?
Oder alternativ irgendwie sagen, dass er das fehlerhafte FS ignorieren soll?

Gruß
 
Klappt es, wenn das YES bei Dir in Anführungsstrichen steht? Also:
Code: 
fsck_y_enable="YES"
 
Ein Stromausfall sollte diesen Fehlerzustand nicht herbeiführen. Wie sicher bist du, dass deine Platten was taugen?
 
Kamikaze schrieb:
Hmm, hast du schon mal über eine USV nachgedacht (Englisch UPS)?
Zum Vergrößern anklicken....
Ja und nein. Eine USV löst das Problem nicht, es verlagert es zeitlich nach hinten. Irgendwann komme ich auch mit USV an oben genanntes Problem.

nakal schrieb:
Klappt es, wenn das YES bei Dir in Anführungsstrichen steht? Also:
Code: 
fsck_y_enable="YES"
Zum Vergrößern anklicken....
Ändert nichts - ich dachte eigentlich, diese Option ist genau dafür gedacht.

Crest schrieb:
Ein Stromausfall sollte diesen Fehlerzustand nicht herbeiführen. Wie sicher bist du, dass deine Platten was taugen?
Zum Vergrößern anklicken....
In wie fern hat das was mit der Platte zu tun?

Hintergrund ist übrigens, dass der Server Teil einer Wetterstation ist, die solarbetrieben mit einer Batterie für 12h im schönen Odenwald steht. Prinzipiell sollte das auch so funktionieren, nur die letzten Winter über ist es öfter vorgekommen, dass dicker Schnee die Solarzelle blockiert hat und durch die Kälte irgendwann die Batterie fertig war. Und das simuliere ich gerade durch ein "Stecker ziehen". Komme ich per SSH dann nicht mehr auf die Maschine, muss ich dann quer durch Deutschland fahren um ein fsck auszuführen.
 
1.) eine USV gibt aber mehrere Signale aus "Netzweg" und danach "langsam mal shutdown einleiten der Ausfall dauert doch länger" ?

2.) wie wäre es denn die root-partition so zu gestalten (logfiles auf eine andere Partition) das die read only gemounted wird ?
a.) für Updates müsste man dann umounten.
b.) welches Dateisystem ggf. mit welchen Einstellungen benutzt Du denn ? "newfs -U -O 2 -j .. ?"

3.) Shutdown bei Batterielow: für Bleiakkus gibt es mit der Spannung einen ziemlich guten Indikator mit dem man einen Shutdown einleiten könnte.
 
Bei so einem Szenario würde ich alles read-only machen, /tmp in tmpfs und /var beim Booten initialisieren so wie es PXE-Boot macht. Oder willst du da dauernd von Remote was aktualisieren?
 
bananenBrot schrieb:
In wie fern hat das was mit der Platte zu tun?
Zum Vergrößern anklicken....
Softupdates halten das Dateisystem zu jedem Zeitpunkt konsistent. Es kann lediglich vorkommen, dass freigegebener Speicherplatz nicht als frei markiert wird. Softupdates Journaling stellt auch dieses sicher. Wenn es nach einem Crash zu weiteren Inkonsistenzen kommt, hat jemand gelogen. Meistens die Platte oder selten der Controller haben die Bestätigung des Ausschreibens zurückgegeben, obwohl die Daten noch im Flug waren...
 
Halten Softupdates das Dateisystem so konsistent, dass es bei einem Neustart ohne unmount immer noch "clean" ist?
Wie finde ich heraus, welche Optionen gesetzt sind? Ich habe die Default-Einstellungen von bsdinstall genommen.

Aber nochmal zum Originalproblem: Ist das nun ein Bug den ich filen sollte? Workarounds wurden ja viele genannt, nur ist ja scheinbar die Funktionaliät von
fsck_y_enable="YES" übrhaupt nicht gegeben
 
bananenBrot schrieb:
Gute Frage. Standardeinstellung für UFS vom Installer. Wie bekomme ich denn Details dazu?
Zum Vergrößern anklicken....
MIt tunefs -p oder dumfps:
Code: 
tunefs -p /
tunefs: POSIX.1e ACLs: (-a)                                disabled
tunefs: NFSv4 ACLs: (-N)                                  disabled
tunefs: MAC multilabel: (-l)                              disabled
tunefs: soft updates: (-n)                                enabled
tunefs: soft update journaling: (-j)                      disabled
tunefs: gjournal: (-J)                                    disabled
tunefs: trim: (-t)                                        enabled
tunefs: maximum blocks per file in a cylinder group: (-e)  2048
tunefs: average file size: (-f)                            16384
tunefs: average number of files in a directory: (-s)      64
tunefs: minimum percentage of free space: (-m)            8%
tunefs: space to hold for metadata blocks: (-k)            0
tunefs: optimization preference: (-o)                      time
tunefs: volume label: (-L)
dumfps ist noch sehr viel detaillierter, zeigt auch blks, cluster und inodes an.
file -s auf den Devicenode ist auch nett, das kann anzeigen, ob das clean flag gesetzt ist.
 
  • Like
Reaktionen: lme
Wie erwartet ist Journaling an - bringt mir aber in dem Fall nichts.
Ich schließe also daraus, dass die rc.conf Option kaputt ist und ich einen Bug filen muss
 
So wird das auch (leider) werden müssen.
Aber mal ehrlich - selbst ein Linux kommt mit nem kaputten FS automatisch wieder zum login prompt - FreeBSD ist bisher das einzige OS, dass dann den Dienst verweigert. Schon merkwürdig.
 
Das von dir beobachtete Verhalten ist völlig korrekt. Du hast Softupdate-Journaling aktiviert. Wenn das Dateisystem nicht sauber geunmounted wurde, wird daher beim nächsten Start automatisch das Journal zurückgespielt. Ob du nun fsck_y_enable="YES" setzt oder nicht völlig egal, denn das wirkt nur im Fall eines vollständigen fsck-Laufs. Dein Problem besteht darin, dass deine Hardware nicht die zugegeben hohen Anforderungen an das Journal erfüllt. Das bleibt das Dateisystem auch nach dem Rückspielen des Journals inkonsistent, was zum Abbruch des Boots führt. Schließlich hat er bereits eine Wiederherstellung des Dateisystems versucht, weshalb er sich hütet noch einen Versuch zu unternehmen. Er würde damit riskieren deine Daten zu schrotten.

Kurz gesagt: Schalte das Journaling ab.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben