Hallo Arno,

ich weiß nicht ob du noch suchst und ich weiß auch nicht genau was du vor hast. Ich hatte letztens aber die Anforderung ein System gegen dauerhafte Veränderung abzusichern und habe daher mit aufs ein RW tmpfs Layer über das RO Root gelegt und reboote das System regelmäßig.

Daran habe ich mich orientiert: https://www.logicsupply.com/explore/io-hub/how-to-build-a-read-only-linux-system/ Die Kommentare darunter sind auch lesenswert, dort gibts Verbesserungsvorschläge. 

Grüße Patrick

Am 20. Juni 2017 um 09:38 schrieb Uwe Kleine-König <uwe@kleine-koenig.org>:
Hallo Arno,

>> Wenig überraschendes. Dass das W-Taint-Flag gesetzt ist, ist vermutlich
>> irrelevant hier. Und oh, ein Vendor-Gammel-Kernel, der nicht mal die
>> Stable-Updates enthält.
>
> Hab mir auch vorgenommen, eher einen Vanilla Kernel zu nehmen und das nötige einzupatchen.
> Aber immer eins nach dem anderen... ;)

Die Praxis zeigt, dass oft alles was halbwegs läuft, dann dem
Zeitmanagement zum Opfer fällt und es in ein Release schafft.

Meines Erachtens nach ist es wenig sinnvoll auf einen Vendor-Kernel zu
setzen, wenn es mainline halbwegs vernünftige Unterstützung gibt. Die
Vendor-Kernel, die ich kenne, enthalten so viel nicht nachvollziehbare
Änderungen, dass von "Vendor funktioniert" auf "Mainline funktioniert"
nur wenig einfacher ist, als von "Nichts" auf "Mainline funktioniert" zu
kommen. Die Differenz ist kleiner als der Aufwand, den Vendor-Kernel ans
fliegen zu kriegen. OK, das setzt voraus, dass man schon firm in
Kernel-Entwicklung ist, weil man ohne den Vendor-Kernel auch den
(vermutlich bereits bezahlten) Support des Vendors nicht in Anspruch
nehmen kann. Ich empfehle hier #armlinux und die linux-arm-kernel ML, da
kriegt man in der Regel bei gut gestellten Fragen auch Hilfe.

Liebe Grüße
Uwe


_______________________________________________
Freiburger Linux User Group
Mail an die Liste: flug@lug-freiburg.de
Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug