Škoda, že poslední tři aktualizace mi vždy můj Turris Mox nepřežil a musel jsem mu nahrát nový firmware na sd kartu. Tak jsem vypnul aktualizace abych měl klid.
Nemám s Turrisem přímou zkušenost, ale tohle je opravdu nějaké obvyklé chování? Nedobral jste se toho, jestli je to něco specifického pro konkrétní hardware/model nebo např. uživatelské nastavení, s kterým ty aktualizace pak takhle selžou?
Jinak to tedy nezní moc povzbudivě.. :( Tak trochu jsem očekával, že právě jedna z výhod Turrisu je kompetentní softwarová podpora na relativně úzké řadě hardware. Což je i třeba důvod, proč si ho někdo koupí místo mnohem lacinějšího routeru.. TP-Link, ASUS atp. Případně že tam trochu "učešou" ten proces aktualizací na běžném OpenWRT, aby to bylo bez obav použitelné i pro "normální" uživatele.
Díky za report a zkušenosti.
Jen ani na obecném OpenWRT bych osobně fakt nedával aktualizace do cronu (míněno procházet nainstalované balíčky a pouštět opkg upgrade na každém z nich, nebo "attended" sysupgrade přes auc, ale v "unattended" režimu).
Tohle je prostě jedna z nevýhod, která za mě prostě vyřazuje čisté OpenWRT z použití pro běžné uživatele, pokud nemají někoho, kdo se jim o to postará.
S tím cronem na OpenWRT jsem se taky zpočátku dost bál - ale zatím mi to bez problému několik let na několika routerech funguje. Ale je pravda, že všechno to jsou routery, kam v případě potřeby prostě můžu zaběhnout.
A taky je to poshazované na nutné služby - žádné doinstalované NASy a externím diskem...
" ale tohle je opravdu nějaké obvyklé chování"
Je to chovani, jehoz vyskyt muzes dohledat u vsech variant a verzi, a to klidne az do nutnosti pripojovat se na jtag, coz je takova bezna vec kterou bezne domaci useri davaj s prstem v nose ...
V NICu jsou totiz jen sami "profici" .. kteri neumej udelat to, co umelo wrtcko pred 20ti lety.
https://en.wikipedia.org/wiki/Linksys_WRT54G_series
Tahle krabka totiz ma tftp, a tery ti nastartuje pri bootu na internim portu a fixne definovany adrese, kde cca 30s ceka zda nastane komunikace. Pokud ne, pokracuje boot, kdyz ano, veme ten stream jednicek a nul, ktery zcela bez jakyhkoli kontrol a blbych kecu proste zapise. Tudiz se to bricknout vlastne vubec neda.
Tak JTAG nebo UART už je další level.. :)
Právě na to koukám.. třeba tady u MOXu..
https://gitlab.nic.cz/turris/mox-boot-builder/-/releases
Ale upřímně než to, že router automaticky spustí TFTP server a pak se tam dá nasypat cokoliv, tak bych byl radši, kdybych tohle vůbec nemusel použít ;)
"kdybych tohle vůbec nemusel použít"
S "cistym"* openwrt se mi nikdy nestalo, ze bych se nebyl schopnej pripojit na sshcko. Stalo se mi parkrat ze nefungovalo treba dnsko, nebo dhcpko nebo ... ale dycky se k tomu dalo pripojit. Tzn to mrveni je vyhradne praci soudruhu v NICu a jejich uzasnyho superhw.
To tftp na tech wrtckach nebylo ani tak proto, ze si tam flashnes tak silene nefukcni firmware, jako spis proto, kdyz ti u toho flashovani treba zdechne elektrina, tak z toho pak nemas nefunkcni cihlu.
*kompiloval sem si to sam ze zdrojaku.
Stát se může cokoliv, jen podobným příběhům přistupuji skepticky, ačkoliv kutilský MOX nepoužívám.
As takhle, zaujatý určitě jsem, protože mi po blízkém okolí funguje 6ks Omnia 2016, 32ks Omnia 2020, 7ks Omina WiFi 6 a 2ks Omnia NG. Připočítám ty moje, to jest dalších 6ks a protože mně lepší polovička uvrtala do "jobovky", tak si mohu připsat ještě jednu navíc (už je v PPL)... a ty routery fungují roky bez sebemenšího problémů. Přirozeně se sem tam malý zádrhel vyskytne, ale není to nic drastického, natož aby to přestalo fungovat a nevyřešilo se.
Musím-li to dělat já (přijde kamarád a potřebuje) ... potom nediskutuji a má na výběr Omnii + Mikrotik, nebo Ubiquiti, protože s D-Link, TP-Link, Šmejd-Link, Šmějdsys, Šmejdwall ... na to prostě nemám nervy a sáhnu po osvědčeném, funkčním a dlouhodobě podporovaném řešení. Nesouhlasí, dávám prostě ruce pryč. Klidně mu to během grilování žebírek vytahám, nakrimpuji, ale dál to řešit nebudu.
Sentinel ... lze na něj nahlížet různě, pro domácího uživatele velice rozumné řešení a NIC je pro mně důvěryhodnější, než třeba Google. Výhoda je v tom, že prostě člověk nemusí "dělat nic" a Sentinel si žije svým životem. Pro někoho nepřekousnutelné, pro druhého výhoda.
Nedělám z toho nic většího, než je.
Díky všem za reakce. Snažil jsem si to trochu utřídit, protože jsem fakt jen kdysi někde nastavoval tu původní Omnii 1.0 jako pomocné AP pro pár klientů v uzavřené síti, ale to bylo jednorázové, nikdy víc jsem s tím nedělal, pak už si to dál řešil kolega.
A ano, četl jsem i nějaká další pojednání o problémech na fórech, ale tam může být kolikrát ten klasický bias (píší jen ti, co mají problém, většina, které to funguje, pak ne)
O těch Btrfs snapshotech v novějších verzích HW jsem také věděl a právě proto mě překvapilo, jak tu p. Tichý zmiňoval ty problémy, kdy musel vícekrát na MOXu znovu zapisovat image. Ale třeba je to problém toho specifického modelu, revize, kusu (nevím, nějaké nefunkční čtení stavu z GPI/tlačítka, když to bootuje, takže se nespustí ten rollback).
Zajímalo mě to i z důvodu třeba vzdálené správy, kdy je při aktualizaci člověk třeba 250 km daleko (a na místě je typicky po telefonu dostupný laik, co pomůže jen se základními úkony typu zmáčknout tlačítko, reset).
Jasně, nic není 100%, ale je to o pravděpodobnosti výskytu problému a předchozí zkušenosti. Jsou zařízení, kde s tím obecně nebývá problém, a člověk to v pohodě riskne. Naopak jsou zařízení a systémy (narážím právě na ty obecné buildy OpenWRT flashnuté na standardních routerech), kde bych se tomuhle rozhodně vyhnul.
Ja doma turrisy pouzivam 3 a stalo se mi to za ty leta asi 2x - ze po aktualizaci jsem to nerozchodil... ale nahravat novy firmware neni nutne, proto ma turris utilitku schnapps ( https://docs.turris.cz/geek/schnapps/schnapps/ ) a behem par sekund se vratim do stavu pred aktualizaci.... a pak mohu s podporou resit proc se to stalo zrovna u mne.....
21. 5. 2026, 11:23 editováno autorem komentáře