[fstab] - "nofail" wirkt nicht wie erwartet

[buhtz]

Die mount-Option nofail bewirkt doch, dass das System bootet, auch wenn die betreffende Partition nicht eingehängt werden konnte - richtig?

Gibt es hier noch andere Faktoren, die den erfolgreichen Boot verhindern könnten? (Debian 10 mit unklarer Hardkernel Odroid Modifikation auf einem ARM Odroid HC4).

Code: Alles auswählen

# / was on /dev/mmcblk0p2 during installation (Partition 2 auf microSD-Karte)
UUID=0f4f438e-0be8-4cff-a204-c2291bc64018 /               ext4    errors=remount-ro 0       1
# /boot was on /dev/mmcblk0p1 during installation ((Partition 1 auf microSD-Karte)
UUID=72f6def3-4466-4e2a-833d-0c0ed1da8d83 /boot           ext2    defaults        0       2

# besteht aus sda1 und sdb1
/dev/md127 /Daten ext4 defaults,nofail 0 2

# mountet problemlos
/dev/sda2 /NoRAID ext4 defaults,nofail 0 2

# bind mounts auf das raid
/Daten/Backup/AyakoBackup /home/ayako/Backup none defaults,bind,nofail 0 0
/Daten/Media/Ayako/Musik /home/ayako/Musik none defaults,bind,nofail 0 0
/Daten/Media/Ayako/Video /home/ayako/Video none defaults,bind,nofial 0 0

Gerät bootet aber nicht.


Was könnte hier noch der Grund sein?
Wie kann ich in Zukunft verhindern, dass bei auftretenden Laufwerksfehlern (bei Laufwerken die keine boot-relevante Daten enthalten), das Gerät nicht mehr mountet?

EDIT: Die Option nobootwait führt beim Booten zu einer Fehlermeldung, da scheinbar unbekannt.

EDIT2: /dev/md127 existiert gar nicht. Das ändert aber nichts an meiner grundlegenden Frage. Das System sollte, wegen nofail, trotzdem booten und sich nicht wegen so einer Belanglosigkeit (auf dem Gerät sind nur Daten, kein OS) blockieren.

[NoobOfLinux]

Hi,
du hast ein Raid mit mdadm erstellt, richtig?

Wenn ja, erst mit blkid die UUID des Raidsets herausfinden und dann unter /etc/mdadm/mdadm.conf nach folgendem Schema eintragen, danach rebooten. Bei mir ist es das einzige Raidset, deshalb md0.

Code: Alles auswählen

ARRAY /dev/md0 UUID=XXXX-XXXX

Was auch hilft ist herauszufinden, ob es vielleicht das Raidset zerschossen hat und er es gerade wieder rekonstruiert (cat /proc/mdstat)

Ich empfehle dir auch, in der fstab anstatt der Partitionsbezeichnungen die UUID zu verwenden. Ist zwar umständlicher aber eindeutiger und kriesensicherer.

Falls es mehrfach eingebunden werden sollte (das Raidset), deinstalliere gvfs. Dsa ding wirkt wie ein Automat fürs Mounten per Plug'n'Play.

[buhtz]

Du hast Recht, aber gehst nicht auf meine Frage ein.
Es geht hier nicht darum, wie man ein RAID korrekt/kriesensicher mit fstab mountet. Sondern es geht darum, wie man ein System trotz fehlerhaften (raid)mount booten kann.

Das Bootproblem habe ich schon behoben (z.B. mit der UUID).

Das ändert aber nichts daran, dass nofail offensichtlich ignoriert, oder von mir falsch verstanden wird.
Es sollte für den Bootprozess völlig wurscht sein, ob das RAID da ist oder nicht. Das System muss booten!

Wie bekomme ich das hin?

[MSfree]

Das ändert aber nichts daran, dass nofail offensichtlich ignoriert, oder von mir falsch verstanden wird.

Das zweitere ist der Fall. Die (englischen) Manpage sagt:

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

Was soviel bedeutet wie:
Es wird keine Fehlermeldung (im Log/Journal) erzeugt, wenn das zu mountende Gerät nicht existiert.

Mit deinem Wunsch, das Gerät zu mounten, obwohl Fehlerbedingungen vorhanden sind, aht diese Option also gar nichts zu tun.

[buhtz]

Mit deinem Wunsch, das Gerät zu mounten, obwohl Fehlerbedingungen vorhanden sind, aht diese Option also gar nichts zu tun.

Das ist nicht mein Wunsch. Mein Wunsch ist es, dass die Kiste bootet, auch wenn das Gerät nicht gemounted werden kann (egal warum).
Das Gerät ist zum booten nicht relevant, da es nur ein Datengrab ist.

