thom_raindog
Anmeldungsdatum: 20. Mai 2005
Beiträge: 2848
|
Moin, ich quäle mich grade mit meinem Raspberry und einer wohl defekten externen-HD. Was mir da auffällt: Sobald ich die HD in der fstab mounte, bricht der Bootvorgang ab (a start job is running for dev-sda1.device....). Und das selbst bei "harmlosen" Einträgen in der fstab wie schlicht "Defaults". Ich bin da vielleicht nicht so firm was die fstab angeht, aber kann man das nicht so einrichten, dass eine nicht funktionierende oder fehlende Partition dann schlicht übersprungen wird? Ich meine, es geht hier ja nicht um / oder /home oder sonstwas systemkritisches.... Danke für jeglichen Input schonmal.
|
unbuntuS12
Anmeldungsdatum: 2. Juni 2010
Beiträge: 1816
|
Jein. Du kannst du option "noauto" setzen. Dann wird das Gerät nur manuell gemountet, wenn du # mount /path/to/mnt aufrufst. Syntaktisch muss die Zeile aber weiterhin korrekt sein. Noch besser wäre es allerdings, den Fehler an sich zu beheben. Poste doch mal deine fstab und die Ausgabe von sudo mount -a
|
thom_raindog
(Themenstarter)
Anmeldungsdatum: 20. Mai 2005
Beiträge: 2848
|
Kann ich grade nicht, weil mein Raspberry ja eben nicht bootet. Ich muss erst mit der Tastatur zum Server dackeln, dort aus der Notfallkonsole heraus die Fstab anpassen, dann neustarten, hossa. Ich poste, sobald ich das kann (offiziell "arbeite" ich grade 😉 )
|
k1l
Anmeldungsdatum: 22. September 2006
Beiträge: 1253
Wohnort: Köln
|
Das ist ein riesen Problem, seit der Umstellung von Upstart auf Systemd. IMHO sollte sich ein Init-System nicht von so etwas stoppen lassen.
|
thom_raindog
(Themenstarter)
Anmeldungsdatum: 20. Mai 2005
Beiträge: 2848
|
So sieht aktuell die fstab aus:
UUID=855a8056-b087-45e2-90d6-ce404b00fbbb /media/pi/Cloud-storage ext3 defaults 0 2 Die UUID stimmt sicher.
Wie gesagt, die HD ist ziemlich sicher Schrott, was ja an sich kein Thema ist. Uncool finde ich an der Stelle einfach, dass das System überhaupt nicht mehr bootet, obwohl die HD nun wirklich in keinem wichtigen Verzeichnis hängt. "noauto" hieße aber, die Platte stünde nach dem Boot nicht als Massenspeicher für Cloud bzw Wiki zur Verfügung, richtig? Ich hab noch was über "nofail,x-systemd.device-timeout=1" gelesen, wodurch wohl zum einen das Warten abgekürzt würde, und - so meine Hoffnung - auch bei nicht vorhandener HD der Bootvorgang weiterliefe. DAS wäre ja was ich suche...
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Ich hatte mal Probleme, bei denen dann eingeblendet wurde, man könne "s" für "skip" drücken, die aber nicht zuverlässig eingeblendet wurden. Ob das bei Dir auch der Fall ist, ist fraglich - probieren könntest Du es.
|
thom_raindog
(Themenstarter)
Anmeldungsdatum: 20. Mai 2005
Beiträge: 2848
|
Das oben erwähnte nofail,x-systemd.device-timeout=1
in der fstab wirkt in der Tat Wunder. ☺ Boot läuft durch, ob mit oder ohne HD, und nach Einsatz einer neuen HD klappert auch alles andere endlich ☺
|
V0LKER
Anmeldungsdatum: 23. Februar 2014
Beiträge: 1967
|
k1l schrieb: Das ist ein riesen Problem, seit der Umstellung von Upstart auf Systemd. IMHO sollte sich ein Init-System nicht von so etwas stoppen lassen.
Das war aber schon immer so, selbst beim alten init hatte ich da stopper.
|
luge86
Anmeldungsdatum: 26. Januar 2012
Beiträge: 201
|
V0LKER schrieb: Das war aber schon immer so, selbst beim alten init hatte ich da stopper.
Es war mir vor 1-2 Jahren definitiv möglich, meinen Raspi2 hochzufahren auch wenn der USB-Stick, der per fstab gemountet wird nicht angeschlossen war. Als ich irgendwann auf "Jessie" umgestiegen bin ging das nicht mehr und hat mich einiges an Zeit gekostet.
(Unschönerweise wird nämlich der ssh-Server dann auch nicht gestartet und ich hatte keine Chance herauszufinden, wo's denn hängt. Als ich den Headless-Pi dann ins Wohnzimmer bugsierte und an den TV stöpselte war die Sache klar und einfach zu beheben. Ohne Monitor/Tastatur ist der Pi aber mangels ssh in einem Zustand, aus dem nur noch ein harter Power-Off-Reset raushilft.)
|
k1l
Anmeldungsdatum: 22. September 2006
Beiträge: 1253
Wohnort: Köln
|
V0LKER schrieb: k1l schrieb: Das ist ein riesen Problem, seit der Umstellung von Upstart auf Systemd. IMHO sollte sich ein Init-System nicht von so etwas stoppen lassen.
Das war aber schon immer so, selbst beim alten init hatte ich da stopper.
Nicht in dem Umfang, wie Systemd da Theater macht.
|
luge86
Anmeldungsdatum: 26. Januar 2012
Beiträge: 201
|
k1l schrieb: Nicht in dem Umfang, wie Systemd da Theater macht.
Fairerweise darf man das aber nicht systemd anlasten sondern eher denjenigen, die die systemd-Regeln für Raspbian formuliert haben.
Ich bin mir sicher es gibt Alternativen zu dem aktuellen Szenario.
(Und man könnte doch bitte den ssh Server trotzdem starten 😉 )
|