Das wird z.B. benötigt, wenn man ein Festplatten-Image bei laufendem VDR-System ziehen will. Dazu muss ein "remount,ro" in die /etc/fstab rein und neugestartet werden und nach der Arbeit muss das "remount,ro" wieder raus aus der /etc/fstab" (dazu muss der ro-Modus temporär aufgehoben werden) und wieder neugestartet werden.
Nun zum Problem:
Nach dem ersten Reboot (im ro-Modus also) war es bisher so, dass der VDR Upstart-Job sich in einen Wartezustand begeben hat, bis das Filesystem wieder schreibbar wurde, und dann hat er ganz normal weiter gemacht.
Neuerdings wartet der Upstart-Job aber bis in alle Ewigkeit. Und wenn man dann rebootet, stirbt dadurch zwar der "post-start" Prozess, aber das löst dann (während des Herunterfahrens!) den Start des VDR aus. Resultat: Der Rechner bleibt stehen und nur noch die Reset-Taste hilft.
Mit etwas Geduld fand ich heraus, dass man nach dem Re-Aktivieren des rw-Modus den "post-start" Prozess des VDR von Hand killen muss, danach noch ein "stop vdr" hinterher, und dann funktioniert der Reboot.
Damit aber noch nicht genug: Eine der Aktionen bewirkt offenbar, dass beim Reboot ein falscher ALSA-State auf die Platte geschrieben wird. Abhilfe schafft hier ein "alsactl restore" direkt vor dem Reboot.
Warum ich das alles erzähle, obwohl ich ja offenbar eine Lösung für alles gefunden habe?
Nun ja, das alles ist bei mir Teil eines Backup-Scriptes, und das will ich eigentlich so allgemein wie möglich halten. Ich würde mir wünschen, dass ich dort keine (exotischen) Eigenheiten des Zielrechners rein programmieren muss.
Gibt es eine solche Lösung? Zufrieden wäre ich aber z.B. auch schon, wenn ich den VDR-"post-start"-Prozess noch im ro-Modus killen könnte. Das liesse sich auch relativ einfach allgemeingültig programmieren. Aber leider startet (zumindest) der VDR-"post-start"-Prozess immer sofort wieder neu, vermutlich durch irgendeinen Watchdog .