extra Festplatte auf /var und rasbian bootet nicht mehr

[egerlach]

Hallo,
habe rasbian (debian für raspberry, arm) auf eine raspi und dann /var/ auf eine externe USB-SSD-Festplatte (ext4) kopiert (nicht verschoben!). Dann per

Code: Alles auswählen

/dev/sda2          /var/        ext4   defaults     0     0

in der fstab eingehängt, Rebootet, geht!
Wenn ich den raspi OHNE eingesteckte USB-Festplatte boote, bleibt der Bootvorgang bei dem Einhängen von /var/ stehen: /dev/sda2 nicht gefunden. Warum? mit "0 0" am Ende der Zeile in fstab ist das Einhängen doch optional!?!
Kommentiere ich die Zeile in der fstab aus, dann startet der raspi ohne USB-Festplatte wie gewohnt.

Mounte ich /dev/sda1 nach /mnt in fstab (ntfs-Dateisystem), dann stört das den raspi (rasbian) nicht, wenn die USB-Festplatte nicht steckt.

Warum bleibt rasbian nur bei /var/ hängen? Warum überhaupt, wenn mit "0 0" doch optional?

Gruß
Eckard

[hikaru]

Die Nullen am Ende der Zeile machen nicht das Mounten Optional, sondern sie verhindern nur, dass:
1. vom Dateisystem mittels dump ein Backup erstellt wird, und
2. dass das Dateisystem auf Fehler überprüft wird.

Soweit mir bekannt, gibt es über die fstab keine Möglichkeit, für optionales Mounten. Das Fehlen eines in der fstab aufgeführten Datenträgers führt in jedem Fall zum Fehler. Vor der Einführung von Systemd waren diese Fehler aber immerhin nicht fatal für den Bootprozess. Mit Systemd sind sie es.

[eggy]

manpage von fstab sagt:

noauto Nicht automatisch einhängen, wenn »mount -a« aufgerufen wird (z. B. beim Hochfahren)

[hikaru]

manpage von fstab sagt:

noauto Nicht automatisch einhängen, wenn »mount -a« aufgerufen wird (z. B. beim Hochfahren)

/var wird man automatisch einhängen wollen, wenn es auf einer eigenen Partition liegt. Dort liegen für den Betrieb wichtige Dateien. Deshalb halte ich das Ziel, /var optional zu mounten für zweifelhaft, denn wenn der Datenträger mal da ist und mal nicht, dann führt das zu inkonsistenten Inhalten in /var.

[eggy]

Klar braucht man /var beim booten, steht doch außer Frage. Aber er hatte ja extra geschrieben, dass er die Daten kopiert hat. D.h. wenn der Eintrag in der fstab beim booten nicht ausgewertet wird, sind die Daten auf der sd noch da, /var ist wie üblich gefüllt und die Kiste sollte ganz normal durchbooten können.

[hikaru]

Aber welchen Sinn soll dann die Option noauto haben? Klar, damit kann man das /var auf der HDD nachträglich von Hand einhängen. Das ergibt für mich aber keinen Sinn, denn genau dadurch entstehen Inkonsistenzen, nicht nur zwischen Boots sondern innerhalb einer Session.
Vielleicht könnte man das Ganze über eine Systemd-Unit erschlagen, die noch vor dem Mounten von irgendwas prüft, ob die HDD angeschlossen ist und dann /var mountet oder nicht. Aber das müssen andere bewerten.

[MSfree]

Aber er hatte ja extra geschrieben, dass er die Daten kopiert hat.

Und dann machst du einmal apt-get update mit externer Platte und schon stimmen "internes" /var und "externes" var nicht mehr überein. Damit kann man sich ganz hervorragend seine Installation bis zur Unreparierbarkeit zerbröseln.

Es ist eine ganz blöde Idee, /var auf einem Datenträger zu speichern, der nicht zuverlässig am System hängt.

[egerlach]

Ich danke für die zahlreichen Beiträge. Wo möglichst früh im Bootprozess könnte ich das mounten von /dev/sda2 auf /var selbst machen, anstelle von fstab-Eintrag?

