Smazání Linuxu na UEFI může zlikvidovat počítač

Kernel developer co se věnuje UEFI v tomhle bude asi větší autorita než Python.P, ale když to říkáš...

Protože Lennart Poettering. Systemd si vyhrazuje právo tam zapisovat, kdykoli se mu chce, z diskuse Lennart nakonec unikl tím, že nabídl volbu "ro" v /etc/fstab. Ano, v tom /etc/fstab, který Lennart tak nenávidí a chce ho zničit.Ale zase je to velbloud z komára, reálná využitelnost naprosto shodná jako na Windows. Akorát Linux má mocný nástroj, který vám to umožní bez stahování binárních blobů. Vsadím se, že první zneužití přijde s Windows.
A pak se ptejte, proč tam Windows chtějí zapisovat.A nakonec poselství Lennart Poetteringa, pokud se vám nelíbí, co dělá, sedněte si ke klávesnici a udělejte to lépe. Rozdíl mezi většinou diskutérů s Lennartem je v tom, že Lennart něco udělal, zatímco oni to kritizují.

Obávám se, že toto je přesně ten případ kdy platí "kdo nic nedělá, nic nepokazí". Když je na Linuxu tolik špatných věcí, měl si udělat vlastní OS, nebo si alespoň Linux forknout a udělat si z něj třeba Pinux. Ten člověk zatím dokázal maximálně doj*bat spoustu léta funkčních věcí, ve spoustě případů dělá SystemD přesnej opak toho, než na co má být a rozbíjí ještě víc to, co měl řešit. Skoro to vypadá, že chce udělat z Linuxu druhej Windows, aby si člověk nemohl být nikdy ničím jistej. Ke mně má každopádně SystemD vstup zakázán, když jsem nucenej ho někde přetrpět, připadám si stejně, jak když jsem kdysi poprvé nainstaloval nějaký SuSE, tuším snad 6.1 nebo 6.2 a byl jsem totálně ztracenej, nechápal jsem co to dělá, proč to dělá a proč mi půlka věcí nefunguje.

Ubuntu od nějaký verze (nevim jaký) přešlo na systemd a já jsem to nijak nezaznamenal. Nic nepřestalo fungovat, všechno je stejný jako před tím. Takže pro mě napsal kus fungujícího SW.A třeba zrovna etc/fstab považuju z pohledu obyčejnýho uživatele za zvěrstvo. U PC mám externí disk a chci, aby byl po bootu připojený. OK, zadám to do etc/fstab. Jenže pak ho vypnu a počítač mi nenabootuje, protože nemůže najít harddisk. Co to je za blbost!Naštěstí Plasma 4 přidala funkci "auto-mount" do oznamovače zařízení. Pak jí ale zase ve verzi 5.0 odstranili. Naštěstí ji po mém několikátém upozornění v 5.5 vrátili zpátky.

> Ubuntu od nějaký verze (nevim jaký) přešlo na systemd a já jsem to nijak nezaznamenal. Nic nepřestalo fungovat, všechno je stejný jako před tím. Pretoze Canonical a Debianisti stravili 2 roky wrappovanim SystemD do niecoho, co aspon v zaklade funguje ako ma. Prial by som ti zazit prechod na Archu.> Pak jí ale zase ve verzi 5.0 odstranili.Pretoze SystemD asimilovalol udisk, ktory bol za mountovanie zodpovedny a vzapati zmenilo interface Nevravel si, ze po prechode vsetko fungovalo?

Co bylo za problém na Archu? Přešel jsem na několika zařízeních a žádný problém jsem nezaznamenal.

Bojim sa, ze to by bol trocha dlhsi zoznam, ale boli to klasicke problemy - systemd crashne, takze kernel panic, nenahodi niektore nedolezite sluzby (napr. sshd), na servery mi raz update premenoval sietove karty...Z mojich strojov nezvladol korektne upgradovat ani jeden, takze som nakoniec dal Archu vale.

Ale to odstranilo KDE, ne systemd. Ale je samozřejmě možný, že to spolu nějak korelovalo.