[MSfree]

Mein Wunsch ist es, dass die Kiste bootet, auch wenn das Gerät nicht gemounted werden kann (egal warum).

Dein Problem sind die bind-Mounts in deiner fstab. Wenn /Daten nicht gemountet werden kann, können die folgenden bind-Mounts auch nicht erfolgen.

Warum willst du denn die Unterverzeichnisse als bind-Mounts ausführen? Ich hätte da unter /home/ayako einfach ein paar symbolic Links gesetzt. Die zeigen dann im Zweifelsfall einfach ins Leere, wenn /Daten nicht gemountet werden kann, sie behindern aber den Bootvorgang nicht.

[buhtz]

Dein Problem sind die bind-Mounts in deiner fstab. Wenn /Daten nicht gemountet werden kann, können die folgenden bind-Mounts auch nicht erfolgen.

OK, verstehe. Aber auch die 3 bind-mounts haben ein nofail bei den Optionen. Sie sollten daher also auch kein bootprozess-blockierendes Problem sein.

Warum willst du denn die Unterverzeichnisse als bind-Mounts ausführen?

Gute Frage. Mir fehlt die Dokumentation von damals. Es hatte irgendwas mit den Rechten zu tun. Genau weiß ich es leider nicht mehr. Aber es funktioniert und hier möchte ich ungern etwas ändern. Ist ja auch OffTopic.

[MSfree]

Aber auch die 3 bind-mounts haben ein nofail bei den Optionen. Sie sollten daher also auch kein bootprozess-blockierendes Problem sein.

Nochmal: nofail bewirkt nicht, daß der Bootprozeß im Fehlerfall fortgesetzt wird, sondern nur, daß im Fehlerfall kein Logeintrag erzeugt wird. Der Fehler bleibt bestehen.

Mir fehlt die Dokumentation von damals. Es hatte irgendwas mit den Rechten zu tun.

Symbolic Links ändern nichts an den Dateirechten. Es ist also egal, ob du bind-Mounts verendest oder symbolic Links. Wenn die Rechte dir den Zugriff verhindern, wird sich das bei SymLinks und bind-Mounts gleich verhalten, du darfst nicht zugreifen.

Aber es funktioniert und hier möchte ich ungern etwas ändern.

Solltest du aber, denn das ist der einzige Weg, der mir einfällt, wie man die Bootblockade verhindern kann.

[mludwig]

Prinzipiell tut nofail genau das was du moechtest: Fehler in dieser Zeile der fstab werden ignoriert und der Bootprozess faehrt fort. Dummerweise funktionieren solche Optionen nicht bei bind-mounts. Diese kann man zwar eintragen, sie werden aber vom Kernel ignoriert. Erst bei einem remount werden diese korrekt gesetzt.

Siehe auch:

https://blog.iwakd.de/systemd-fstab-and ... th-options
und der Bug in systemd, mit diesem Kernel-Problem umzugehen:
https://bugs.freedesktop.org/show_bug.cgi?id=53205

noch ein Edith:
Das Verhalten ist in der mount-Manpage dokumentiert:

Code: Alles auswählen

man 8 mount

<snip>
       Beachten Sie, dass die vom Kernel verwalteten Einhängeoptionen des Dateisystems die gleichen wie im  ursprünglichen  Ein‐
       hängepunkt  sind. Die Einhängeoptionen auf Anwendungsebene (z.B. _netdev) werden von mount(8) nicht kopiert, daher ist es
       nötig, die Optionen explizit in der Befehlszeile an mount zu übergeben.

       Seit Version 2.27 von Util-linux erlaubt mount(8) die Änderung der Einhängeoptionen durch Übergeben der relevanten Optio‐
       nen mit --bind. Zum Beispiel:

              mount -o bind,ro foo foo

       Diese Funktion wird vom Linux-Kernel nicht unterstützt. Sie ist auf Anwendungsebene durch einen zusätzlichen mount(2)-Sy‐
       stemaufruf zum erneuten Einhängen implementiert. Diese Lösung ist nicht atomar.

[buhtz]

Prinzipiell tut nofail genau das was du moechtest: Fehler in dieser Zeile der fstab werden ignoriert und der Bootprozess faehrt fort. Dummerweise funktionieren solche Optionen nicht bei bind-mounts.

Danke für die klare Aussage. Jetzt kann ich das Verhalten nachvollziehen.

Ich merke, nach dem Lesen des von dir zitierten manpage-Auszugs, dass es mir hier irgendwie an Background fehlt. So richtig versteh ich diesen Text gar nicht - aber das liegt an mir, nicht am Text.