Wen es interessiert, die näheren Hintergründe:
Der raspi läuft als Server in einem Betrieb. Sollte die USB-Festplatte mal ausfallen, dann bootet die Kiste nicht mehr das ist ärgerlich! Wenn sie im "Notfall" wenigstens mit dem alten "var" nochmals booten würde, wäre das sehr hilfreich um Fehler zu finden. Auf /var/www/ und /var/XXX liegen übrigens die Programme und Daten, die aber auch jede Nacht auf anderen raspi gesichert werden.
Im übrigen kopiere ich gelegentlich das /var/ von der externen Festplatte auf das /var der microSD-Karte (in dem ich mit auskommentiertem /dev/sda2 .... in der fstab reboote, dann sda2 auf /mnt einhänge ). Somit ist das /var/ immer recht aktuell und kann im Notbetrieb bei ausgefallener Festplatte den Betrieb aufrecht erhalten - WENN der rasbi-Server wenigstens hochfahren würde wenn die externe Festplatte ausfällt!! tut er aber leider nicht, wenn die /var/ in fstab eingehängt ist. Mist! Da die externe Festplatte aber vermutlich nie ausfällt, will ich eigentlich nicht mit irgendwelchen "noauto" -Basteleien anfangen, oder überhaupt kein mount in der fstab, alles manuell drüber'mount'en. Da mir aber nichts anderes als das übrig bleibt, wo an welcher frühen Stelle im Bootprozess kann ich /dev/sda2 selbst auf /var/ einhängen?
PS: warum ich überhaupt eine externe SSD-Festplatte auf /var einhänge? Eine microSD-Karte ist schnell am Ende, wenn sie ständig beschrieben wird, alle Daten die der raspi-Server liefert, liegen auf /var/www/... und anderen /var/dataXY/ , außerdem ist eine SSD schneller als eine microSD-Karte.

[MSfree]

Auf /var/www/ und /var/XXX liegen übrigens die Programme und Daten, die aber auch jede Nacht auf anderen raspi gesichert werden.

In dem Fall würde ich aber ganz anders vorgehen.

Laß /var einfach auf der SD-Karte.

Der Webserver, der per Default von /var/www aus arbeitet, kann auch umkonfiguriert werden, so daß er von einer anderen Stelle seine Webseiten ausliefert. Gleiches gilt für dein /var/XXX.

Erstelle ein neues Verzeichnis unter /, ich nehme dafür in der Regel /pub.
Mounte deine externe Platte auf /pub mit entsprechendem Eintrag in der fstab. Und, nein, ich würde die externe Platte nicht unter /media mounten, weil sich da der Automounter austobt.

Kopiere /var/www nach /pub/www, gleiches für XXX.

Konfiguriere den Webserver so um, daß er seine Seiten von /pub/www ausliefert statt /var/www.

Damit hast du die externe Plate von /var unabhängig gemacht und die Kiste bootet auch ohne die externe Platte.

[hikaru]

Wo möglichst früh im Bootprozess könnte ich das mounten von /dev/sda2 auf /var selbst machen, anstelle von fstab-Eintrag?

Das ganze mount-Geraffel macht Systemd. Die /etc/fstab ist im Grunde nur noch eine Hilfskonfigurationsdatei aus der die eigentlichen mount-Units generiert werden. Die fstab könnte man sich also eigentlich sparen, wenn man die mount-Units anders generiert.
So wirklich durchschaut habe ich das selbst noch nicht, aber schau dich mal in /run/systemd/generator um! Dort wirst du mount-Units für alle deine fstab-Einträge finden. Der entscheidende Punkt ist wohl, dass jede aus der fstab generierte Unit im Unterverzeichnis local-fs.target.requires erscheint, womit ihr Versagen zum Stoppen des kompletten Boot-Prozesses führt. Du möchtest deine Unit wohl eher in local-fs.target.wants haben.
Wie du sie dort hinbekommst - noch dazu auf sinnvolle Weise - weiß ich nicht.

