Nur für Fortgeschrittene - kleiner systemd-Exkurs: Kurzer Hinweis zur fstab: Wie ich die Lektüre zu systemd verstand, erzeugt systemd-fstab-generator doch keine fstab, sondern aus ihr die neuen systemd-Dateien. Man findet sie z.B. mit
sudo updatedb && locate \.mount
Vorrangig soll wohl die fstab angepasst werden, wobei die danach erzeugten systemd-Dateien (Units) dann Vorrang haben sollen (?).
Nur was hat dann meine fstab-Änderung verworfen gehabt, wenn sie nicht durch systemd neu und von meinem Eintrag für die Micro SDcard befreit angelegt wurde? Dabei fand ich das Script update-fstab im Ordner /usr/lib/lxc-android-config. Dieses wird beim Booten von /etc/init/lxc-android-boot.conf aufgerufen. Da drin stehen übrigens interessante Kommentare:
# lxc-android-boot - LXC Android Boot Setup
#
# Boot setup to map the Android specifics in Ubuntu Touch
# This logic should be moved to the initrd once we have a working loop mounted
# partition scheme for Touch
Jedenfalls steht in dem update-fstab-Script:
if grep -q "^[a-z0-9/]*./system" /etc/fstab || \
grep -q "^[a-z0-9/]*./data" /etc/fstab; then
exit 0
fi
Es wird also nach einer System- oder Datenpartition in der fstab gesucht und wenn sie schon vorhanden ist (wie bei meiner vollen fstab vor meinem Eintrag?), wird das Script (ohne Update, weil nicht nötig) verlassen. Ansonsten wird eine temporäre fstab angelegt:
tmpfile=$(mktemp /tmp/fstab.XXX)
Mit der passiert dort weiter erst mal nichts. Irgendwas fehlt hier noch als Puzzleteil, wie es dann weiterginge. Irgendwas wird diese wohl weiterverarbeiten zu einer richtigen fstab in /etc. Und wenn nicht über das tmpfile, dann muss ja irgendwas (andres?) eine fstab angelegt haben, um aussteigen zu können. Die fstab vom vorherigen Boot bleibt ja vermutlich bis zum Booten erhalten. Sie wird aber dann eben ersetzt oder zumindest kastriert um den eigenen Eintrag. Nur warum bzw. durch welches Script, ist mir noch etwas unklar.
Ich werd mich wohl auch mal bei https://help.launchpad.net/ anmelden, um ggf. mit Entwicklern in Kontakt zu treten bzw. deren Posts zu lesen und des Weiteren beim nächsten Fummeln an der fstab (etwa für USB-Sticks als Test) den systemd-fstab-generator paar systemd-Units generieren lassen. Dann werden die Änderungen sicherlich berücksichtigt.
systemd ausschalten traue ich mich nicht, schon gar nicht in der Entwicklerversion und auf dem Handy. Außerdem wird das noch ganz spannend. 😉 In der fstab kann man für den generator gleich passende neue mount-Optionen mitgeben wie etwa comment=systemd.automount aus systemd.mount.
Da steht auch nochmal zum Vorrang:
This means: native unit
files take precedence over traditional configuration files, but this is
superseded by the rule that configuration in /etc will always take
precedence over configuration in /usr.
Wobei /etc traditionell auch Vorrang über /lib haben sollte, wo bei Touch die von mir gefundenen .mount-Units rumliegen. Ist letztlich egal, ob sie in /lib oder /usr liegen - und /etc hat darüber Vorrang. Also eigentlich hat systemd (trotz in /lib) Vorrang vor traditionellen Dateien, aber da die fstab in /etc liegt, hat letztlich doch die /etc Vorrang. Es gilt also, was in der fstab steht. Meine Frage ist eben nur, was mir die fstab zerschossen hat.
Das spielt aber dann keine Rolle mehr, wenn ich die fstab zu Units generieren lasse - dann wird die neue fstab - wo auch immer sie jedes Mal herkommt - sicherlich die neu generierten Units berücksichtigen und sie entsprechend wiederherstellen. In den bisherigen Units sah ich beim Überfliegen nix, was die fstab erzeugt, aber vielleicht schaue ich irgendwann mal genauer hin.
(Sonst wird es bald nötig, ein Stalkerscript zu schreiben, welches das Ändern der fstab überwacht und dann schnell die Prozessliste sichert, aber das geht sicherlich schief. fstab wird ja vorm Mounten geändert - und der Prozess kann nach dem Ändern längst beendet worden sein.)
An alle, die ich nun verwirrt habe: Es war zwar kein Aprilscherz, aber nehmt es einfach mit Humor und Erleichterung, dass es euch eigentlich egal sein kann. 😊
Grüße, Benno