http://commit-digest.org/issues/2014-04-27/moreinf... ...

"Ubuntu od nějaký verze (nevim jaký) přešlo na systemd a já jsem to nijak nezaznamenal. Nic nepřestalo fungovat, všechno je stejný jako před tím."
takže pro mě napsal kus zbytečnýho SW, který řeší věci dávno vyřešené přesně tak jak mají být - spoustou samostatných kousků, které se dají kombinovat a nahrazovat dle libosti. Akorát zatáhl do systému hromadu nových bugů, a vlastních nesmyslných názorů - například zastavit boot kvůli prkotině bez možnosti pokračovat, teď je to zcela nesmyslné připojení efivars, o úžasném chování při změně různého HW ani nemluvím. Minimálně 80 procent průšvihů z poslední doby, který jsem řešil na CentOSu souviselo se SystemD.
Co se týče Plasmy, používám ji taky (na Gentoo), od začátku live verzi (poslední vývojové verze z gitu) a nepamatuju si, že by mi nefungovalo připojování médií v nějaké verzi. Spíš bych to viděl jako Ubuntu specific. Nicméně to je přesně místo, kam podobné fičury patří. Toto rozhodně nepatří do kompetnce čistého (čti neSystemD a bez DE) systému, aby si dělal, co uzná za vhodné.

Problém s funkčností jako norm. uživatel nezaznamenáte ... Ale zkuste si jenom upgradovat Debian ... Peklo má jméno SystemD

>všechno je stejný jako před tím
jen pokud nezačneš systemd pořádně využívat.
Jak bys třeba řešil přes init skripty nastavení CPU kvóty 20% pro všechny procesy v jedné cgroup?
Napsání vlastního unit file je oproti init skriptu triviální a je těžší udělat chybu. Systém závislostí a další mraky vlastností taky super.
journalctl je mnohem přehlednější než logy generované syslogem (přesto si ho ponechávám jako zálohu)Neříkám že systemd nemá chyby, ale pro mě je to správná cesta.

> Jak bys třeba řešil přes init skripty nastavení CPU kvóty 20% pro všechny procesy v jedné cgroup?cgexec?

Nutno dohackovat do init skriptů pro každý proces. V systemd unit mi pro základ stačí
CPUQuota=20%
rozhodně mi to připadá jako čistší a pro správu přehlednější.

Nevidim rozdiel v upravovani systemd unit a "dohackovani" rc skriptu.Ostatne, uz z definicie nemoze byt nic, co by systemd unit - tupy konfigurak - zvladol, zatial co rc script nemohol

Když se podívám třeba na rc skripty třeba v debianu, rozdíl v přehlednosti a udržovatelnosti vidím na první pohled :) Ale dobře, takže třeba: Závislosti, monitoring běžících služeb. Oboje tak nějak jde řešit i v sysvinit, ale oboje tak napůl.

Ja viem, ze sa zavislosti medzi sluzbami casto uvadzali ako hlavna vyhoda systemd, ale pravdou je, ze uz v dobe, ked bol systemd novinkou vedel zavyslosti riesit snad kazdy pouzivany init.A monitoring so sposobom, akym sa zluzba spusti nema nic spolocne.

Se způsobem spuštění ne, s následnou správou ovšem ano.

Problém je v tom, že závislosti, monitoring služeb a spousta dalších SystemD fičur je přesně to, co se rozdrbe přesně v okamžik, kdy se to nejmíň hodí. Chování se mění s každou verzí podle nálady toho debila. Celá tahle aféra má jediný řešení. V další verzi kernelu zakázat mountovat efivars RW úplně a pak může debil brečet, že se mu to nehodí. Jestli je podle něj v Linuxu všechno špatně, může si to udělat po svým. Buď od nuly, nebo si může celej kernel forknout a udělat si z něj třeba Pinux.

Psal jsem o automatickým připojování disků. Když například připojím USB disk, tak aby se sám namountoval nebo aby byla hned po startu připojená Windows partition. Já s tím jedním klinutím problém nemám, ale vysvětlovat to přítelkyni, proč ve Windows nemusí a v Linuxu musí, se mi nechtělo. S obývákovým PC zatím stejně zůstávám na Plasně 4 a Kubuntu 14.04. Intelu se totiž v kernelu 3.16 podařilo rozbít ovladač grafický karty i915 a doteď to ještě nikdo neopravil. Oprava nebude asi ani ve 4.5, pokud vůbec někdy bude, protože k bug reportu přibývají jenom další hlášení identickýho problému, ale žádný řešení. Naštěstí se to dá alespoň obejít tím, že nechám GPU běžet pořád na plný výkon. Ale to u trvale zapnutýho obývákovýho počítače nepovažuju za ideální řešení.

Zajímavé ... Automatické připojování disků ("bez klepnutí") existuje. Řeší se (teď přesně nevím kterým programem), ale na úrovni uživatelových práv. Disk se onhot mountuje do /run/user/ ...

V KDE to funguje bez jakýhokoliv dalšího programu už několik let. Akorát s příchodem Plasmy 5.0 se ta funkce jaksi ztratila a vrátila se až v 5.5. Disk se připojuje do /media/uživatel/název_disku.

Smazat partition s EFI jde celkem snadno,přes jakýkoli 3rd nástroj na partitiony. Možná i GParted to dokáže.

Tohle není o mazání EFI partition, ale o mazání přímo dat z firmware

Přesně ... Pokud chceme udělat tuhle prasárnu, tak je potřeba i přidat volbu --no-preserve-root ;)

Ty zřejmě vůbec netušíš, co je UEFI

Ono vůbec vyndavat disk z počítače na to, abych ho smazal, což můžu udělat nabootováním z CD nebo USB (klidně rovnou v tý instalačce Win7) je dost zajímavej způsob, jak ztratit záruku a spoustu času něčím naprosto ale naprsoto zbytečným.

UEFI není na disku.

ze te bavi udelat ze sebe bl..ba.. system reserved fakt neni efi ba ani uefi..

Problem UEFI je v tom, ze to zase vyrobci ne uplne zvladaji implementovat spravne. Treba krasny problem na nekterych deskach (Samsung) bylo, ze po nekolika instalacich Fedory se zaplnila nvram (stacilo se dostat nad 50%), garbage collector se nekdy pustil, nekdy ne a jedine reseni bylo preflashovat UEFI...

Jo, zdravy rozum. To by clovek cekal, ale...
A hlasku by to vratit mohlo. Nejakou uzivatelsky privetivou ala Mrkvosoft: "Neco se porouchalo"
To pak clovek hned vi na cem je.

Pokud mluvíš o novém přívětivějším bluescreenu tak tam ta chybová hláška je. A pokud potřebuješ nutně vědět chybu tak stačí při takové chybe zmáčknout SHIFT+F9 spustíš tím cmd jako administrator a mužeš si jit vesele hledat logy. Nevím jestli to funguje v jakékoliv chybě ale při instalaci ano.

Hlupákovi se tohle stane celkem snadno.

No hlavně by měl autor napsat, že cokoli provádí uživatel s právy roota, je na jeho vlastní nebezpečí. To znamená, že musí vědět co dělá a když ne, tak by to neměl dělat. A když je hračička, ví že je pod rootem a přesto zkouší, co to udělá, tak si za to může sám. Systemd je sice prasárna na ntou, ale v tomhle případě bych Lennarta spíš neobviňoval.

Osobně mi připadá, že tady mají máslo na hlavě převážně autoři HW. Podobné chování by snad mohlo být důvodem k reklamaci jako vadný návrh.

Je to problém hlavně hardware. A ano, mount jako read only tenhle průšvih jen částečně skryje, ale nevyřeší dostatečně. Lennart má pravdu v tom, že jestli ten problém jde někde efektivně řešit, je tím místem jádro systému. Ne systemd.

Proč to takto dělat? Pro srandu... je to zábava sledovat jak to všechno mizí.

