ein PC soll nur eine bestimmte Anwendung ausführen und die muss lokal nichts schreiben, man könnte / read-only mounten. Anscheinend muss man dazu /etc/fstab ändern (geht das wirklich nicht anders?). Es gibt sowieso ein Script, um alles einzurichten, das sollte also auch die fstab ändern. Diese Zeilen funktionieren scheinbar, aber das ist mein erster Versuch mit sed, und, macht man das so?
ein PC soll nur eine bestimmte Anwendung ausführen und die muss lokal
nichts schreiben, man könnte / read-only mounten. Anscheinend muss man
dazu /etc/fstab ändern (geht das wirklich nicht anders?). Es gibt
sowieso ein Script, um alles einzurichten, das sollte also auch die
fstab ändern. Diese Zeilen funktionieren scheinbar, aber das ist mein
erster Versuch mit sed, und, macht man das so?
Du machst solche Dinge ja öfter, deswegen würde ich Dir empfehlen, Dich in ein Automatisierungsframework wie Ansible einzuarbeiten. Das braucht nicht mehr als einen SSH-Zugang mit der Möglichkeit zur Privilegienerweiterung und bietet für Deinen Anwendungsfall das Modul ansible.builtin.lineinfile [1] an. HF!
in ein Automatisierungsframework wie Ansible einzuarbeiten. Das braucht
Interessant das fuer solchen Pipifax immer gleich grosse Kaliber
herausgeholt werden.
Ein:
mount -o remount,ro /
als root ausgefuehrt, sollte eigentlich reichen.
Wird aber wohl scheitern:
mount: / is busy
Man kann sich sein System so umschnitzen, dass es auch
schon beim Boot nur R/O-gemountet ist. Bei einer "normalen"
Distribution wird das aber wohl in vielen Fehlermeldungen
enden.
in ein Automatisierungsframework wie Ansible einzuarbeiten. Das braucht
Interessant das fuer solchen Pipifax immer gleich grosse Kaliber
herausgeholt werden.
Und gleichzeitig auch noch die Nutzung davon fehlerhaft zu propagieren.
Die Nutzung von lineinfile von ansible ist in diesem Fall genauso unvollständig und fehleranfällig wie das sed Beispiel.
mount -o remount,ro /
als root ausgefuehrt, sollte eigentlich reichen.
Das wäre vielleicht eine Notlösung, aber
Man kann sich sein System so umschnitzen, dass es auch
schon beim Boot nur R/O-gemountet ist.
Eben, das kostet genau ein zusätzliches "ro," in der fstab. Das funktioniert problemlos, wenn man es von Hand einträgt (und natürlich weiß, wie und wo). Man kann es auch gleich bei der Installation so einrichten, das wäre die offizielle korrekte Methode. Ich weiß aber nicht, ob man dafür mit priority=low installieren müsste. Daher dieser Versuch mit sed.
Bei einer "normalen" Distribution wird das aber wohl in vielen
Fehlermeldungen enden.
Jein, seit /run benutzt wird, funktionieren viele Dinge automatisch, jedenfalls bei Debian. Es bleiben nur ein paar Kleinigkeiten, z.B. will irgendwer /etc/resolv.conf schreiben und hwclock /etc/adjtime. Aber egal, hwclock hat für speziellere Konfigurationen noch nie richtig funktioniert.
in ein Automatisierungsframework wie Ansible einzuarbeiten. Das braucht
Interessant das fuer solchen Pipifax immer gleich grosse Kaliber
herausgeholt werden.
Und gleichzeitig auch noch die Nutzung davon fehlerhaft zu propagieren.
Die Nutzung von lineinfile von ansible ist in diesem Fall genauso
unvollständig und fehleranfällig wie das sed Beispiel.
nur /genauso/ fehleranfällig ist aber sehr optimistisch ;)
Eigentlich benutzt man dafür das mount command:
Das hat auch den Vorteil, dass bei einem Crash Dein System nicht die
geänderte /etc/fstab benutzen würde.
Was bei einem Crash benutzt wird, ist mir ziemlich egal. In dem Fall muss man mit allem rechnen, da kommt es auf das read-only auch nicht mehr an. Im Gegenteil, man kann weniger kaputt machen.
Das "remount,ro" sollte so früh wie möglich passieren, aber natürlich nachdem das init-System es / read-write gemountet hat. Also irgendwo mitten im Bootvorgang. Im Zweifelsfall wird vielleicht /etc/resolv.conf noch überschrieben und das kann dann nicht korrigiert werden oder sowas.
Das "remount,ro" sollte so früh wie möglich passieren, aber natürlich
nachdem das init-System es / read-write gemountet hat. Also irgendwo
mitten im Bootvorgang.
Hast du es denn schon einmal probiert?
Nach einem R/W-Mount ist das Filesystem in Benutzung, und laesst
sich nicht mehr einfach R/O-(re)mounten.
Wenn deine benutzte Distri mit Root R/O startet dann hast du
doch schon was du willst.
Wenn die Eintraege in resolv.conf und adjtime so passen...
Das "remount,ro" sollte so früh wie möglich passieren, aber natürlich
nachdem das init-System es / read-write gemountet hat.
Hast du es denn schon einmal probiert?
Jein. Ich lasse das init-System read-only mounten, und kann dann jederzeit remount,rw - schreiben - remount,ro.
Nach einem R/W-Mount ist das Filesystem in Benutzung, und laesst
sich nicht mehr einfach R/O-(re)mounten.
Einfach ist relativ. Während ich das hier schreibe, sagt mir lsof, dass nur eine einzige Datei in $HOME/.cache zum Schreiben offen ist! Auf die kann ich verzichten. Woran könnte es sonst noch scheitern? Aber egal, das gehört in die fstab.
Wenn deine benutzte Distri mit Root R/O startet dann hast du
doch schon was du willst.
Beinahe. Das funktioniert ja, nur wie bekomme ich das "ro," per Script in die fstab?
Wenn die Eintraege in resolv.conf und adjtime so passen...
Die werden passend gemacht, das ist nur Fleißarbeit.
Im Embedded Bereich ist RO gar nicht mal so unüblich. Oft sind es Firewalls oder Steuergeräte, welche grundsätzlich nur lesend arbeiten. Zur Konfuguration wird ein remount-rw aufgerufen, umkonfiguriert, anschließend wieder mit remount-ro dicht gemacht.
Ich muss gestehen den Aufbau bisher nie genauer angeschaut zu haben. Spontan fällt mir die Mini-Distro Voyage ein. Die hat es, dort könnte man sich die config und das remount script anschauen.
Beim Raspberry gab es auch ein paar ähnlich Ansätze. Um die sdcard zu schonen ging es mit To-RAM und dann ein persistence bzw. sync beim shutdown.
@bauformb Auf Basis von Dateirechten d.h. Gruppenzugehörigkeit wäre vielleicht ein einfacher Ansatz.
Sowas wie chmod u+rwx,g-w,o- /srv
Eine frische fstab sieht /ungefähr/ so aus, aber in den options kann ja
alles mögliche stehen, nur defaults oder noatime und wer-weiß-was
Im Prinzip würde ich es auch so machen. Aber ist es beabsichtigt dass egal welche Optionen in der Datei stehen, die durch "ro,noatime 0 1" ersetzt werden sollen? Falls nicht, würde ich entweder
a) den linken Teil vom s/// so explizit schreiben dass er nur auf die bekannte Zeile matcht, und mir anderenfalls eine Warnung ausgeben lassen, dann kann ich entscheiden wie es dann geändert werden soll, oder
b) den Ausdruck so umschreiben dass er nur das "ro," an passender Stelle einfügt
Ansonsten noch: außer Leerzeichen könnten auch Tabs vorkommen
Im Embedded Bereich ist RO gar nicht mal so unüblich. (...)
Zur Konfuguration wird ein remount-rw aufgerufen, umkonfiguriert,
anschließend wieder mit remount-ro dicht gemacht.
Jetzt hast du mich völlig verwirrt.
Warum gibst du noch irgendwem Schreibrechte?
Die sind doch garnicht nötig, weil niemand schreiben will.
Wenn sowieso niemand schreibt, muss man das nicht verbieten.
Wenn man nichts verhindern muss, ist read-only unnötig.
Was wird mit read-only besser, warum macht man das?
OK, im Superblock von ext4 gibt es Daten wie "Last mount time" und "Mount count", also wird der Superblock normalerweise geschrieben. Das könnte man mit ro sparen, aber sonst?
Was wird mit read-only besser, warum macht man das?
Meine Suchmaschine liefert genau eine einzige (falsche) Antwort:
"Why mount read-only? This can be handy if for example you want to look up files in your backups while making sure that you cannot accidentally add, change or delete files in the backup."
Ja, ok, dafür, meinetwegen.
Ohne read-only könnte man die "Last mount time" als RTC-Ersatz missbrauchen, so ähnlich wie fake-hwclock das macht. Also, warum?
Jetzt hast du mich völlig verwirrt.
Warum gibst du noch irgendwem Schreibrechte?
Die sind doch garnicht nötig, weil niemand schreiben will.
Wenn sowieso niemand schreibt, muss man das nicht verbieten.
Wenn man nichts verhindern muss, ist read-only unnötig.
Was wird mit read-only besser, warum macht man das?
Weil der Mountpoint immer root gehört.
root darf, soll und muss.
User(s) darf oder auch nicht.
Von other halte ich nichts, die dürfen bei mir gar nichts.
Verwechsle bitte nicht den Mountpoint und das gemoutete device.
Die /etc/fstab lässt du wie sie ist, also /srv bekommt sein rw bzw. ein default
nur wie bekomme ich das "ro," per Script
in die fstab?
Warum muss das unbedingt per Script sein?
Wenn das System mit Root R/O laueft, klappt das eh nicht. :)
Da ist die fstab ja dann auch R/O.
Wenn man etwas "dynamisch" umkonfigurieren will, dann per
mount mit passenden Optionen.
Wenn die Eintraege in resolv.conf und adjtime so passen...
Die werden passend gemacht, das ist nur Fleißarbeit.
Die Fleissarbeit an der adjtime leistet eigentlich NTP.
Am besten ist es wohl, ganz auf adjtime zu verzichten.
Ein "flascher" Wert in der adjtime sorgt sonst fuer eine
permanent falsch gehende Uhr wenn NTP nicht laueft.
Bei einer "normalen" Distribution wird das aber wohl in vielen
Fehlermeldungen enden.
Jein, seit /run benutzt wird, funktionieren viele Dinge automatisch,
jedenfalls bei Debian. Es bleiben nur ein paar Kleinigkeiten, z.B. will
irgendwer /etc/resolv.conf schreiben und hwclock /etc/adjtime. Aber
egal, hwclock hat für speziellere Konfigurationen noch nie richtig
funktioniert.
Was wird mit read-only besser, warum macht man das?
Gute Frage, hatte ich bisher noch garnicht hinterfragt -- meine Vermutung wäre dass man damit verhindern will dass bei Fehlern, sei es in der Konfiguration oder im Code von irgendwelchen Programmen, dann doch Schreibvorgänge passieren könnten (nebst den von dir ja schon genannten Einträgen im Superblock). Wäre aber interessant ob es auch einen "echten" Grund gibt, und es nicht nur eine Vorsichtsmaßnahme ist?
in ein Automatisierungsframework wie Ansible einzuarbeiten. Das braucht
Interessant das fuer solchen Pipifax immer gleich grosse Kaliber
herausgeholt werden.
In Deiner üblichen "Weisheit" ignorierst Du einige wesentliche Teile meines Hinweises: nämlich, daß unser TO solche Dinge häufiger braucht.
Ich kann mich noch prima an den letzten Thread dieser Art vom TO erinnern, da ging es um die Einrichtung eines Kiosk-Systems. In jenem Thread tauchte auch so ein besonders "kluger" Mensch auf und empfahl, alles -- unter Verletzung des Filesystem Hierarchy Standard -- doch einfach in /home zu installieren.
Ein:
mount -o remount,ro /
als root ausgefuehrt, sollte eigentlich reichen.
Genau, und wegen solcher "klugen Ratschläge" wird Linux in gewissen Kreisen den Ruf nicht los, ein "Frickelsystem" zu sein. Man kann so etwas natürlich jedes Mal aufs Neue irgendwie hinfrickeln. Allerdings...
Wird aber wohl scheitern:
mount: / is busy
Ach, sieh an. Man kann so etwas aber auch einfach richtig machen, also: professionell, reproduzierbar, wartbar und sauber (selbst)dokumentiert. Muß ja nicht unbedingt mit Ansible sein, das hat als Pushsystem ohne Agenten halt gewisse Vorteile für die Anwendungsfälle des TO. Und dann packt man seine Playbooks, Inventories, Konfigurationsdateien und -templates einfach in ein Versionskontrollsystem, und wenn das nächste Mal dieselben Aufgaben gelöst werden sollen, muß man nur noch ein paar Knöpfchen drücken.
Und gleichzeitig auch noch die Nutzung davon fehlerhaft zu propagieren.
Die Nutzung von lineinfile von ansible ist in diesem Fall genauso
unvollständig und fehleranfällig wie das sed Beispiel.
Wenn Du bessere Ideen hättest, dann könntest Du sie vorschlagen. Aber dafür reicht es offensichtlich nicht.
nur wie bekomme ich das "ro," per Script in die fstab?
Warum muss das unbedingt per Script sein?
Es muss nicht unbedingt sein, offensichtlich ist es einfacher/besser, das gleich im Debian Installer zu machen. Weil man auch eine EFI-Partition braucht, kommt man wohl zwangsläufig zu dem Menüpunkt. An der Stelle muss man dran denken, im postinst Script von meinem .deb würde es automatisch gehen.
Wenn das System mit Root R/O laueft, klappt das eh nicht. :)
Muss es ja nicht, dann ist ja schon alles gut und richtig.
Am besten ist es wohl, ganz auf adjtime zu verzichten.
Meine Rede. Ein Link nach /dev/null macht das ganz gut, unabhängig von read-only, auf jedem Rechner. Für resolv.conf hat früher mal ein Link nach /run funktioniert, mal sehen, ob das immer noch geht.
ABER: inzwischen kamen Zweifel auf: was bringt read-only überhaupt?
im postinst Script von meinem .deb
würde es automatisch gehen.
Ja, da ist es gut aufgehoben.
ABER: inzwischen kamen Zweifel auf: was bringt read-only überhaupt?
Ein unkaputtbares root-fs ist fuer manche Anwendung schon unverzichtbar.
Ich habe selbst mal ein Stock-S.u.S.E. 7.0 auf R/O umgebaut, dass
dann unter anderem eins der Systeme auf meinem Notebook war.
Das konnte man zu jedem beliebigen Zeitpunkt ausschalten. :)
wird Linux in gewissen
Kreisen den Ruf nicht los, ein "Frickelsystem" zu sein
In manchen Kreisen hat Linux mittlerweile ueberhaupt keinen Ruf mehr.
Da laesst man selbst HPC-Anwendungen unter Windows laufen.
Oder Firewalls. Das ist schon gruselig. :)
Und das Zeug wird von noch ahnungsloseren VMWARE-Admins "zusammengeklickt".
muß man nur noch ein paar Knöpfchen drücken.
Die sind hoffentlich formschoen und in einer netten Farbe.
Die Arbeit soll ja Spass machen. :)
ABER: inzwischen kamen Zweifel auf: was bringt read-only überhaupt?
Diese Frage müßtest Du Dir selbst beantworten, methinks. Im Grunde erhöht das die Sicherheit des Systems in mehrlei Hinsicht, zum Beispiel bei unsauberen Reboots (kein FS-Check nötig), fehlerhafter Software oder Angriffen. Zudem benötigst Du bei Readonly-Dateisystemen natürlich auch kein Journaling, und obendrein entfallen die mitunter zeitraubenden Dateisystemchecks, die Linux bei Reboots regelmäßig ausführt.
Nebenbei sei auf den Kernel-Bootparameter "ro" hingewiesen, der dafür sorgt, daß das Root-Dateisystem beim Booten readonly gemountet wird, siehe dazu in Documentation/admin-guide/kernel-parameters.txt. Aber klar, zuerst wirst Du Dir natürlich Deine Frage beantworten müssen. :-)
Ich muss gestehen den Aufbau bisher nie genauer angeschaut zu haben.
Spontan fällt mir die Mini-Distro Voyage ein. Die hat es, dort könnte
man sich die config und das remount script anschauen.
Was soll denn Voyage sein? Finde nur "Voyager". Meinst du die?
ABER: inzwischen kamen Zweifel auf: was bringt read-only überhaupt?
Ein netter Nebeneffekt ist, dass man das Root-fs fuer nahezu
beliebig viele Klonsysteme per NFS exportieren kann, die dann
per NFS-root ein identisches System ausfuehren.
Das konnte mein Notebook damals natuerlich auch. :)
Und war fuer Wartung/Installation/Troubleshooting anderer Systeme
ueberaus nuetzlich.
Im Grunde erhöht das [ro mounten] die Sicherheit des Systems
in mehrlei Hinsicht, zum Beispiel bei unsauberen Reboots
(kein FS-Check nötig), fehlerhafter Software oder Angriffen.
OK, überredet. Es lohnt sich allerdings nur so richtig, wenn /tmp noexec ist (und trotzdem noch alles funktioniert).
Nebenbei sei auf den Kernel-Bootparameter "ro" hingewiesen, der dafür
sorgt, daß das Root-Dateisystem beim Booten readonly gemountet wird
Leider hält dieser ro Zustand nicht lange an, wenn in der fstab kein ro steht.
Was soll denn Voyage sein? Finde nur "Voyager". Meinst du die?
Ja, du hast Recht, es ist Voyager. Tu mal nicht so obergescheit, liefere lieber weitere Optionen.
So, ich klinke mich an diese Stelle aus. Wieder einmal wird alles von Schmutzfinken, Besserwissern, Diskutanten und Nörglern zertrampelt ohne konstruktiven Beitrag einer Lösung.
Wer nicht weis wozu ein System im RO laufen soll, braucht es auch nicht. Wer nichts von Zugriffs- und Rechteverwaltung hällt, braucht es auch nicht. Wer seine App nicht unter Kontrolle halten kann, sollte sie nicht nutzen. Und wer sein OS nicht kennt oder kennenlernen möchte soll bitte bei Windoofs bleiben. Linux ist kein Frickelsysten sondern endlos anpassbar. Auf die eigenen Wünsche und Anforderungen.
OK, überredet. Es lohnt sich allerdings nur so richtig, wenn /tmp noexec
ist (und trotzdem noch alles funktioniert).
Wenn ein System mit noexec auf /tmp nicht funktioniert, dann ist irgendwas an dessen Konzept kaputt.
Nebenbei sei auf den Kernel-Bootparameter "ro" hingewiesen, der dafür
sorgt, daß das Root-Dateisystem beim Booten readonly gemountet wird
Leider hält dieser ro Zustand nicht lange an, wenn in der fstab kein ro
steht.
True. Ich wollte inmitten einer Diskussion, die sich rein auf die /etc/fstab konzentriert hat, nur darauf hinweisen, daß das Root-Dateisystem ohne diesen Bootparameter... sagen wir, nicht ganz so readonly ist wie gedacht. :-)
Ich wollte inmitten einer Diskussion, die sich rein auf die
/etc/fstab konzentriert hat, nur darauf hinweisen, daß das
Root-Dateisystem ohne diesen Bootparameter... sagen wir, nicht ganz so
readonly ist wie gedacht. :-)
Wohl wahr, auch das gehört dazu. Obwohl es eine saubere Lösung wäre. Es ist doch eine Frechheit von irgendeinem init-Mechanismus, dass /proc/cmdline einfach ignoriert wird ;)
Ja, du hast Recht, es ist Voyager. Tu mal nicht so obergescheit, liefere
lieber weitere Optionen.
Haaallooo! Du schreibst was falsch, ich finde deswegen nicht und wenn ich nachfrage wirst du noch frech. Bist du sicher das bei dir sonst alles in Ordnung ist?
Ein netter Nebeneffekt ist, dass man das Root-fs fuer nahezu
beliebig viele Klonsysteme per NFS exportieren kann, die dann
per NFS-root ein identisches System ausfuehren.
Das mache ich auch, per NFS als RO exportieren, inklusive PXE boot.
Auf dem Server habe ich dann aber einen LXC container, der das Ding RW gemountet hat, und automatisch updated. Ist eine coole Sache, wenn ich was ändern will, mach ich das in dem Container, und alle PCs haben die Änderung sofort. Und die PCs können selbst nichts ändern. Hier noch die fstab:
Ich habe dort einige Configs in ein Verzeichnis verschoben, und einen Symlink darauf angelegt. Im Container bind mounte ich das Verzeichnis, um dort andere Configs zu haben. Im Container ist meine fstab leer.
Edit: Das "ovtmp" ist das oben abgehängte Script. Muss unter /sbin/mount.ovtmp liegen. Mountet ein Overlay, mit tmpfs als backing store, über das Verzeichnis.
Auf dem Server habe ich dann aber einen LXC container, der das Ding RW
gemountet hat, und automatisch updated.
Wenn da mal keine Raceconditions dir ins Handwerk pfuschen...
NFS-Root ist aber eigentlich ein ganz alter Hut, den sicher die
Haelfte der Rechner in einem Computermuseum auch schon konnten.
Wurden doch an den Universitaeten die Rechnerpools fuer die Studenten
so betrieben.
Und es gab ja auch Zeiten, wo jedes Megabyte eines USB-Flashsticks
mit einer DM aufgewogen wurde, und moeglicherweise gerade mal
USB-Fullspeed schaffte. Das konnte NFS ueber Ethernet schon lange.
Auf dem Server habe ich dann aber einen LXC container, der das Ding RW
gemountet hat, und automatisch updated.
Wenn da mal keine Raceconditions dir ins Handwerk pfuschen...
Was soll da racen? Die Frage ist für mich eher, wie die Rechner mitbekommen, wenn sich was aktualisiert und was dann ggf. neu gestartet werden muss.
Und es gab ja auch Zeiten, wo jedes Megabyte eines USB-Flashsticks
mit einer DM aufgewogen wurde, und moeglicherweise gerade mal
USB-Fullspeed schaffte. Das konnte NFS ueber Ethernet schon lange.
Ja, alles lange her. Heut gibt man dann doch lieber jedem Rechner sein eigenes lokales Root-Verzeichnis, und dann werden die eben ggf. per Ansible oder so synchron gehalten.
Du machst solche Dinge ja öfter, deswegen würde ich Dir empfehlen, Dich
in ein Automatisierungsframework wie Ansible einzuarbeiten.
Ack. Einfach Debian-Standardinstallation durchfahren (oder einfach ein jungfräuliches Image klonen) und danach mit Ansible die spezifischen Anpassungen machen lassen. BTDT - der initiale Aufwand lohnt sich ziemlich schnell.
Das braucht
nicht mehr als einen SSH-Zugang mit der Möglichkeit zur
Privilegienerweiterung und bietet für Deinen Anwendungsfall das Modul
ansible.builtin.lineinfile [1] an. HF!
Örks. Damit kann man das zwar theoretisch auch machen, aber eigentlich ist für diesen speziellen Zweck doch ansible.posix.mount vorgesehen, das einem das Leben viel einfacher macht. ;-)
bietet für Deinen Anwendungsfall das Modul
ansible.builtin.lineinfile [1] an. HF!
Örks. Damit kann man das zwar theoretisch auch machen, aber eigentlich
ist für diesen speziellen Zweck doch ansible.posix.mount vorgesehen, das
einem das Leben viel einfacher macht. ;-)
Just dieses Modul hat mich letztes oder vorletztes Jahr böse gebissen, hab aber nicht mehr genau im Kopf, was. IIRC wars irgendwas mit Newlines, aber vermutlich ist das mittlerweile gefixt?!
Die Jungs der Ansible Community sind ziemlich fix -- ein Kollege hat letzte Woche einen Feature Request wegen Labels für Docker-Images eingereicht, der war keine drei Stunden später umgesetzt. :-)
Man kann in der fstab auch label oder UUIDs verwenden. Wenn man bei seinen Maschinen jeweils immer das selbe bei seinen Partitionen setzt, kann man die selbe fstab auch einfach kopieren.
Was ich auch mal gemacht habe, war als fstab ein Verzeichnis zu nehmen. Früher konnte fstab kurzfristig mal mit /etc/fstab.d umgehen, aber der Support dafür wurde dann recht schnell wieder entfernt. Für den "mount -T myfstab" bzw. "mount --fstab myfstab" Parameter erlauben aber weiterhin auch ein Verzeichnis. Deshalb kann man /etc/fstab/ auch durch ein Verzeichnis ersetzen. Die Dateien darin müssen nur mit .fstab enden.
(Als ich das damals gemacht habe, hatte ich aber einen Symlink von /etc/fstab/ nach /etc/fstab.d/ gemacht, damit die init Scripte damit klar kommen. Die kannten /etc/fstab.d/ auch noch).
Früher konnte fstab kurzfristig mal mit /etc/fstab.d umgehen, aber der
Support dafür wurde dann recht schnell wieder entfernt.
Interessant, das ging schon in die richtige Richtung, aber mehr auch nicht. Es passt für zusätzliche eigene Partitionen. Aber damit man die Optionen für die root-Partition ändern kann, müsste fstab.d ja Priorität haben, aber für jede Partition einzeln. Die Regeln dafür waren dann wohl doch zu kompliziert.
-T, --fstab path
Specifies an alternative fstab file. If path is a directory then the files
in the directory are sorted by strverscmp(3); files that start with "." or
without an .fstab extension are ignored.
Man könnte es also genauso wie bei anderen Configs üblich machen, und einfach eine Nummer an den Anfang setzen, um die Reihenfolge zu regeln.