Im Übrigen halte ich es für weitaus wahrscheinlicher, dass deine µSD-Karte stirbt, als dass deine HDD stirbt - insbesondere wenn du viel darauf schreibst (/var).

Auf meinem Cubieboard2 habe ich ein ähnliches Setup: µSD + HDD
Allerdings kommt bei mir von der µSD wirklich nur /boot, weil das CB2 nicht von HDD booten kann. Alles Andere liegt aber auf der HDD.

[egerlach]

Konfiguriere den Webserver so um, daß er seine Seiten von /pub/www ausliefert statt /var/www.
Damit hast du die externe Plate von /var unabhängig gemacht und die Kiste bootet auch ohne die externe Platte.

OK, danke, eine neue Variante. Allerdings schreibt debian ständig auf /var/ herum. Das macht die microSD-Karte kaputt. Also bräuchte ich für /var/ wieder eine Lösung in Form einer stabilen Partition, die ich da einhänge, z.B. /dev/sda3 - und dann habe ich das alte Problem wieder: gibts ein Problem mit der USB-Festplatte, dann bootet die Kiste nicht.

Ich bin sicher, dass ein Profi dieses zwanghafte "einhängen-wollen" von /var/ in der fstab abschalten kann. Es scheint ja extra so programmiert zu sein, dass die fstab nach systemrelevanten Verzeichnissen wie /var/ , /usr, ... durchsucht wird und die sollen unbedingt eingehängt werden. Dieses Programm-Schnipsel muss weg. Wer weiss wie ich daran komme?
@im 5 Minuten zuvor erschienenen Beitrag von hikaru (direkt oberhalb) ist das schon beschrieben, ich war gerade am schreiben meines Beitragen hier, Danke hikaru!

PS: der nächste Rasbi wird sicherlich eine kleine 60GB-SSD onboard haben, oder als auf die Platine aufsteckbares Modul, das fehlt dem Raspi noch.

[MSfree]

Allerdings schreibt debian ständig auf /var/ herum. Das macht die microSD-Karte kaputt.

Nein, da wird nicht "ständig" geschrieben. Davon abgesehen, so schnell geht eine SD-Karte nicht kaputt. Die sterben eher eine Tod durch elektrostatische Entladung, als daß sie kaput geschrieben werden. Das Bißchen, das durch Logging und apt-get geschrieben wird, macht SD-Karten auf keinen Fall kaputt. Und /var/run ist eine RAM-Disk, landet also nicht auf der SD-Karte.

Ausserdem kann man die SD-Karte regelmässig klonen, um im Zweifelsfall schnell Ersatz durch Austausch parat zu haben.

[hikaru]

PS: der nächste Rasbi wird sicherlich eine kleine 60GB-SSD onboard haben, oder als auf die Platine aufsteckbares Modul, das fehlt dem Raspi noch.

Das glaube ich nicht. Ich habe mir seinerzeit das CB2 u.A. deshalb gekauft, weil der RPi keine sinnvolle Schnittstelle für Massenspeicher hatte. Das CB2 hat einen SATA-Anschluss.

Nein, da wird nicht "ständig" geschrieben.

In /var/log schon. Ich sehe das an der HDD-LED meines Notebooks, die etwa im Sekundentakt blinkt. Lege ich /var/log in ein tmpfs ist die LED deutlich ruhiger.

Davon abgesehen, so schnell geht eine SD-Karte nicht kaputt. Die sterben eher eine Tod durch elektrostatische Entladung, als daß sie kaput geschrieben werden.

Ich habe in 6 Jahren eine meist zu ca. 50% gefüllte 64GB-µSD in meinem Handy kaputtgeschrieben. Dort lief u.A. sporadisch ein Debian-chroot, außerdem permanent eine Swap-Partition für das Host-System. Durch statische Aufladung habe ich noch keine zerstört.

[egerlach]

Nein, da wird nicht "ständig" geschrieben. Davon abgesehen, so schnell geht eine SD-Karte nicht kaputt. Die sterben eher eine Tod durch elektrostatische Entladung, als daß sie kaput geschrieben werden. Das Bißchen, das durch Logging und apt-get geschrieben wird, macht SD-Karten auf keinen Fall kaputt. Und /var/run ist eine RAM-Disk, landet also nicht auf der SD-Karte.