Ich finde mount könnte hier redseliger sein, wenn man Optionen setzt, die zu einander inkompatibel sind, könnte da irgendwo ein Warning kommen. Und mount/fstab fände ich eigentlich so wichtig, dass auch eine Mail an root gehen könnte. Naja, ich bin ja nicht das Mass aller Dinge.

Wenn es an den binds liegt, werd ich doch mal Symlinks probieren und dann evtl. auch wieder merken, wo damals das Problem mit den Symlinks lag.

[buhtz]

und der Bug in systemd, mit diesem Kernel-Problem umzugehen:
https://bugs.freedesktop.org/show_bug.cgi?id=53205

Das Bug-System ist geschlossen, der Bug hat keine Umzugsmeldung.
Auf dem neuen Bug-System ist der Bug (mit ID, Projekt oder Titel) nicht zu finden.

So kann man auch aufräumen.

[mludwig]

Ich wuerde diese mounts nicht per fstab, sondern als mount Befehl in einen Skript schreiben, der beim starten ausgefuehrt wird. z. b. /etc/rc.local
Dort sollten sie ganz am Ende ausgefuehrt werden, und wenn es nicht klappt ist die Kiste erstmal trotzdem hochgefahren.

[NoobOfLinux]

...


Was könnte hier noch der Grund sein?
Wie kann ich in Zukunft verhindern, dass bei auftretenden Laufwerksfehlern (bei Laufwerken die keine boot-relevante Daten enthalten), das Gerät nicht mehr mountet?

EDIT: Die Option nobootwait führt beim Booten zu einer Fehlermeldung, da scheinbar unbekannt.

EDIT2: /dev/md127 existiert gar nicht. Das ändert aber nichts an meiner grundlegenden Frage. Das System sollte, wegen nofail, trotzdem booten und sich nicht wegen so einer Belanglosigkeit (auf dem Gerät sind nur Daten, kein OS) blockieren.

Bin ich der einzige der sich fragt, warum man ein Raid in der fstab mounten will, obwohl man aber weiß, dass es nicht existiert?

Hast du das Problem selbst oder hast du das Problem nur im Netz gefunden?

[buhtz]

Bin ich der einzige der sich fragt, warum man ein Raid in der fstab mounten will, obwohl man aber weiß, dass es nicht existiert?

Ich wollte nicht zu ausschweifend werden, da es nichts mit meiner Grundsatzfrage zu tun hat. Meine Fragestil orientiert sich sehr, aber nicht immer, an der StackExchange Art (fokusiert). Aber der Vollständigkeit halber: Das Problem trat nach einem Update des Kernel-Images auf. /dev/md0 wurde plötzlich zu /dev/md127 (oder war es anders rum?). Warum weiß ich nicht, aber auf der kernel-raid-mailingliste hat man mich schon darauf hingewiesen, dass Geräte-Bezeichnungen (also /dev/*) nie garantiert, sondern immer random sind.

Und ja, ich weiß jetzt auch dass man diese Probleme umgehen kann, indem man Speicher per UUID mounted. Das sollte man wohl generell so machen; wird auf HowTo Seiten aber scheinbar unterschlagen.

Trotzdem wollte ich eben dem "nofail" Ding auf den Grund gehen und es einfach verstehen. Es ging hier ums Verstehen (daher "Grundsatzfrag") und nicht, um die Lösung eines konkreten technischen Problems.

[NoobOfLinux]

Ich bin über "neuste Beiträge" auf dein Thema gekommen und habe den Punkt "Grundsatzfragen" vollkommen überlesen, sry

[buhtz]

Also nochmal zum Punkt bind-mount vs. symlink.

Hab das gerade nochmal probiert. Geht nicht. Merkwürdige Seiteneffekte. minidlna findet Verzeichnisse nicht mehr, obwohl die mit dem links (scheinbar) nix zu tun haben.
Fragt mich nicht, hab keine Nerven das weiter zu verfolgen.

Hab wieder die bind-mounts gemacht und es geht.

[MSfree]

minidlna findet Verzeichnisse nicht mehr, obwohl die mit dem links (scheinbar) nix zu tun haben.

Minidlna verfolgt standardmässig keine symbolic Links, was man aber per /etc/minidlna.conf (Stichwort wide_links) ändern kann.

Davon abgesehen, warum serviert dein minidlna denn Dateien von /home/..., wenn die Dateien eigentlich unter /Daten/... stehen? Wenn du den minidlna direkt auf /Daten/... zeigen läßt, erspart dir das sowohl den bind-mount als auch symbolic Links.

Irgendwie ist das, was du da machst, von hinten durch die Brust ins Auge.

Keep it simple, stupid