Tedy je to zábava ve virtuálu a 1x úplně stačí. Taky nevím proč to dělat na ostrém systému. To už je lepší dd if=/dev/zero of=/dev/sda (tedy přepíše celý hdd nulami a smaže tak vše co tam bylo).
Navíc jak bylo řečeno rm -rf / neudělá nic, ani když se před to napíše sudo. Je potřeba ještě přidat další parametr, který potvrdí že je to opravdu myšleno vážně.

a ani jeden z vas mudrlantov nenapise, co teda tomu rm -rf chyba... takych ludi nema nikto rad.

man rm ... dilinko

ty si tiez urcite velmi popularny...

tak pro tebe mám jeden pěknej: nabootuj do command line a dej "format C:" (bez uvozovek) a enter, pak yes/ano a enter.. (snad starý příkazy fungujou i na těch novejch omalovánkách)

No, to si mi teda dal, ty profik. Ale aspon to "nabootuj do command line" bolo zabavne. Ono totiz kazdy windows ma jednoducho vyvolatelny prikazovy riadok, ak je ho treba (co vacsinou nie je, narozdiel od inych, menej rozvinutych OS... ). Ale to je taka choroba vacsiny linuxakov robit vsetko co najkomplikovanejsie a zit zaseknuty v ere textovych uzivatelskych rozhrani.

ta 9 ve jmene bude vek? To by pak vysvetlovalo ten problem prikazove radky. Naucit se cist a psat nejakou dobu trva, ale klikat na obrazky se da zvladnout relativne brzo. :)Delam si legraci, ta valka mezi klikacim a neklikacim je tady uz dlouho, ale je fakt, ze i ja jako odkojenec windows, jsem nakonec u linuxu skoncil, protoze hromada veci je proste genialni. Na co we windows potrebuju dve utilitky a hromadu casu, to v linuxu udelam jen nativnimi nastroji. A to se nemusime bavit o serveru, i kdyz zrovna na tehle pude ma linux navrh zcela urcite.

si to zabil za tvou nevědomost bohužel nemůžu.. ale za starých časů bývalo zvykem, že si nabootovaný widle nedaly pod zadkem zformátovat C:\ ale jistě si taký borec, že ty tvoje překecáš a sory, já mám rád komplikovaný věci, ty jednoduchý sou pro lamy, není s nima taková zábava
(edit: chyběla čárka)

Názor byl 1× upraven, naposled 04. 02. 2016 07:48

To asi nic neudělá, napíše to že disk je aktuálně používaný.

musí rebootnout do command line..

za to nemuze UEFI, to je v tom nevinne
treba moje UEFI vypada jak klasickej BIOS a naopak mam (mel) jsem doma jednu starou 486, kde byl klikaci BIOS taky

To, jak to vypada, nema zadnou souvislost s tim, ze je to "UEFI"

koukam, ze Lennart Poettering je vazne idiot

O tom uz dnes pochybuje len malokto

A co s tím má SystemD co dělat? /sys být namountovaný musí a do jeho obsahu Lennart nemá co kecat.

/sys namountovany byt nemusi, aj ked obyvkle byva. /sys/firmware/efi obyvkle namountovany nebyva a mountuje sa docasne, len ak ho nejaky nastroj potrebuje, presne pre TENTO dovod.Ale kedze systemd od nedavna obsahuje i boot manager, drzi si pripojene evi/vars v rw mode neustale.

Dik za info, to pak meni situaci.

I tak to není chyba kterou by měl systemd řešit. To že problém schováme za jeden ro mount ho neodstraní.
https://twitter.com/mjg59/status/693494314941... ...

Kupodivu ano, osetri totiz ten najpravdepodobnejsi sposob likvidacie HW - omylom ( https://github.com/MrMEEE/bumblebee-Old-and-... ... ) alebo blbou lamou ( http://www.lamer.cz/quote/1... ).Ale Systemd by hlavne s tymto vobec nemal suvisiet. Init si nema svojvolne pripajat filesystem len pre to, ze to jeden blb uznal za vhodne. Zial, nahodne zmeny konfiguracie su pre systemd rovnako typicke ako neochota vlastne chyby riesit

Jinak tohle platí jen v případě některých desek kde nejde udělat jednoduše factory reset UEFI.