Počítač s UEFI se může nenávratně poškodit použitím rm -rf /

že ten příkaz napíšou špatně na živě jsem čekal. Ale že k tomu dojde i tady... :)

o živě nemluvím, ale "rm -rf /" je pro mě termín a ne příkaz :). Ono je ve výsledku jedno, jestli napíšeš "rm -rf /*", "rm -rf /sys" či "cd / && rm -rf ."

Argumentace a ani přístup systemd se mi nelíbí, provedli regresi a mají to napravit. Smazání rootu před incriminovanou verzi nic nezpůsobilo, po aktualizaci rozbije MB, na tom není co diskutovat. A ano, občas se dá podobným způsobem zničit dost věcí, třeba nahrávat nový firmware, ale nezkontrolovat si jeho checksum má občas také fatální následky.

"regrese" přispěla k odhalení problému, ale nezpůsobila ho. Což ostatně uznává i Matthew. To že na chybu hodíme ro plachtu a budem se tvářit že neexistuje chybu neodstraní.

Nechci v tomhle slovíčkařit, máš samozřejmě pravdu. Ale v Linuxu se mezi vývojáři, hlavně co vidím u kernelu, drží zásada, že změnu nezpůsobíš jiné chování, ikdyž není dokumentované.

Tady jednoznačně příkaz rm -rf / před touhle verzí a potéhle verzi má jiné důsledky. Nejde o to na čí přesně straně je chyba a kdo jí bude postupně opravovat, ale v systemd by mělo mountování zůstat zhodné a nezpůsobovat nežádoucí side effect. Můj názor.

Před touto a po této verzi by měl mít ten příkaz naprosto identické výsledky, pokud jsou efivars kernelem mountované do /sys/ jako rw.
Co jsem koukal, nejpopulárnější varianta řešení je zařídit na úrovni kernelu, aby ty soubory které nesmí být přepsány byly immutable a zbytek normálně dostupný.

To je teda argumentace... Ne, nebudeme mountovat efivars readonly by default, protoze podobne si muzes prepsat treba /dev/sda a taky ti to nikdo nezakazuje.

No to víš, ze systému do EFI každý uživatel pravidelně rebootuje nejméně 10x denně, takže by ho přemountování na rw hrozně zdržovalo. :-P

Argumentace možná špatná, ale faktem je že to prostě chyba systemd není.

Uz jsem zazil situaci kdy na produkcnim serveru nebylo misto na disku a tak nekoho napadlo vytvorit zalohu databaze v /dev/shm. Proc taky ne, kdyz podle vystupu z df je tam dost mista. Problem nemusi byt v tom, ze se to smaze. Staci to zaplnit na 100% anebo tam nahrat nejaky bordel a nektere biosy to nevydychaji.

Systemd mysli za uzivatele a snucuje nim svuj podled na svet pri ruznych prilezitostech. V tomhle pripade ale dava lidem svobodnou volbu si svuj system rozbit.

Nevsim sem si ze by se bug vyskytoval jinde, nez na systemech s prave touhle srackou. Nikdo normalni ottiz nic takovyho do FS nemountuje. Kdyz si primontuje BIOS, tak ho taky kupodivu muzu prepsat ... zazrak co?

Isteze... presunme problem na kernel... alebo este lepsie na `rm` ze nedostatocne brania zmazaniu niecoho co systemd uplne zbytocne nemountuje ako rw do sys

HW, který poškodíte pomocí software, si nic jiného nezaslouží!
Skutečně, takový HW neměl spatřit světlo světa!
Něco jiného je přetaktování a něco jiného je bricknutí pomocí skriptu nějakého vtipálka, který do repozitáře přidá vhodně zakuklený příkaz rm. App, on ze příkaz rm rf dá velmi pěkně obfuskovat, že na první pohled vypadá naprosto neškodně, třeba jako úklid nějakého pracovního adresáře.

Jenze ten HW neznicis, jen ho proste bez externiho programovani znova nenastartujes. Stejne jako 100% vseho, kdyz tomu prepises firware. A muze za to vyhradne idiot a systemd.

nestaci len vybrat baterku a vyclearovat nvram?

NVRAM není CMOS RAM, nebo mi něco uniklo?

A co tam jako přesně chceš clearovat, když už to vyclearoval uživatel přes rm -rf /, načež to nenaběhlo, protože dementní EFI implementace daného čínského krumplu nepočítá s chybějící konfigurací a nemá žádné defaultní nastavení, takže to vychcípne hned na POSTu?

vyclearovat zmeny ktore tam user cez rm-fr spravil a drzia sa bateriou pri zivote? Nehodlam to skusat, ale z mojho pohladu by sa po odpojeni od AC, vybrati baterie a opatovnom zapojeni baterie mali nacitat povodne hodnoty

No, suverénně nejhorší zkušenost mám z nedávné doby s DD-WRT. To, co se děje v "bugzille" tam, nad tím zůstává rozum stát. Bug o bricknutí routeru v důsledku moc velkého souboru s FW (po aktualizaci nějaké "nezbytnosti" na novější, nabobtnalejší verzi) asi 20x dokola označen jako invalid, aby byl po několika měsících opraven. A naprosto stejně to tam vypadá s většinou ostatních.

No je fakt, ze sem si uz stacil premazat MBR u disku s cryptsetup partition. Zrovna zaloha tabulek UEFI na konci disku me zachranila. Ufff - skvelej vynalez. Premazano prave zapisem do sda (dd if=/dev/zero of=/dev/sda). Stane se, kdyz clovek pouziva yocto-like komercni systemy ktere obsahuji zastarale deployment skripty.
Pripadne mi, ze se systemd se chova podobne jako instalace MS-DOS. Instalace automaticky premazala MBR - bez upozorneni, dotazovani uzivatele, autodetekce jinych partition nebo instalovanych OS - proste nezajem.

Kdyby jen widle ... tuhle sem nekde nahazoval tuxe, a ten mi vynadal, ze ten MBR neni tak uplne widlousi ... tak sem zkoumal a nasel, ze najeka podelana gameska si tam nekam flakla nejaky to DRM .... samo zcela bez ptani/upozorneni.

Nepletete si UEFI a GPT?

Mam nejake dosky s UEFI, ale nikde nepouzivam SystemD. Ako som pochopil, tak sa ma tento problem netyka, ze?
V tom pripade by titulok snad mohol zniet aj "Počítač s UEFI a SystemD se může nenávratně poškodit použitím rm -rf /", nie?

Problem se tyka kazdeho, kdo ma namountovany efivarfs pro zapis. Systemd ma maslo na hlave, protoze mountovani efivars je v nem hardkodovane. Uzivatel tak ani nemusi vedet, ze ma efivars pripojene, protoze o to nikoho neprosil.

Uzivatel toho ma tolik pripojene, ze ani nevi, co vse ma pripojene. Nedelejte si iluzi, ze znate vsechny detaily o bezicim systemu, at uz je z jakkekoliv firmy.

Opravdu to je tak zákeřné, že to poškodí PC? Nebo jenom systém? Chtělo příště ubrat na senzačnosti.

Opravdu to muze dostat desku do stavu, kdy je treba vypajet flashku, ve zvlastnim pripravku do ni nahrat defaultni hodnoty a znovu naletovat zpatky. Pokud ma uzivatel trochu mensi smulu, staci na pamet pripravek "nacvaknout" a neni treba ji vyndavat.

Zapomněls sis ráno nasadit mozek. Když udělám rm -rf / tak asi žádný systém nezbyde. #thedement

A jak to uděláš, když ne použiješ sudo. Ty bezmozku.