Was ich noch nicht geschrieben habe, ist dass der Raspi auch Faxserver ist, täglich gehen durchschnittlich 20 Faxe ein und 5 gehen raus. Das zusammen mit dem fax-log (gut, ich könnte ich den weniger 'gesprächigen' Faxempfangs-Modus 444 konfigurieren) erzeugt dann doch mehr traffic auf /var/spool/hylafax und /var/log. Ich könnte /var/log und /var/spool dann je auf eine externe Partition legen (die werden vom systemd sicherlich nicht zwanghaft eingehängt), dann macht die Restaktivität in /var die microSD sicherlich nicht kaputt. Das alles habe ich mir vor Auslieferung des raspi-Servers auch schon überlegt. Dann bräuchte ich aber schon mal 3 Partitionen auf /dev/sda (externe Festplatte), was alles nicht übersichtlicher macht. Allerdings wusste ich damals noch nicht von dem zwanghaften Einhängen-wollen von /var/ in fstab.
Jetzt habe ich also drei Alternativen:
1. selbst /var im Bootprozess einhängen, ohne fstab
2. Den systemd unter die Lupe nehmen und das zwanghafte Einhängen von /var/ ausschalten (/run/systemd/generator, ...)
3. /var auf der microSD-KArte lassen, Daten und www auf /externeFestplatte-Partition/ verschieben , und /var/spool/ und /var/log auf jeweils extra-Paritionen der externen FP

Ich tendiere dazu den systemd auf die Finger zu sehen ... dann kann ich auch alles lassen wie es bisher ist.

Weitere Varianten?

[JTH]

Habe mir nicht alles im Detail durchgelesen, nur als Einwurf zu Ausgangsfrage:

2. Den systemd unter die Lupe nehmen und das zwanghafte Einhängen von /var/ ausschalten (/run/systemd/generator, ...)

nofail wäre die Option für die fstab, um fehlschlagendes Mounten wegen fehlendem Device zu ignorieren:

nofail do not report errors for this device if it does not exist.

Die Option gabs auch schon lange vor systemd.


Wenn ich man systemd.mount richtig verstehe, sollte man bei nofail im Zusammenspiel mit systemd noch Folgendes ergänzen:

Code: Alles auswählen

nofail,x-systemd.before=local-fs.target

Da systemd einen Mount mit nofail nicht mehr vor local-fs.target einsortiert.

[MSfree]

In /var/log schon. Ich sehe das an der HDD-LED meines Notebooks, die etwa im Sekundentakt blinkt. Lege ich /var/log in ein tmpfs ist die LED deutlich ruhiger.

Unter Raspian ist das Journal nicht persistent per Default, die loggen also in die RAM-Disk.

Swap sollte man allerdings lieber nicht auf SD-Karte haben. Aber den kann man ja auch auf der externen Platte anlegen (oder ganz abschalten) und den Default-Swap von Raspian, der auf einer Datei unter /var liegt, abschalten.

[mludwig]

In der fstab gibt es noch die Mount-Option nofail, damit wird der Mountvorgang übersprungen, wenn es das Device nicht gibt ... wird auch von systemd umgesetzt.

[JTH]

In der fstab gibt es noch die Mount-Option nofail, damit wird der Mountvorgang übersprungen, wenn es das Device nicht gibt ... wird auch von systemd umgesetzt.

Siehe zwei Beiträge über deinem

[MSfree]

In der fstab gibt es noch die Mount-Option nofail, damit wird der Mountvorgang übersprungen, wenn es das Device nicht gibt ... wird auch von systemd umgesetzt.

Siehe zwei Beiträge über deinem

nofail ist in diesem Fall aber eine ganz blöde Idee. Nochmal, /var beinhaltet die Daten für die Paketverwaltung. Wenn man aber Pakete und Updates teilweise von der internen SD-Karte verwalten läßt, weil die externe Platte gerade nicht eingebunden werden kann, auf der externen Platte aber der eigentlich aktuelle Stand der Paketverwaltung steckt, hast du hinterher eine System, das schlicht und ergreifend fubar ist.

