staging.inyokaproject.org

"Falscher" fstab-Eintrag stoppt Systemstart?

Status: Gelöst | Ubuntu-Version: Kein Ubuntu
Antworten |

thom_raindog

Avatar von 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)
Avatar von thom_raindog

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

Avatar von k1l

Anmeldungsdatum:
22. September 2006

Beiträge: 1253

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)
Avatar von thom_raindog

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

Avatar von user_unknown

Anmeldungsdatum:
10. August 2005

Beiträge: 17630

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)
Avatar von thom_raindog

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

Avatar von 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

Avatar von k1l

Anmeldungsdatum:
22. September 2006

Beiträge: 1253

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 😉 )

Antworten |