Hm. Teď jsem vyjel s jedním RPi úplně z čistýho stavu, a koukám, že je tam možnost zapnout overlayfs, a vůbec se na SD kartu nebude zapisovat.

raspi-config - Performance - Overlay file system - hotovo :D

GitHub - ghollingworth/overlayfs
https://github.com/ghollingworth/overlayfs

PISKVOR: Já už vím. Ale dá se to nastavit i pro jednotlivé typy souborů (třeba *.sh), nebo konkrétní fajl, jestli se nepletu.

PECA: Pedantry: Git to takhle dělá _defaultně_, ale je na to toggle:

Configuring Git to handle line endings - GitHub Docs
https://docs.github.com/en/github/using-git/configuring-git-to-handle-line-endings

K těm LF a CR, ono to je docela weird issue, IMO. Pamatuju z dětství ještě takové ty dálnopisné stroje, na které se dalo tisknout z děrné pásky, nebo třeba "tiskárny" co vypadaly jako elektrický psací stroj zabudovaný do psacího stolu :) A později i třeba terminál, který vypisoval na obrazovku dost podobně.
Tam bylo LF jednoznačně Line Feed, tedy přechod na další řádek, ale na stejné pozici a CR byl skutečně návrat vozíku (tiskové hlavy) bez odřádkování. A dávalo to smysl. Dalo se tak přetisknout řádek 2× pro výraznější tisk, nebo třeba kombinaci různých znaků přes sebe (to terminál neuměl, ten nahradil písmenka za nová).
Ale důvod, proč na se na Linuxu (asi všech unixech obecně, nevím jistě) používá samotný LF a CR navíc rozbije skript mi absolutně uniká. Mac používá samotný CR, jestli mu v něčem vadí kombinace s LF netuším. Na Windows a DOS je zvykem používat CRLF, příčemž zamotné LF či CR asi ničemu moc nevadí, jak se mi z pokusů jeví. Ale pamatuji "texťáky", kde se používalo samotné CR jako měkké zalomení řádku (čistě pro formátování) a CRLF jako konec odstavce.
Vím, že alespoň dříve měly tiskárny v konfiguraci (dip přepínače třeba) nastavení, jak se chovat při samotném LF či CR (jestli automaticky odřádkovat včetně návratu vozíku).

Git, pokud to někdo neví, tak dělá konvrzi podle hostitelského OS. Což se může ukázat jako problém, jak se stalo mě. Zvláštní je, že se na tohle narazí ještě po tolika letech. Ale kolega taky nechápe, proč mi na klávesnici vadí, když tam nemám SysRq, Break a ScrollLock (ne že bych ten SysRq někdy použil). :D

//konec historické vsuvky ne až takového pamětníka :)

BOAR: Ano, jsem ve fázi řešení provozního prototypu. Ale nebude to bohužel možné testovat úplně v reálném provozu třeba měsíc. Prostě se otestuje, že to pasuje, že to funguje podle očekávání a třeba ty updaty SW musím během pár dní vyřešit alespoň na sucho a pak otestovat na tom prototypu, až mi přijde.

Jinak ano, veselých (někdy méně) historek se najde asi v každé profesi dost. Není nad vlastní zkušenost. Akorát se ty hodiny strávený laděním nějaký vlastní idiocie špatně zdůvodňují ve výkazu práce :)
Nejhorší je, že jeden by si myslel, že po nějakých 20 - 30 letech praxe už se mu podobný blbosti nebudou dít často... A zrovna předminulý týden jsem si "odmaturoval" z LF vs CRLF a to hned 2×. Nejprve, než jsem přišel na to, že sripty s crlf na linuxu nefungují a je to právě kvůli tomu crlf, namísto pouhého lf (což osobně považuji za bug, ale co už) a podhé, než jsem přišel na to, že git mi defaultně ty opravené lf opět na windows převede na crlf (než jsem to pak našel v nastavení)... Kdo to psal o tom stálezeleném stromě praxe?

PECA: jedna vec, co PISKVOR s btrfs nezminil a kterou se slusi vypichnout je moznost cely filesystem snapshotovat (a mit tak moznost se celkem snadno vratit do funkcniho stavu, pokud se neco nepovede). Taky se muze hodit :) Proto zminuje potrebu initrd (ext4 je natvrdo v jadre; btrfs nikoliv) - defaultni OS initramfs vubec neresi/nepotrebuje (obecne jakmile je v kernelu natvrdo minimalne podporoa pro vse nutne na mount rootu, tak potreba ani neni)...

PECA: hehe je vzdy dobry mit nejakej prototyp, nechat ho chvili jet, a pak upravit - prijdes na spoustu chyb, tak nenechavej delat vsech 100 kusu hned - teda pokud to neni nezbytne nutny. Venuj dost casu testovani v realnem provozu realneho zarizeni. ono se ti treba stane, ze zjistis, ze v navrhu mas nejakyho sotka, a ze ti treba pri spusteni vetraku restartuje system :-)
jinak to co psal PISKVOR, tak to je zase uplne opacnej extrem,a je potreba se podivat na to, jestli cena vyvoje takovyho reseni neni vyssi, nez 3x za pristich 5 let jet restartovat jedno zarizeni :) Nadruhou stranu, zazil jsem, ze kluci (programatori) stali v 10metrech na plosine pod zarizeni, a pres eth se snazili debugovat proc to neni pripojeny do site. :-)

PECA: Firmware a kernel v žádným případě neměnit bezobslužně, to je jen otázka, *kdy* tě to pokouše.

Od jisté doby mám na SD kartě /boot sda1, /boot.alt sda2, /boot.recovery sda3, / sda5, /root.alt sda6 a /recovery sda7

S tím, že všechny booty jsou fat16, / je btrfs s RAID1 na SD a USB, a /root.alt a /recovery je ext4.

/boot je defaultní, boot.alt je jeho kopie (už se hodilo i při poškození karty), boot.recovery a recovery je nějaký jiný armbian

mám custom initramfs, který má moduly pro USB+kbd, statický custom busybox, a hlavně skript, který čeká, jestli naskočí systém do 5 minut: když ne, rebootne do boot.alt. Pokud nenaběhne boot.alt, týž skript rebootne do recovery. Tam teda neběží ty věci, kvůli kterým tam malina je, ale zase se to pokouší všemi způsoby řvát, aby si toho všiml monitoring.

Všude (včetně initramfs) jede dropbear se stejným klíčem (ten initramfs se musí pak shodit a pustit plnotučně), tj. pokud naběhne aspoň něco, tak se snad dobouchám.

No a výměna kernelu probíhá tak, že se ručním zásahem standardním postupem upgraduje /boot a /, zbuildí se přitom initramfs (má na to hook), a reboot. To by teoreticky šlo automaticky přes unattended-upgrades, ale věčně zelený je strom praxe. Pokud to proběhne dobře, tak se v plánovaným downtime rebootne do recovery, odtamtud se zkopíruje /boot na /boot.alt a / na /root.alt, zkusí se boot z boot.alt, a pak reboot ze standardního /boot .

Není to zas tak složitý, jak to vypadá z textu, nejtěžší bylo na začátku správně sestavit ten initramfs - teď se to pouští ručně jen pro úplnou jistotu.