Daher sollte man in diesem Fall tunlichst die Finger von der Idee lassen, die externe Platte auf /var zu mounten.

[JTH]

Nochmal, /var beinhaltet die Daten für die Paketverwaltung.

Wer braucht schon /var/lib/dpkg Aber ja, /var komplett je nach Verfügbarkeit extern zu mounten ist eine sehr blöde Idee. Außer vielleicht man hat ein System, das komplett read-only ist und keine Installation zulässt.

Ich war irgendwie der Meinung, es ging hier ursprünglich um /var/www.

[egerlach]

In der fstab gibt es noch die Mount-Option nofail, damit wird der Mountvorgang übersprungen, wenn es das Device nicht gibt ... wird auch von systemd umgesetzt.

Danke! Lese es jetzt erst richtig: "noauto" und "nofail" sind zweierlei ... GENAU DAS: "nofail" suche ich, werde ich gleich testen.

Siehe zwei Beiträge über deinem

nofail ist in diesem Fall aber eine ganz blöde Idee. Nochmal, /var beinhaltet die Daten für die Paketverwaltung. Wenn man aber Pakete und Updates teilweise von der internen SD-Karte verwalten läßt, weil die externe Platte gerade nicht eingebunden werden kann, auf der externen Platte aber der eigentlich aktuelle Stand der Paketverwaltung steckt, hast du hinterher eine System, das schlicht und ergreifend fubar ist.

Danke für diesen wichtigen Hinweis: dessen bin ich mir bewusst! Wenn das richtige, (etwas!) aktuellere /var/ nicht gemountet ist, und der raspi hochfährt, dann weiss ich wenigstens, dass der raspi nicht abgeraucht, Netzwerk in Ordnung ist (Switch ausgefallen?) oder das Netzteill des Raspi defekt ist/ Stecker rausgeflutscht, oder ... oder ... ! DARUM geht es mir!!!Dann könnte ich als Notbetrieb die zum Betrieb notwendigen Daten von einer Sicherung nach /var/www/ , /var/komsys/, /var/samba/ auf die microSD-Karte kopieren und mein Kunde kann im Notbetrieb an diesem Tag weiter arbeiten, bis ich die 150km angefahren bin und dann nachsehe, was mit der USB-Festplatte nicht in Ordnung ist, Ersatz installieren/ Raspi tauschen, microSD-Karte auf jeden Fall erneuere, etc. ALSO: nur Notbetrieb für ein paar Stunden bis zu einem Tag!

Übrigens, wie schon vorher von mir erwähnt: das /var/ der microSD-karte veraltet nicht, es wird von mir immer nach install neuer Pakete (geplant alle 3 Monate) auf /var/ mit eingehängter USB-Festplatte aktualisiert , indem ich reboote, vorher den mount in fstab auf /var/ auskommentiere, die externe FP /dev/sda2 auf /mnt mounte, dann mit rsync .... --delete .... aktualisiere. Sicherheit: Der Raspi dient nur dem Intranet, das /var/www/ stellt NICHT im Internet irgendwas bereit, daher könnten die Paket-Aktualisierungen auch Jahre alt sein.

Vielen Dank dank schon mal an alle hier die mir geholfen haben, diese zahlreichen Lösungen zu erarbeiten!!!

[MSfree]

Übrigens, wie schon vorher von mir erwähnt: das /var/ der microSD-karte veraltet nicht, es wird von mir immer nach install neuer Pakete (geplant alle 3 Monate) auf /var/ mit eingehängter USB-Festplatte aktualisiert , indem ich reboote, vorher den mount auf /var/ auskommentiere, die externe FP /dev/sda2 auf /mnt mounte, dann mit rsync .... --delete .... aktualisiere.

