In fstab herumpfuschen (eigene Optionen)

29/08/2011 - 01:42 von Hauke Laging | Report spam
Moin,

ich spiele mit dem Gedanken, nur noch die wichtigsten Volumes (alles, was
zum OS gehört) über den normalen fstab-Mountmechanismus einzubinden und alle
Datenlaufwerke selber zu mounten, um mit Dateisystemproblemen besser umgehen
zu können (also v.a. den automatischen Bootprozess nicht zu unterbrechen).

Nun wàre es der Übersichtlichkeit halber natürlich schon wünschenswert, dass
die Volumes weiterhin in fstab auftauchen. Dank u.a. noauto kein Problem.
Noch schöner wàre es, wenn es nicht nur einfach eine mehr oder weniger
aktuelle Kopie eines Eintrags irgendwo anders wàre, sondern die maßgebliche
Konfiguration für mein Script. Damit es fstab auswerten kann, müsste ich
natürlich irgendwelche Optionen erfinden, die es verarbeitet.

Spricht irgendwas gegen diese Vorgehensweise? Ich habe es zugegebenermaßen
noch nicht ausprobiert. Vielleicht flippt mount dann ja auch aus. :-)
Vielleicht gibt es eine syntaktische Vorgabe für eigene Mountoptionen? Wenn
nicht, erscheint es vernünftig, das mal bei den Entwicklern anzuregen?

Gibt es Distributionen, die dieses Problem über einen allgemeinen
Mechanismus handhaben? Also für jedes Volume konfigurierbar zu machen, wie
auf Mountprobleme reagiert werden soll? Die grundlegenden drei Varianten
sind:

1) (wie heute) unterbrechen, in den interaktiven Modus schalten
2) ignorieren (d.h., nicht mounten)
3) verschàrften fsck versuchen, ggf. rebooten, ggf. Script aufrufen


CU

Hauke
http://www.hauke-laging.de/ideen/
D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
 

Lesen sie die antworten

#1 Marcel Müller
29/08/2011 - 10:01 | Warnen spam
Hallo,

Hauke Laging wrote:
Nun wàre es der Übersichtlichkeit halber natürlich schon wünschenswert, dass
die Volumes weiterhin in fstab auftauchen. Dank u.a. noauto kein Problem.
Noch schöner wàre es, wenn es nicht nur einfach eine mehr oder weniger
aktuelle Kopie eines Eintrags irgendwo anders wàre, sondern die maßgebliche
Konfiguration für mein Script. Damit es fstab auswerten kann, müsste ich
natürlich irgendwelche Optionen erfinden, die es verarbeitet.

Spricht irgendwas gegen diese Vorgehensweise?



das würde ich lassen. Selbst wenn es heute geht, man kann nie wissen,
wer noch alles fstab liest und morgen darüber stolpert.

Vielleicht gibt es eine syntaktische Vorgabe für eigene Mountoptionen? Wenn
nicht, erscheint es vernünftig, das mal bei den Entwicklern anzuregen?



Naja, die mount.xyz Scripte müssen die Optionen halt verstehen. Klar
kannst Du da ein eigenes Script basteln, aber wozu der ganze Aufriss.
Dein Mount-Script muss doch sowieso irgendwo /nach/ dem Systemstart
aufgerufen werden. Es ist doch naheliegend bei diesem Aufruf die
entsprechenden Parameter per Kommandozeile mitzugeben.


Gibt es Distributionen, die dieses Problem über einen allgemeinen
Mechanismus handhaben? Also für jedes Volume konfigurierbar zu machen, wie
auf Mountprobleme reagiert werden soll? Die grundlegenden drei Varianten
sind:

1) (wie heute) unterbrechen, in den interaktiven Modus schalten
2) ignorieren (d.h., nicht mounten)



Ignorieren ist so eine Sache. Man weiß nie, welches Programm, oder
welcher Symbolische Link das Volume genau braucht. Dasselbe Problem hat
man aber auch schon alleine beim verzögerten Mount, nach dem Start.

noauto ist da schon ungefàhr das richtige. Gnome z.B. mountet Volumes
auch so mal automatisch, wenn man darauf zugreift. Beispielsweise
fremdartige Partitionen.

3) verschàrften fsck versuchen, ggf. rebooten, ggf. Script aufrufen



? - gegen welche Art Fehler soll das wirken? Und was soll der Reboot? Da
hast Du ruck zuck eine Boot-Schleife.


Marcel

Ähnliche fragen