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.

PECA: Jasný, to je asi zrovna věc, která se dá pořešit později. Ten CM4 je myslím prakticky stejný HW jako Pi 4 a teoreticky se pro něj dá udělat deska ve stejný velikosti jako je to Pi, takže by se to pak dalo nahradit 1:1. Za mě jsou ty SD karty největší slabina Pi a je fakt škoda, že neprodávají nějakou verzi Pi 4 s flash pamětí, přišlo by mi to třeba lepší nápad, než tam cpát 8 GB RAM :)

A co misto mSD pouzit eMMC?

UUGear Raspikey: 16GB eMMC paměť pro Raspberry Pi
https://rpishop.cz/emmc/2095-uugear-raspikey-16gb-emmc-pamet-pro-raspberry-pi.html

PECA: a tak ono taky jde mit filesystem readonly a premountovat ho readwrite jen kdyz resis ten update... nejaky navody na to taky jsou.

BOAR: nevim jaky ceny to ukazuje tobe, ale ja vidim 780,- za 16Gb (1 kus, levnejsi pri velkoodberu), coz na provoz systemu vcetne rozbalovani velkych update staci, spravne navrzeny prumyslovy reseni skladuje data jinde

novy Pi4 = 1060,- (2Gb RAM), 1540,- (4Gb), 2270,- (8Gb) ... takze ne, nestoji to ani jako Pi, natoz 2x
kdyz by jsi navrhl nizsi cenu pouzitim MLC misto SLC, tak jeste budiz, ale tenhle argument ti nezeru

ale jasne, rekneme ze koupim nejlevnejsi 16Gb za 170,-
karta se mi vysere / upisu ji / sesype se system ... nasledne platim:
- servis u zakaznika = vyjezd technika (platim hodiny technika + auto na vyjezd + PHM)
- a podle SLA a typu sluzby jeste treba poplatky zakaznikovi

jsou veci, ktery te na domaci pouziti netrapi, ale v prumyslu se nevyplati usetrit blbych 610,-, aby jsi pak musel zaplatit za cely ten cirkus, kdyz se to vysere

MARASAN: Podle MS sice jo, ale ne pro ARM - instaloval jsem to podle MS a přes apt mi to fakt nešlo. Ale určitě znovu prověřím, než vypotím finální verzi.

BOAR: Jo, to já taky. Udělal jsem aby to běhalo z USB, ale počítám totožný problém. Idální by bylo read-only fs, ale to bych nemohl dělat ty aktualizace SW (nebo nevím jak). Nicméně USB jsem volil protože vím o problémech SD, kdy to při tvrdém vypnutí a zapnutí může tu mikroSD posrat. Takže ještě možná pohledat lepší flashky.

MARASAN: To asi záleží jak na kterou platformu. Zrovna v tohle případě jsem se dočetl "Package manager installs are only supported on the x64 architecture. Other architectures, such as ARM, must install .NET by some other means such as with Snap, an installer script, or through a manual binary installation."

Taky to "instaluju" z toho zipu jako PECA. Mám na Pi udělaný řízení 192x64 LED displaye v C++, ale grafiku renderuju v C#.

BOAR: Tak snad pojedou "Industrial SD karty" a minimalizují zbytečné zápisy...