Wie gesagt, du kannst dir dieses ziemlich umständliche Prozedere komplett sparen, indem du die USB-Platte einfach als Datengrab irgendwo anders einhängst und /var auf der SD-Karte beläßt. Die Angst vor kaputt geschriebenem Flash-Speicher ist unbegründet. Hikaru hatte zwar gesagt, daß er sich schonmal eine Karte kaputt geschrieben hat, die war aber auch ungleich höher belastet als das, was im normalen Betrieb unter /var passiert. Raspbian lagert hier sowieso alles, was ständig auf /var schreibt in RAM-Disks auslagert.

[egerlach]

Habe das in der fstab getestet:

Code: Alles auswählen

/dev/sda2          /var/        ext4   defaults,nofail,x-systemd.before=local-fs.target     0     0

Geht! Der Bootvorgang macht 2 x 1,5 Minuten rum, dann bootet der durch. Die 2 x 1,5 Minuten lassen sich noch mit x-systemd.device-timeout=9 auf ca 9 Sekunden verkürzen:

Code: Alles auswählen

/dev/sda2          /var/        ext4   defaults,nofail,x-systemd.before=local-fs.target,x-systemd.device-timeout=9     0     0

bin happy!!

@MSfree: sicherlich bin ich übervorsichtig mit /var/. Habe eine 32GB-karte im Raspi, vermutlich wird die auch in 5 Jahren nicht damit fertig, alle 32GB EINMAL zu beschreiben. Obwaohl, Fax schreibt in 5 Jahren ca. 7GB. Und die Karten haben ja ca, 1000 Schreibzyklen. Ich weiß, Karten schreiben intelligent, sie "merken" sich welche Speicherbytes wie häufig beschrieben wurden und nutzen alle gleichmäßig. Aber: meine crontab ist vollgestopft mit allerlei Aufrufen, Sicherungen, daemons. Alle generieren log-Einträge und viele "mail an root". Da bekomme ich einfach ein ungutes Gefühl. Da ich nur selten noch Pakete installiere, ist das Kopieren von /var der Festplatte auf das originale /var vermutlich nur alle 2 Jahre mal notwendig (und daran, dem "Server-Check", verdiene ich ) , oder wenn dist-upgrade (wenn ich das überhaupt jemals mache). Booten ohne /var/ der externen Festplatte wird zu 99% eh nie passieren, denn wann bitte krachen SSD-Festplatten, die als "Heiligtümer" jahrelang unberührt im Serverschrank liegen? Natürlich wird die und die Steckkarte spätestens nach 4 Jahren ausgewechselt, ist ja ein wichtiger Server.

[MSfree]

@MSfree: sicherlich bin ich übervorsichtig mit /var/. Habe eine 32GB-karte im Raspi, ... Und die Karten haben ja ca, 1000 Schreibzyklen.

Das würde 32TB an Gesamtschreibleistung ergeben. Wie gesagt, du wirst eine SD-Karte damit nicht kaputt schreiben. Ich hatte mal in einem Router eine 8GB-CF-Karte, die 13 Jahre gelaufen ist. Da ist ein Squid-Proxy drüber gelaufen , der sehr viel IO gemacht hat und das Logging hat jedes von der Firewall verworfene Netzwerkpaket gelogt, mit bis zu 20000 Logeinträgen pro Stunden. Die Karte ist heute noch intakt.

Da bekomme ich einfach ein ungutes Gefühl.

Völlig unbegründet.

Da ich nur selten noch Pakete installiere,

Darum gin es mir nicht. Mir ging es um die üblichen Sicherheitsupdates, die von der Paketverwaltung erfaßt werden.

Code: Alles auswählen

apt-get update
apt-get dist-upgrade

Um den Rechner mit Sicherheitsupdates zu versorgen, verändert man auch /var.

ist das Kopieren von /var der Festplatte auf das originale /var vermutlich nur alle 2 Jahre mal notwendig

Nein, es wäre nach jedem apt-get update nötig.

Natürlich wird die und die Steckkarte spätestens nach 4 Jahren ausgewechselt, ist ja ein wichtiger Server.

Dann besteht noch viel weniger Grund, sich Sorgen um die SD-Karte zu machen.