Další z řady bizarních chyb v UEFI

LWN.net upozorňuje na další z řady bizarních chyb v UEFI. Matthew Garrett (mjg59) při instalaci Fedory na počítači Lenovo Thinkcentre M92p zjistil, že UEFI tohoto počítače dokáže zavést pouze "Windows Boot Manager" nebo "Red Hat Enterprise Linux". Instalace Fedory proběhne bez problémů, po restartu počítače se ale ve výběru nainstalovaných operačních systémů vůbec neobjeví. Nejedná se přitom o problém s UEFI Secure Boot. Po bližším zkoumání bylo zjištěno, že UEFI v Lenovu Thinkcentre M92p řetězec "Fedora" prostě ignoruje. Dokáže zobrazit pouze "Windows Boot Manager" nebo "Red Hat Enterprise Linux". Uživatelům Fedory a dalších linuxových distribucí tak nezůstává nic jiného, než povolit Legacy Boot.

16.11.2012 16:23 | Ladislav Hagara | Zajímavý článek

Komentáře

[pepe_]

Chinašmejďárna ? Lenovo už není lenovo ?

[Ovocníček]

Spíš chyba v Lenovu než UEFI samém, ne?

[little.owl]

To neni chyba v UEFI, ale v implementaci UEFI konkretnim vyrobcem, mozna zde i zamer. Vyvojare Lenova bych za jejich UEFI tloukl od rana do vecera.

[Ondrej 'SanTiago' Zajicek]

Ono chyba v UEFI je vubec to, ze zde je prostor pro takovehle chyby. Tedy ze se pri navrhu nedrzeli KISS. Kdo po zkusenostech s tim, jaka byla historie problemu s ACPI, cekal od UEFI neco neco jineho, je znacne naivni.

[little.owl]

To je Intel, nicmene BIOS byl jiz neudrzitelny.

[bukk__e]

Jo. Úplně neudržitelný. Kazil disky, tedy, ehm, zisky.

[little.owl]

GPT, uz zadne prepisovani boot sektoru u vice instalovanych OS, genericky model driveru, moznost updatovat firmware bez nutnosti Windows, nezavislost na platforme, takze muzete mit v podstate stejne UEFI i na ARM, ne natvrdo vse vazane na x86 .... Pozitiv je plno.

[pc2005]

uz zadne prepisovani boot sektoru u vice instalovanych OS

+, tedy pokud to někdo v implementaci nezmrví...

genericky model driveru

Jakože bude celý ovladač closed source ve flash? Blé...

moznost updatovat firmware bez nutnosti Windows

512B (minimálně) každýho čipu a amiboot.rom. Pokud to někomu nefungovalo, tak to byla chyba implementace (což je u UEFI taky možný). Award měl něco podobnýho.

takze muzete mit v podstate stejne UEFI i na ARM

Nemůžu, na ARMu nemusím být schopen nabootovat UEFI linux .

[little.owl]

Jakože bude celý ovladač closed source ve flash?

Ne to, ne, jedna se o inicializaci. V soucasnosti tam uz zakladni drivery jsou, vcetne firmware, napriklad pro sitovky, kvuli PXE bootu. Ten je trend je skutecne takovy, ze UEFI prednastavy HW tak, aby OS byl schopem to maximalne genericky pouzit, proste ty nejvice HW specificke veci a inicializace, ktere se doslova lisi od model od modelu bude delat UEFI.

512B (minimálně) každýho čipu a amiboot.rom.

Puvodni amiboot.rom predpokladal existency floppy a klavesnice majici interrupt, tohle uz davno neni pravda a vse se strasne zeslozitilo. Tam se nejedna jenom o update UEFI, ale treba i FW hardisku (SSD) ci RAIDu. Proste nakopirujete flashovaci EFI programek a novy firmware do EFS a spustite ho a ono to provede update a nemusite se starat, jestli mate WinXYZ, LinuxABC ci nejaky HackintoshGH.

[pc2005]

Inicializace síťovky byla už na ISA síťovkách ve formě buď epromky na kartě a nebo 0x55 0xaa rom modulu. Starší realizaci neznám, neboť z té doby nemám žádný hw . Tomu, že by UEFI nastavil hardware na nějaké obecné použití bych věřil (BIOS nedělal nic jinýho). Ovšem, že to často nebude použitelné a u hardware bude využit jen zlomek jeho možností je zase jiná. Koneckonců je to vidět na BIOSu (i když je fakt, že jsem viděl nějakou diskuzi s Kontronem, kde chtěli lidi nějakej další videomód a v další verzi už ten videomód byl).

Pokud bude muset OS dál tu periferii ovládat, tak to stejně bude jedno, zda je inicializace v UEFI (kromě bootovacích zařízení, kde je to požadavek a není to tedy klad UEFI). Spíš se bojím toho, že ty inicializace nebudou dostatečně kvalitní a návrh driverů zleniví. Doufám, že to není varianta, kdy bude OS volat funkce UEFI na lowlevel ovládání (blé to už tu bylo u 16-bit BIOSu).

Puvodni amiboot.rom predpokladal existency floppy a klavesnice majici interrupt, tohle uz davno neni pravda a vse se strasne zeslozitilo.

A taky to bylo ale bezpečné. Klávesnice na PS/2 nevyžaduje žádné transfer buffery a v zásadě stačí, když jsi schopen zapisovat na jeden jediný (!) port. Floppy se ovládá o něco hůř, ale oproti několika vrstvám USB je to pořád lahoda. Co se týče zesložitění: mě se zdá, že to je jen důsledek požadavky na více a více high-tech programovací interface. Ale neměl by být problém alokovat v ty flash víc místa (ani vlastně nevím zda to bulo opravdu 512B). Tak jako tak, mě UEFI nenechá nabootovat flasher ze zvukové karty .

Tam se nejedna jenom o update UEFI, ale treba i FW hardisku (SSD) ci RAIDu. Proste nakopirujete flashovaci EFI programek a novy firmware do EFS a spustite ho a ono to provede update a nemusite se starat, jestli mate WinXYZ, LinuxABC ci nejaky HackintoshGH.

Tohle šlo už na prvním počítači, co měl flashovatelnej BIOS. Kód boot sektoru se totiž od .com programu liší jen v jiném offsetu a nepoužíváním DOS funkcí. Takže šlo udělat flasher a umístit ho na jakékoliv zařízení, co umí BIOS bootovat. V tomhle bude mít UEFI asi navrch, pokud třeba certifikáty vynutí použití jednoho postupu. Jiná ale je, že se mě tohle omezování moc nelíbí, protože to zavání jednosměrkou.

[little.owl]

To je exkurze do historie HW, to uz je liche a novy HW je proste designovan jinak.

[pc2005]

To je exkurze do historie HW, to uz je liche a novy HW je proste designovan jinak.

To by mě teda zajímalo jak, něco co nevím? (a hlavně na jakou větu z kterého z mých 4 odstavců).

Předpokládám, že myslíš usb klávesnici: Pokud bude UEFI poškozeno a bude vyžadovat lowlevel opravu, tak ti fakt usb klávesnice, která potřebuje inicializaci PCI, USB a tunu bufferů pro deskriptory → nutná inicializovaná RAM určitě pomůže . Nehledě na to, že při poškozeném BIOSu to ten amiboot.rom flashoval automaticky.

Co se týče BIOS modulů, tak prohledávání nultého wordu každejch někde 0x2000 je fakt starý, ale to byl příklad neinovativnosti UEFI. U BIOSu měly už dávno oba výrobci lepší modulární design.

Osobně se mě ale nelíbí pokud má firmware schopnost zapisovat na čip, kde je umístěn, resp. využívá toho na jiné akce než kompletní update.

[xkucf03]

Osobně se mě ale nelíbí pokud má firmware schopnost zapisovat na čip, kde je umístěn, resp. využívá toho na jiné akce než kompletní update.

Zkusil jsem na jedné desce s UEFI stáhnout ROM a vypadá to, že se při každém bootu trochu změní – takže už to Read Only Memory moc není.

[pc2005]

Pomocí nějaké utility nebo ručně? U ručně by se to měnit mohlo. Nejlepší by na to byl třeba uniflash, ale pochybuju, že bude mít podporu nejnovějších čipsetů (podle readme neumí už ani můj i945 čipset ).

Co se týče vlastní modifikace, tak stačí drobná chyba/neošetření indexu stránky a pápá UEFI . Sice se to snaží specifikace omezit (nepravděpodobná sekvence zápisů nepravděpodobných hodnot na nepravděpodobné adresy), ale to nemusí stačit.

[xkucf03]

Pomocí flashromu. Ještě je možnost, že by chyba byla v něm – podpora pro tuhle desku přibyla nedávno – ale to se mi moc nezdá, protože ty stažené ROM nejsou úplně nesmyslné a až do dalšího bootu se dá opakovaně stahovat ta samá ROM.

[pc2005]

Asi by mohlo u flashromu fungovat. Osobně bych se flashování BIOSu pod preemptivním operačním systémem bál (takhle jsem si jednou pod w98 smazal BIOS a s kámošem jsme museli hotflashovat ).

Myslel jsem třeba to, že spousta BIOSů se shadowuje do RAM a pak obvykle provede readonly lock. Teoreticky by šlo, aby před readonly lockem si tam něco poznamenal. Flasher pak musí znát registr čipsetu, kterým se ten lock vypíná a prioritizuje se přístup do flash čipu. Když bys pak přečetl bez toho přepnutí, tak přečteš jen ty RAM data (a uložíš si je do backup souboru, který pak v nouzi naprogramuješ pod w98 ).

Jinak díky za pošťouchnutí, provedl jsem kompilaci (na k7s5a se mě v tom nechtělo hrabat, protože v té době to na sis735 nefungovalo - bez datasheetu a podpory). Stáhnul jsem si vlastní BIOS a trololo:

Press <SpaceBar> to update BIOS..
Confirm update BIOS? (y/n) .
BIOS checksum error detected..
Begin remote BIOS flash? (y/n).
Starting remote flash.
Upload new BIOS file using Xmodem protocol.

P.S. "Značka SPACEBAR není povolena!"

[little.owl]

Pokud bude UEFI poškozeno a bude vyžadovat lowlevel opravu, tak ti fakt usb klávesnice, která potřebuje inicializaci PCI, USB a tunu bufferů pro deskriptory → nutná inicializovaná RAM určitě pomůže .

A presvedcite kvuli tomu vyrobce aby to delali jinak a opet vam pridali floppy a zadratovali klavesnici bez nejakeho bridge?

[pc2005]

O tomhle jsem ale nepsal, psal jsem o tom, že i BIOS to uměl. Samozřejmě pokud by to šlo vylepšit, tak proč ne, BIOS to dovoluje. V BIOSu to tedy realizovat šlo (a i bylo) a argument, že je v tomhle UEFI inovativní tím padá.

BTW umí UEFI bootovat z floppy?

opet vam pridali floppy a zadratovali klavesnici

No desku bez PS/2 bych si asi nekoupil. USB je na takovou trivialitu jako klávesnice škoda (byť na to byl USB původně určen asi).

P.S. Dnes je vysoká šance, že pokud bude mít deska LPT, tak bude mít i FDD. PS/2 by měl jít triviálně emulovat přes GPIO (a i tak bude jednodušší než usb stack). Jinak už se blíží iterace Mooreova zákona, kdy půjde i ta FDD přes GPIO (má dost komplikovaný způsob přenosu dat a třeba na PICu, co mám, by to ještě šlo blbě).

[little.owl]

BTW umí UEFI bootovat z floppy?

Modul pro to existuje, ale vyrobci ho uz asi nebudou podporovat.

Znovu, UEFI ma modularni strukturu a to ktere moduly jsou ve vasem firmware je rozhodnuti vyrobce, nikoliv limitace UEFI. Pokud modul, ktery potrebujete pridat, neni k dispozici, muzete si ho nasypat do ESP oddilu a zavolat, klidne i rucne ci z shell skriptu.

Muzete si napsat i sam svuj modul, ktery vam nabootuje, i z toho paralelniho portu. Koukne se zde ci zde.

[pc2005]

Takže jen napsat vlastní? To se moc nemění oproti BIOSu (třeba kdysi podpora >4GB HDD). Bude to na x86 fungovat, když budu chtít využívat služeb Secure Bootu (rozhodně nechci kupovat klíč přes MS)?

[Jendа]

Proste nakopirujete flashovaci EFI programek a novy firmware do EFS a spustite ho a ono to provede update a nemusite se starat, jestli mate WinXYZ, LinuxABC ci nejaky HackintoshGH.

A proč přesně ten stejný prográmek nemůže být šířen ve formě bootovací diskety s FreeDOSem či ISO s Linuxem jako dnešní upgrade FW?

[pc2005]

Jak jsem psal nad tebou, tak i FreeDOS je overkill.

[little.owl]

Muze, ale proc by to meli hlavni hraci chtit?

[Jendа]

Z toho stejného důvodu, proč by měli chtít dodávat ho pro UEFI?

[VM]

1. jaká nezávislost na platformě u nejnižší SW vrstvy? V čem je stejné UEFI na x86 a ARM - v binárním kódu různých procesorů? V ovladačích pro různý HW? Co z toho bylo nutné vázat na x86?

2. co z toho ostatního nešlo do BIOSu dodělat, kdyby někdo chtěl?

[Jendа]

2. co z toho ostatního nešlo do BIOSu dodělat, kdyby někdo chtěl?

Podle mě sjednotit BIOSy a donutit je respektovat nějaký jeden standard by přineslo zhruba stejně práce jako napsat rovnou něco nového (třeba UEFI nebo něco podobného).

[little.owl]

jaká nezávislost na platformě u nejnižší SW vrstvy? čem je stejné UEFI na x86 a ARM - v binárním kódu různých procesorů?

Nejnizsi vrstva je samozrejme HW zavisla, jde o to, kolik % kodu to je a ze je to napsane v C. Ale hlavne, specifikace definuje interface mezi UEFI a OS, vcetne calling convention a sluzby ktere to musi poskytovata to zpusobem ktery je celkem prenositelny napric platformami.

Co z toho bylo nutné vázat na x86? ... co z toho ostatního nešlo do BIOSu dodělat, kdyby někdo chtěl?

Najdete si neco o puvodnim BIOSu. Pokud vyhodite x86 zavisle veci, napsane navic v assembleru, veci ktere nikdo uz nepouziva neb se tam vlaci od dob PC XT nebo veci zastarale jako MSDOS partition table ci memory model, nezbude vam skoro vubec nic. Ta dodelavka by znamenala zacit znovu a pak kvuli interoperatibilite potrebujete specifikaci a jste tam, kde jsme ted.

[pc2005]

Ale hlavne, specifikace definuje interface mezi UEFI a OS, vcetne calling convention

To šlo i ve standardním BIOSu. Prostě by se udělal novej interface. Celý by to pak bylo najednou zpětně kompatibilní na rozdíl od UEFI, kde je legacy support tak jako tak ale s tím, že je vzájemně výlučný.

sluzby ktere to musi poskytovata to zpusobem ktery je celkem prenositelny napric platformami.

Snad jedině, kdyby byl v UEFI perl interpreter . Schválně jak se budou ukládat parametry do registrů na zásobníkové architektuře . Z pohledu non x86 architektur ty architektury zcela jistě UEFI "poděkujou" za zavedení kompatibility s x86 calling convention.

Najdete si neco o puvodnim BIOSu. Pokud vyhodite x86 zavisle veci, napsane navic v assembleru, veci ktere nikdo uz nepouziva neb se tam vlaci od dob PC XT nebo veci zastarale jako MSDOS partition table ci memory model, nezbude vam skoro vubec nic. Ta dodelavka by znamenala zacit znovu a pak kvuli interoperatibilite potrebujete specifikaci a jste tam, kde jsme ted.

BIOSy se už dávno nepíšou v assembleru (jedině, že ten BIOS z cca '94 by psal úplný šílenec nebo genius). LinuxBIOS (→coreboot) začal podle wiki v roce 99 a už v první verzi měl assembler jen úplně na začátku pro nastavení PM. Navíc ten BIOS tam stejně musíš mít ve formě legacy módu a tedy nelze brát jeho neexistenci jako výhodu UEFI.

[little.owl]

Schválně jak se budou ukládat parametry do registrů na zásobníkové architektuře .

Na uplne nejnizsi urovni je to HW specificke, ted to podporuje 80x86, Itanium a amd64 a dalsi jsou na ceste - treba ARM.

Celý by to pak bylo najednou zpětně kompatibilní

Radsi ne. Jsem rad ze ten balast tahnouci se od dob PC XT bude splachnut.

[pc2005]

Na uplne nejnizsi urovni je to HW specificke

For 32-bit 80x86, the calling convention used is the standard C calling convention. For Itanium, the calling convention is defined in the "Intel(R) Itanium(R) System Abstraction Layer Specification".

For 64-bit 80x86, Microsoft's x64 calling convention is used.

Hmm toliko k univerzální kompatibilitě. Navíc bych se divil, kdyby najednou všichni výrobci UEFI softwaru začali hrrr dělat portabilní kód.

BTW

Because the IA-64 only supports 64-bit instructions, the PC BIOS couldn't be used, therefore Intel developed the EFI specification.

FFFFUUUUUU!! Mor na ty vaše Itania..

Radsi ne. Jsem rad ze ten balast tahnouci se od dob PC XT bude splachnut.

A to právě nebude, neboť legacy mód . Leda, že bys ho chtěl odstřihnout, ale tím ti padá možnost provozovat starý OS (a tím i užitečnost UEFI, je to docela těsně propojené ).

[little.owl]

For 32-bit 80x86, the calling convention used is the standard C calling convention. For Itanium, the calling convention is defined in the "Intel(R) Itanium(R) System Abstraction Layer Specification".

For 64-bit 80x86, Microsoft's x64 calling convention is used.

Ano. Ale fakticky je to Microsoft Portable Executable 32/64. Itanium si vzdy zilo ve svem svete a C calling convention u 32 bit je tam z historickych duvodu - bylo to v prvni verzi specifikace, pozdeji to nemenili s tim, ze to stejne bude jen zalezitost jednoucelovych embedded systemu, tudiz to muze byt mnohem volnejsi.

ale tím ti padá možnost provozovat starý OS

Jaky? Win7/8-64 nemaji s UEFI problem, jediny Linux, ktery jeste pred rokem na UEFI trochu chodil byla Fedora 16-64. WinXp maji problem s GPT a uz jsou stejne na novem HW mrtve. Legacy mod je tam hlavne kvuli aplikacim, nikoliv OS a to uz je take irelevantni. Navic je to komedie - sice diky legacy modu muzete nainstalovat stary OS, ale nenabootujete nebot UEFI chce GPT.

[pc2005]

Nastavovat gcc do Microsoft x64 módu bude docela legrace. Něco takového se za kompatibilní calling convention nedá považovat.

Jaky?

Vyber si .

ale nenabootujete nebot UEFI chce GPT

Tak to je UEFI dost nanic.

P.S. A samozřejmě jakej formát UEFI používá? PE, ble.

[little.owl]

Nastavovat gcc do Microsoft x64 módu bude docela legrace.

Zadny problem, PE je podporovano, gnu-efi tools, na nez jsem vam dal link, to generuji by default.

Tak to je UEFI dost nanic.

Ne. Zkousite provozovat stary OS na systemu, ktery pro to neni designovany, nic vice.

PE, ble.

Vzdy jsem to psal nahore. ELF by byl lepsi, ale PE je OK.

[pc2005]

ad ELF/PE: Hmm jak se pohybuju ve vláknech nelineárně a reaguju ve více současně, tak v tom mám trochu bordel . Spíš to byla taková nelibost nad použitím formátu od firmy, které jde jen o peníze bez ohledu na ostatní.

Ne. Zkousite provozovat stary OS na systemu, ktery pro to neni designovany, nic vice.

Takže byla prostě z fleku zahozena kompatibilita se starými OS. Mám z toho pocit, že z propadáku Itanium (EFI) to prolezlo až na ARM (brrr). Sice chápu, že UEFI přímo by to používat teda nemohlo, ale měl by být všude implicitně nějakej legacy mód (aspoň do doby, než půjdou všechny legacy OS provozovat ve virtualizaci na stejném výkonu jako na původním hw).

[smazáno]

Jaky? Win7/8-64 nemaji s UEFI problem, jediny Linux, ktery jeste pred rokem na UEFI trochu chodil byla Fedora 16-64.

To se neni cemu divit, kdyz UEFI implementace jsou ve stylu UEFI tohoto počítače dokáže zavést pouze "Windows Boot Manager" nebo "Red Hat Enterprise Linux" ... to je ve veku open source a otevrenych standardu k smichu.

[Jendа]

GPT

Proč by tohle měl řešit firmware? Já od něj očekávám nahrání nějakého sektoru z disku do paměti a skočení na začátek, nic dalšího mě nezajímá.

uz zadne prepisovani boot sektoru u vice instalovanych OS

Když instaluju další OS a nechci si přepsat bootsektor, tak ho prostě… nepřepíšu, ne?

[little.owl]

Já od něj očekávám nahrání nějakého sektoru z disku do paměti a skočení na začátek, nic dalšího mě nezajímá.

To je vas problem, ze mate takhle technicke slabe a problematicke pozadavky. GPT, vcetne bootu z EFS je snad nejlepsi vec, co UEFI prinesl.

[pavlix]

To je vas problem, ze mate takhle technicke slabe a problematicke pozadavky.

Mně přijdou tyto požadavky velmi rozumné.

GPT, vcetne bootu z EFS je snad nejlepsi vec, co UEFI prinesl.

A přesto je to věc, která je ukrutně pozadu oproti známému aktuálnímu vývoji i oproti tomu, co denně používám. Z mého pohledu je přístup k GPT z BIOSu krokem od modularity k uniformitě. Takový Windows style.

[little.owl]

Mně přijdou tyto požadavky velmi rozumné.

No a? Ja nerikam, ze je to nesmysl, ale ze je to technicky slabe a problematicke. Neresi to sdileni vice ruznych OS aniz by o sobe vedeli, bootovani z externich zarizeni (DVD/CD/USB), ktere vzdycky stalo na vode, chyby tomu jakekoliv genericke pre-boot recovery jako je UEFI shell. Mne kdyz se podela grub.cfg, proste nabootuji do UEFI shellu a opravim to, aniz bych musel hledat rescue CD/disk. Treba Grub2 ma ted na plno zarizeni problem s mode setting a hazi vystup out of range, staci kouknout do bugzilly, pak ti konzole v grubu nepomuze kdyz to selze hned na pocatku, zatimco mode setting v UEFI dodavany vyrobcem funguje spolehlive.

A přesto je to věc, která je ukrutně pozadu oproti známému aktuálnímu vývoji i oproti tomu, co denně používám.

A muzes to upresnit?

Z mého pohledu je přístup k GPT z BIOSu krokem od modularity k uniformitě.

To zni dosti politicky. V cem je pristup k GPT mene modularni ci vice restriktivni nez MS DOS partition table? Vadi ti GUID?

Mluvit o ztrate modularity v tomto kontextu, u cehokoliv, s ohledem na monoliticky BIOS a od pocatku modularniho UEFI je pritazene za vlasy. I cela podpora GPT je jen modul, ktery tam nemusi byt, pokud to nebootuje z disku, ale treba jen ze site.

[Ondrej 'SanTiago' Zajicek]

Neresi to sdileni vice ruznych OS aniz by o sobe vedeli,

On ale neni vubec zadny duvod, proc by zrovna tuhle vec mel resit firmware. Jedna se o hardwarove nezavisly problem, ktery klidne muze resit software tretich stran (akorat vyuzivajici rozhrani firmware pro pristup k hardware). Zkusenost uci, ze firmware ma typicky bidnou kvalitu, pro vyrobce je to okrajova zalezitost a malokdy se resi bugy v nem, takze dava smysl minimalizovat jeho sferu vlivu.

To zni dosti politicky. V cem je pristup k GPT mene modularni ci vice restriktivni nez MS DOS partition table?

Standardni BIOS nevyzadoval MS DOS partition table, jen MBR v prvnim sektoru (coz je mnohem volnejsi pozadavek). Partition table tedy mohla byt resena jakkoliv, zatimco nove musi byt GPT.

Kdyby novy navrh firmware pocital pouze s iniciaci hardware a platformove nezavislym rozhranim pro pristup k hardware ze strany zavadece ci iniciacnich rutin OS, pak by to bylo daleko pruznejsi a bylo mene moznosti neco zvrtat (jako v tomto pripade).

[little.owl]

On ale neni vubec zadny duvod, proc by zrovna tuhle vec mel resit firmware.

Duvody jsem jmenoval. Ja zas nevidim duvod proc by bootovani vice ruznych OS nemelo byt podporovano lepe ve firmware, zejmena kdyz alternativou je Grub2.

Zkusenost uci, ze firmware ma typicky bidnou kvalitu

Jak co, jak kdy a jak kde, jako u kazdeho SW.

pro vyrobce je to okrajova zalezitost

Ne. Bez toho by vubec nic nefungovalo, a nejen na PC.

zatimco nove musi byt GPT.

Diky modularite ani nemusi, ale pro boot z disku je ve Windows vyzadovan.

[pc2005]

Kdyby novy navrh firmware pocital pouze s iniciaci hardware a platformove nezavislym rozhranim pro pristup k hardware ze strany zavadece ci iniciacnich rutin OS, pak by to bylo daleko pruznejsi a bylo mene moznosti neco zvrtat (jako v tomto pripade).

Mě by například ani nevadil ten hi-tech level přístupu k bootu. klidně ať ten firmware načítá z zařízení přímo ELF struktury. Ale určitě bych to nesvěřil closed source firmám. Neboť platí, že čím složitější software, tím víc chyb, což je ve firmware fatální. Pokud by ale kód mohl kdokoliv zkontrolovat, tak v pohodě. Těmito argumenty se ale UEFI stává redundantním, neboť coreboot (i když je fakt, že se mě ještě nepovedlo udělat image chcípe to na nějakých sekcích linkeru).

[pavlix]

Dlouho jsem si chtěl pořídit stroj podporovaný Corebootem, ale zvlášť u notebooků žádná sláva.

[pavlix]

Standardni BIOS nevyzadoval MS DOS partition table, jen MBR v prvnim sektoru (coz je mnohem volnejsi pozadavek).

Nehledě na to, že MBR je v nějaké formě vyžadován i pro GPT.

[Jendа]

A muzes to upresnit?

Podle mě myslí LVM.

[pavlix]

A muzes to upresnit?

Už docela hodně let provozuju partition v LVM. Schopnosti GPT jsou oproti tomu jak z doby kamenné.

Tím netvrdím, že měli použít LVM. Právě naopak. Starý stav byl takový, že pod MBR hlavičku dám bootloader a formát, který potřebuju (LVM či RAID a LVM nad ním).

To zni dosti politicky.

Politicky? To je zcela technická otázka. Mně vyhovuje, když se firmware nestará o věci, o které se starat nemá. Třeba na mých strojích BIOS nemusí řešit ani formát partition tabulky.

V cem je pristup k GPT mene modularni ci vice restriktivni nez MS DOS partition table?

Mimo téma.

Vadi ti GUID?

Jako ten identifikátor? Radši mu říkám UUID. Možná to vypadá jako trolling, ale zde skutečně nevím, na co se mě ptáš.

Mluvit o ztrate modularity v tomto kontextu, u cehokoliv, s ohledem na monoliticky BIOS a od pocatku modularniho UEFI je pritazene za vlasy.

Nicméně, pokud se ta modularita opravdu zhorší, bude to znamenat, že pravda je přitažená za vlasy? Dlé mého názoru čím více zasahuje firmware do toho, co se ho netýký, tím více modularitu ztrácíme.

[little.owl]

Už docela hodně let provozuju partition v LVM.

Fajn. A GPT ti nejak brani LVM pouzivat? GPT a LVM jsou uplne jine urovne a korektni by bylo mluvit GPT partition table versus MSDOS partition table.

Politicky? To je zcela technická otázka. Mně vyhovuje, když se firmware nestará o věci, o které se starat nemá.

Zvovu, narazel jsem na tve tvzeni:

GPT, vcetne bootu z EFS je snad nejlepsi vec, co UEFI prinesl.

A přesto je to věc, která je ukrutně pozadu oproti známému aktuálnímu vývoji i oproti tomu, co denně používám.

Pokud mi chces tvrdit, ze GPT partition table neni technicky krok vpred oproti MSDOS partition table, pak fakt nevim co rici i kdyz chapu, ze tve reseni s LVM na Linux only masine ma vyhody.

když se firmware nestará o věci, o které se starat nemá.

Posouvas to jinam, GPT je primarne o layoutu partition a plno starsich BIOSu ji take podporuje.

Třeba na mých strojích BIOS nemusí řešit ani formát partition tabulky.

Pokud mas jen jeden OS, pak mozna.

ale zde skutečně nevím, na co se mě ptáš.

Fixni list GUID byla jedina vyhrada, kterou jsem zatim vuci GPT zaznamenal.

více zasahuje firmware do toho, co se ho netýký, tím více modularitu ztrácíme.

Modularita systemu a rozsah poskytovanych features jsou kompletne jine veci.

Ve srovnani s GPT a LVM, je nabotnalym molochem prave LVM, byt to ma vice features, a co hure je to pouzitelny jen na jednom OS.

co se ho netýký,

To je velmi relativni. Vzdy mas vice cest reseni a neco se musi vybrat a cokoliv vyberes ma sve slabe a silne stranky. V situaci, kdy 95% podilu na trhu osobnich PC maji Windows, je jasne ze se primarne reflektuji jejich zajmy, pokud by to byl Linux, reseni by mohlo vypadat jinak.

UEFI bude zasahovat do vice a vice veci, zejmena inicializace HW, kterou je v podstate schopen delat jen vyrobce HW a presouvat cokoliv z toho do Grubu ci kernelu bude znamenat, ze podpora v Linuxu bude problematicka - viz. polofunkcni Coreboot ci mode setting v Grub ci problemy v udev s loadovanim firmware.

[Jendа]

GPT a LVM jsou uplne jine urovne

Opravdu? Oboje tak nějak slouží na správu kontejnerů, ve kterých jsou FS, a LVM pod sebou rozhodně nepotřebuje žádnou partition tabulku.

(že bych mezi to stejně ještě rád vsunul ten RAID a šifrování je druhá věc)

Pokud mi chces tvrdit, ze GPT partition table neni technicky krok vpred oproti MSDOS partition table

To on někde tvrdí?

Pokud mas jen jeden OS, pak mozna.

Nejde to i s více OS? BIOS prostě natáhne do paměti první sektor a tam může být klidně zavaděč podporující mnoho různých OS a PPTF (Pavlix Partition Table Format).

[little.owl]

BIOS prostě natáhne do paměti první sektor a tam může být klidně zavaděč podporující mnoho různých OS

Ma to jeden hacek - musi byt LVM friendly.

[pavlix]

Při použití LVM musí zavaděč, který zavádí soubory (ne bloky) umět LVM. Jaké překvapení.

[little.owl]

Mam na mysli, ze onech "mnoho ruznych OS" ktere tam jde provozovat, musi byt LVM friendly. Mas pocit ze Win ci Mac jsou LVM friendly?

[pavlix]

GPT a LVM jsou uplne jine urovne a korektni by bylo mluvit GPT partition table versus MSDOS partition table.

Pokud se na to díváš takto (dle mého názoru zcela chybně), tak chápu tvůj závěr.

Posouvas to jinam

To stejné můžu můžu říci já o tobě.

V situaci, kdy 95% podilu na trhu osobnich PC maji Windows, je jasne ze se primarne reflektuji jejich zajmy, pokud by to byl Linux, reseni by mohlo vypadat jinak.

A mě říkáš něco o politickém pohledu…

[little.owl]

Pokud se na to díváš takto (dle mého názoru zcela chybně), tak chápu tvůj závěr.

Ono to tak, ze GPT je jen pokrocila naharda MSDOS partition table, nic vic.

A mě říkáš něco o politickém pohledu…

Nikoliv, to je ciry realismus. Vzdycky platilo, ze hraci s velkym trznim podilem urcuji smer, ostatne Red Hat to dela na poli Linuxu take.

[pavlix]

Ono to tak, ze GPT je jen pokrocila naharda MSDOS partition table, nic vic.

Právě. Přesně z toho důvodu mi přijde chybné LVM vyčleňovat, jen proto, že umí pár věcí navíc.

[pavlix]

Vzdycky platilo, ze hraci s velkym trznim podilem urcuji smer, ostatne Red Hat to dela na poli Linuxu take.

Ať si dělají, co chtějí.

[xkucf03]

Mluvit o ztrate modularity v tomto kontextu, u cehokoliv, s ohledem na monoliticky BIOS a od pocatku modularniho UEFI je pritazene za vlasy.

Ta modularita je v obou případech, ale pokaždé v jiném směru – u UEFI mám modularitu v rámci jedné vrstvy (uvnitř firmwaru), zatímco u BIOSu mám modularitu napříč vrstvami – firmware si udělá své minimum práce, řeší toho co nejméně a pak předá řízení další vrstvě (zavaděč/OS), která se natáhne z disku.

Nelze říct, že by jeden z těch přístupů byl výrazně horší, každý má něco do sebe… Ale v dnešní době, kdy se Microsoft snaží škodit, kde to jen jde, a omezovat konkurenci (umírající stvůra kope kolem sebe) a jsou tu i jiné subjekty, které se snaží omezit práva uživatelů a sebrat jim kontrolu nad jejich majetkem (počítačem), tak se nemůžeš divit, že spousta lidí chce, aby toho ten proprietární firmware zadrátovaný v čipu na desce dělal co nejméně a chtějí na něm být co nejvíc nezávislí.

[little.owl]

UEFI mám modularitu v rámci jedné vrstvy

Ne. UEFI lze nakonfigurovat tak, ze to nema modul VGA, podporu sitovky, klavesnice ci USB, .... Je jen na vyrobci, jake moduly tam integruje, pripadne na pozadavcich vyroce OS, pro ktere je zarizeni designovane. Standardni UEFI poskytuje ted sluzby jake poskytuje protoze se Microsoft s Intelem tak dohodli. Pokud zarizeni bude urcene vyhradne jen pro Linux ci jiny OS, muze to byt UEFI nakonfigurovano jinak.

[pc2005]

Je jen na vyrobci, jake moduly tam integruje

To by ale být nemělo.

pripadne na pozadavcich vyroce OS, pro ktere je zarizeni designovane.

A tohle už vůbec ne. Měl jsem za to, že PC je univerzální turingův stroj.

Nejlepší řešení, co mě napadlo by bylo to, kdyby výrobce udělal kotel modulů a uživatel si je tam naintegroval sám. Tedy by si je nemusel programovat sám (ale mohl, pokud by modul od výrobce byl nekvalitní) a zase pokud by se tím nechtěl zabývat, tak by to aspoň nějak fungovalo.

Pokud zarizeni bude urcene vyhradne jen pro Linux ci jiny OS

Špatná definice počítače. Dokonce i u smartphonů IMHO.

[xkucf03]

Nejlepší řešení, co mě napadlo by bylo to, kdyby výrobce udělal kotel modulů a uživatel si je tam naintegroval sám.

Je ale otázka, proč se zabývat nějakými moduly na úrovni firmwaru, když máme moduly na úrovni zavaděče (např. Grub 2).

Podle mého by firmware měl řešit jen inicializaci HW – a ta je specifická pro danou desku, takže ani není potřeba modularita. Dále je potřeba už jen vybrat disk, ze kterého se nabootuje – a zbytek už obstará zavaděč. Nicméně pokud to bude plně otevřené (coreboot), ať je klidně ten Grub nahraný na ROM čipu, nebo ať firmware rovnou natahuje jádro z disku a rozumí souborovým systémům. Ale dokud bude BIOS/UEFI proprietární blob, chci, aby toho dělal co nejméně.

[little.owl]

, když máme moduly na úrovni zavaděče (např. Grub 2).

Grub2 boot je jen blbe napsany balvan na ceste k plnemu UEFI bootu. Kernel od verze 3.6 lze naloadovat jako efi binarku, od verze 3.7 umi nacist i konfigurak z ESP partition, zadny Grub2 jako zavadec pak neni vubec potreba.

[xkucf03]

1. Grub 2 je uložen na disku, takže ho můžu přendat do jiného počítače a mít všechno svoje nastavení.
2. Jádro můžu rovnou nabootovat i corebootem – taky k tomu nepotřebuji žádný zavaděč na disku.

Můžeš mi tedy vysvětlit, proč bych měl používat nějaký proprietární blob, do kterého není vidět, místo otevřené technologie? Zatím jediný důvod, o kterém vím, je, že výrobce desek/čipsetů utajuje specifikace a otevřený firmware tak neexistuje pro všechny desky.

[xkucf03]

P.S. tzn. je to důvod, proč člověk nakonec ten proprietární BIOS/UEFI použije – protože musí – nikoli důvod, proč by ho chtěl použít.

[little.owl]

Grub 2 je uložen na disku, takže ho můžu přendat do jiného počítače a mít všechno svoje nastavení.

To muzete i s UEFI, navic jak casto to delate?

Jádro můžu rovnou nabootovat i corebootem – taky k tomu nepotřebuji žádný zavaděč na disku.

A ze tech zarizeni s coreboot funguje!

Můžeš mi tedy vysvětlit, proč bych měl používat nějaký proprietární blob,

Protoze funguje a protoze vase PC je takovych blobu plne od wifi po firmware v disku.

Jaky ma smysl retezec UEFI->GRUB->KERNEL, kdyz muzete pouzit UEFI->KERNEL?

Napriklad, UEFI nastavi grafiku, Grub nastavi grafiku a pak kernel nastavi grafiku.

Pokud to grub neumi poradne, jako ze neumi, jste v haji. To se ted deje, Grub2 a kernel si od verze 3.5.x nerozumi na nekterych zarizeni a vysledkem je black screen. Lidi z kernelu na to prdi, protoze UEFI->KERNEL je cesta, ne ten hnus Grub2.

[pc2005]

A ze tech zarizeni s coreboot funguje!

A, že se to zlepší s příchodem binárního UEFI blobu .

Protoze funguje a protoze vase PC je takovych blobu plne od wifi po firmware v disku.

V tom případě ať UEFI neleze na ARM, nebo pokud již bereš PC jako libovolný turingový stroj, tak ne všichni výrobci dělaj bloby.

Napriklad, UEFI nastavi grafiku, Grub nastavi grafiku a pak kernel nastavi grafiku.

Například: když bude v UEFI ovladači chybka tak tam zůstane dokud se výrobce desky neuráčí chybu opravit novým rom image.

Kernel tu grafiku bude muset nastavovat stejně, leda že by se celý třeba KMS přesunulo do UEFI a kernel komandoval UEFI přes něco jako int 0x10 .

Pokud to grub neumi poradne, jako ze neumi, jste v haji. To se ted deje, Grub2 a kernel si od verze 3.5.x nerozumi na nekterych zarizeni a vysledkem je black screen. Lidi z kernelu na to prdi, protoze UEFI->KERNEL je cesta, ne ten hnus Grub2.

A teď jak moc v háji budeme, když ta samá chyba bude ve špatně updatovatelném švábu na desce? (šance, že si budou BFU jako nic hrát s JTAG/SPI/LPC programátorem není moc vysoká :-/)

[xkucf03]

To muzete i s UEFI, navic jak casto to delate?

S živými CD nebo bootovatelnými flashkami velice často. A chci tam mít svoji nabídku, položky ve správném pořadí, svůj obrázek na pozadí, doplňkové informace… a chci, aby to vypadalo na všech počítačích stejně – až např. budu pro někoho dělat návod nebo ho navigovat po telefonu.

S běžnými disky méně často, ale když už se to stane, tak je to dost možná krizová situace, kdy člověk nemá moc času ani klidu na to, aby řešil, jak zrovna pracuje UEFI na té které desce a jak se tam vybírá OS, jak se mu nastavují parametry (pokud to vůbec jde)… V takovou chvíli budu vděčný za to, že BIOS jen natáhne Grub a pak už to bude vypadat stejně jako v tom původním počítači.

A ze tech zarizeni s coreboot funguje!

A to má být nějaká principiální výhoda UEFI?

Schválně: co ti v corebootu oproti UEFI chybí? (bez ohledu na počet podporovaných desek)

Protoze funguje

To je právě otázka. Vzhledem k tomu, že od něj nemám zdrojáky, tak nemůžu vědět, jak dobře funguje a jestli nedělá něco, co nemá. A když mi někdo chce omezovat množinu OS, které můžu bootovat, a ještě říká, že je to pro moji bezpečnost… tak v takovou technologii nemám důvěru. (ano, vím, že teď házím SecureBoot a UEFI do jednoho pytle, ale ono to spolu souvisí a jako spotřebitel to nemůžu moc oddělit – zvlášť když výrobci začnou dodávat desky podporující pouze MS a jeho certifikáty).

Tak se nemůžeš divit, že chci tenhle svět (UEFI/SB) co nejdříve opustit a dělat si to po svém (coreboot). UEFI/SB je prostě další zpackaná technologie – přitom kdyby to od začátku bylo otevřené a svobodné a nechávalo to kontrolu nad počítačem v rukou uživatele, mohla to být dobrá věc.

a protoze vase PC je takovych blobu plne od wifi po firmware v disku.

Periferní komponenty a jejich firmware, připojené přes určité definované rozhraní, to je něco jiného, než kód, který běží přímo na procesoru a který se stará o zavedení OS/zavaděče. U těch periferií se dá jednak uzavřený firmware tolerovat (byť to není ideální) a jednak si můžu vybrat otevřené.

Jaky ma smysl retezec UEFI->GRUB->KERNEL, kdyz muzete pouzit UEFI->KERNEL?

Když to vezmu z pohledu času: mám tu teď jednu novou desku – čas strávený v Grubu je okem nepostřehnutelný (když je vypnutá nabídka) a čas mezi Grubem a přihlašovací obrazovkou případně desktopem GNU/Linuxu je pár vteřin. Několikrát víc času ale zabere černá obrazovka po zapnutí počítače a UEFI. Takže pokud bych mohl ten řetězec nějak zkrátit, škrtnul bych UEFI a dal místo něj něco svižnějšího.

Napriklad, UEFI nastavi grafiku, Grub nastavi grafiku a pak kernel nastavi grafiku.

To nejsou žádné neopravitelné chyby. V principu mi tam ten Grub nevadí a spíš ho tam vítám.

[little.owl]

To nejsou žádné neopravitelné chyby.

Tak uz aby konecne zacli. VESA mody uz nemuseji byt podporovane, to znamena pro grub integrovat podporu pro kdejaky kus HW, fakticky presunout tam cast funkcionality kernelu. Proc? Ono je to fuk, stejne na to nemaji vyvojare a stavajicim tempem by byly tak dva roky pozadu za HW. Ale znovu, proc kdyz UEFI bude moci natahnout kernel - a verifikovat i jeho podpis - to delat?

[pavlix]

Já neříkám, že to nedává logiku. Dokonce neříkám, že to tak nakonec nebude. Ale nadávat kvůli tomu na GRUB mi přijde tak strašně mimo, že ani neumím vyjádřit jak.

A že VESA nebude podporovaná? Open source svět si vždycky nejlépe rozuměl s otevřenými standardy. Přizpůsobovat se proprietárnímu světu je něco, co já osobně považuju za nutné zlo a open source pragmatismus.

Ale pokud bych měl na výběr, tak bych na 100% dal přednost hardware, který odpovídá nějakému dobře implementovatelnému a tím pádem obvykle i implementovanému standardu.

To že se v hardwarovém světě od všeobecných standardů (někdy) upouští (jindy zase ne), není něco, co bych byl ochotný oslavovat. A ani UEFI nevnímám ani jednoznačný odklod od standardů nebo jednoznačný příklon k nim. Pro mě je to šedá technologie, která má spoustu výhod a spoustu nevýhod. Rozhodně to nevidím ani tak jako vhodný předmět uctívání, jako opatrnosti.

[little.owl]

To že se v hardwarovém světě od všeobecných standardů (někdy) upouští (jindy zase ne), není něco, co bych byl ochotný oslavovat.

Starsi standardy prestavaji byt podporovany a vznikaji nove, to je zivot.

[xkucf03]

Tak uz aby konecne zacli. VESA mody uz nemuseji byt podporovane, to znamena pro grub integrovat podporu pro kdejaky kus HW

A UEFI/BIOS tu podporu libovolné grafické karty vezme kde?

U Grubu vidím, výhodu v tom, že si do něj tu podporu můžu (nechat) doprogramovat a dá se to lépe aktualizovat, je do toho lépe vidět a když si něco rozbiji, připojím disk k jinému počítači a opravím to. Jak ale ty změny dostanu do proprietárního blobu?

Ale znovu, proc kdyz UEFI bude moci natahnout kernel - a verifikovat i jeho podpis - to delat?

Viz #121 (první dva odstavce). Ale jak už jsem psal – pokud to bude otevřená technologie, nemám problém, když bude výběr jádra/OS případně další věci probíhat už na úrovni firmwaru.

…a verifikovat i jeho podpis…

Což je spíš škodlivá vlastnost, než výhoda – alespoň do doby, kdy tu bude taková atmosféra, jaká tu je, a kdy bude hrozit, že Microsoft skrze tuto technologii bude omezovat konkurenci a škodit.

[little.owl]

A UEFI/BIOS tu podporu libovolné grafické karty vezme kde?

Podpora libovolne karty neni vyzadovana a staci podpora jen te, co je naintegrovana a to jeste ne v textovem modu.

[xkucf03]

jen te, co je naintegrovana

Jak integrovaná? Na mojí desce žádná není – dal jsem tam nějakou, co jsem měl v šuplíku.

a to jeste ne v textovem modu.

Jak textovém? Ten UEFI moloch, co tam je, má plno barviček a grafických efektů a ovládá se myší.

BTW: nejjednodušší je nasměrovat vstup/výstup na sériový port a k němu si připojit libovolný terminál (jiný počítač, chytřejší mobil atd.), tohle Grub umí. Ve světě proprietárních blobů to bude nejspíš strašně „enterprise“ vlastnost vybraných serverových desek, možná ještě za příplatek.

[pavlix]

BTW: nejjednodušší je nasměrovat vstup/výstup na sériový port a k němu si připojit libovolný terminál (jiný počítač, chytřejší mobil atd.), tohle Grub umí. Ve světě proprietárních blobů to bude nejspíš strašně „enterprise“ vlastnost vybraných serverových desek, možná ještě za příplatek.

+1

Sám už dlouho uvažuju nad pořízením nějakých IP-serial převodníků, abych mohl některé věci při síťové chybě ovládat po seriáku. I když faktem je, že jedna z věcí, za co jsem placený je právě odstraňování problémů se sítí, které jsou linuxovým distribucím tak nějak vlastní.

Jenže i experimentování samotné není bez rizika, že si experimentovaný stroj odpojím, takže bych rád měl něco jako síť nesíť. Ten seriák zpřístupněný po internetu se mi zdá jako ideální možnost.

[little.owl]

Jak integrovaná?

Vetsinu prodanych zarizeni tvori laptopy a tablety, kde kartu nemenite. Vetsina desktopovych PC se provozuje s integrovanou kartou, i kdyz tam asi VESA bude podporovana.

Jak textovém? Ten UEFI moloch, co tam je, má plno barviček a grafických efektů a ovládá se myší.

Ne, jde o to, ze to jak bude vypadat GUI a zdali tam vubec bude, neni dane, muze byt textove, muze byt graficke, muze to byt zalozene na VESA a nebo take ne, a u ARMu nemusi byt vubec. Navic u prechodu UEFI->KERNEL nemusi byt graficky vystup inicializovan - neni to nutne - pokud nechcete jit do UEFI menu.

[pc2005]

VESA mody uz nemuseji byt podporovane

Podpora libovolne karty neni vyzadovana ... to jeste ne v textovem modu

Neříkám, že VESA je moderní a dobrá, ale měl bys ses ohlédnout na bordel grafických rozlišení v preVESA světě .

[little.owl]

v preVESA světě

Tak ja jsem mel EGA i zeleny Hercules, tak horke to nebylo.

[pc2005]

No já nevím, mě ta tabulka u nestandardních videomódech dost odpuzuje. Navíc dneska může být co karta to jiný port a registrový interface.

[little.owl]

Tady mate nove UEFI inteface ASUS .. zde ci zde .. ma ho kolega na novem boardu.

[pc2005]

No ty ukazatelé (ovladače) napětí apdo. jsou relativně hezký a bootovací priorita je docela pekelná, ale ty další volby na druhém obrázku se od UI textovýho BIOSu (třeba z roku 2000) prakticky nelišej (včetně máloříkající nápovědy).

S GUI oproti TUI nebo ještě lépe CLI je problém v tom, že CLI ve stejném čipu může integrovat mnohem víc věcí než grafické obrázky GUI. Vykreslování grafiky pak trvá mnohem dýl než vytisknutí informativního řádku.

[little.owl]

Rychlost vas tady urcite nepali.

jsou relativně hezký

Mne se to vubec nelibi ... jak omalovanka .... a urcite jsou horsi.

[pc2005]

No já nevím, grafika přes framebuffer (hmm co takhle opengl 3D bios ) je dost pomalá a AMI i Award (co jsou zaangažovaní v UEFI) BIOSy mely často pomalou i to TUI.

Jako grafický to je někde zbytečně moc, ale nastavování boot priority na mé MB (2006) je dost opruz. Ovšem u i grafiky se to dá udělat tak, aby to byl opruz, to je fakt .

Jinak pokud se ti nelíbí omalovánka, proč se tak raduješ, že UEFI je budoucnost. Je prakticky jistota, že to bude grafičtější a grafičtější. Je na to řešení grafických okýnek aspoň nějakej standard taky? (aby tu po čase nebylo několik "window serverů" pro UEFI, navzájem nekompatibilních).

[little.owl]

proč se tak raduješ, že UEFI je budoucnost.

Ja ocenuji par technickych aspektu, jsou tam plusy i minusy.

Je prakticky jistota, že to bude grafičtější a grafičtější.

Ano. Nechci videt, co z toho vyrobci udelaji.

Je na to řešení grafických okýnek aspoň nějakej standard taky?

Ne, mohou si delat co chteji. I treba 3D UEFI s integrovanou strileckou.

[David Jaša]

Jaky ma smysl retezec UEFI->GRUB->KERNEL, kdyz muzete pouzit UEFI->KERNEL?

Jaký smysl má řetězec UEFI->GRUB->KERNEL, když můžete použít UEFI->SHIM->GRUB->KERNEL?

[pavlix]

+1

[little.owl]

Porad lepsi UEFI->SHIM->KERNEL nez UEFI->SHIM->GRUB->KERNEL !

Shim se alespon nesnazi o peachoviny jako grub.

[pavlix]

Shim se alespon nesnazi o peachoviny jako grub.

Mno je vidět, že jste si s panem Grubem udělali něco opravdu nepěkného.

[pavlix]

Grub2 boot je jen blbe napsany balvan na ceste k plnemu UEFI bootu.

Hezké, ale s argumentací nemá toto vyjádření nic společného.

[pc2005]

ceste k plnemu UEFI bootu

Co je to plný UEFI boot?

[pc2005]

Nicméně pokud to bude plně otevřené (coreboot), ať je klidně ten Grub nahraný na ROM čipu

Jo taky nechápu. Vždyť by mohli dát na desku druhej čip (větší), kde bude nějakej flash filesystém. V tom druhým (kterej by pak mohl být readonly) by byl minimální hloupý firmware, který by řešil věci jako nastavení obnovování RAM a topologie modulů a na filesystému by si pak každý mohl udělat vlastní API pro zbytek systému a asi by ani nepotřeboval datasheety k lowlevel registrům čipsetu (pokud by měl ten primární firmware rozumný interface; a ne že bych je pak přestal vyžadovat ). Teoreticky by to šlo i do jednoho čipu, ale tam je právě to riziko nechtěnýho přepsání.

UEFI se podle mě prostě snaží integrovat moc různěúrovňové funkcionality na špatném místě.

[pavlix]

UEFI se podle mě prostě snaží integrovat moc různěúrovňové funkcionality na špatném místě.

+1

[little.owl]

Posledni prispevek, uz na to nemam cas, cely den se tu snazim pracovat a vy me stale rozptylujete!

Pokud chcete pouzivat PC jako generecke zarizeni sdilene vice OS, museji byt veci jako je bootloader a sdileni disku agnosticke vuci pouzitemu OS a museji byt vetsinou OS podporovany.

UEFI boot a GPT jsou takovym resenim, ktere nema problem ani s Windows, ani s Linuxem, ani s MacOS a za nejakou dobu ani s FreeBSD. Na stranu druhou, LVM a Grub[2] je ciste Linux specificka vec, ktera nebude ve Windows nikdy rozumne podporovana.

Pokud jsem dnes chtel mit Linux a Windows na laptopu, musel jsem mit MSDOS Partition Table se vsemi limity a problemy, navzajem si OS prepisovaly MBR a kontrolovat to slo rozumne jen z jednoho OS.

Pro mne je i jen UEFI boot a GPT velky krok vpred, vedle dalsich veci v UEFI, a pokud mate jiny nazor, tak se proste neshodnem.

[pavlix]

Posledni prispevek, uz na to nemam cas, cely den se tu snazim pracovat a vy me stale rozptylujete!

To mě zrovna práce nejde od ruky, takže se nechám rozptylovat rád :D.

Pokud chcete pouzivat PC jako generecke zarizeni sdilene vice OS, museji byt veci jako je bootloader a sdileni disku agnosticke vuci pouzitemu OS a museji byt vetsinou OS podporovany.

Nevím jak ostatní, ale mně osobně takováhle možnost vůbec nezajímá. Na každém stroji používám pouze jeden hlavní OS a nemám absolutně žádný důvod k multibootu.

Multiboot jsem používal v dřevních dobách, kdy stroj nebyl schopný daný systém utáhnout ve virtualizaci a fakt jsem potřeboval střídat dva systémy. Dneska už pro mě neplatí ani jedno.

Pokud bych reálně potřeboval někde multiboot třeba kvůli testování na reálném hardware, tak se mi bude hodit na více než jednom stroji a pak to řeším přes PXE. Se syslinuxem, iPXE a podobnými nástroji je to hračka.

Pokud bych výjimečně používal jeden stroj na dualboot dvou zcela různých OS, což se mi nestává, tak některý z nich budu považovat za primární a budu hlavní bootloader klidně řešit v něm. Jistě, bootloader ve firmware je elegantnější, ale pro tak okrajový případ je mi to fakt šumák.

Pro mne je i jen UEFI boot a GPT velky krok vpred, vedle dalsich veci v UEFI, a pokud mate jiny nazor, tak se proste neshodnem.

Já v té neshodě žádný problém nevidím. Jen mi přijde divné tak okrajový případ použití a jeho tak okrajové řešení označovat jako něco zásadního, či dokonce snad nutného.

Tak trochu tuším, že nejsi zrovna lama. Takže poradit si se správou bootloaderu z linux pro tebe nemůže být problém. A když použiješ google, tak to zvládneš i naopak z windows. Kamarád to zvládl bez předchozích znalostí během dvou večerů jako totální linxová lama (proto chtěl ovládat bootloader z Windows, kterým víc rozuměl).

Vždyť takovéto problémy musejí být pod tvoji rozlišovací schopnost.

[little.owl]

Nevím jak ostatní, ale mně osobně takováhle možnost vůbec nezajímá.

Pokud takove stanovisko zaujme druhy tabor, maji uzivatele Linuxu problem.

Jen mi přijde divné tak okrajový případ použití a jeho tak okrajové řešení označovat jako něco zásadního, či dokonce snad nutného.

Ja hlavne doma nemam zadne Windows,ale vsadim botky, ze vetsina lidi i zde ma dualboot.

Takže poradit si se správou bootloaderu z linux pro tebe nemůže být problém.

Byl jsem schopen si opravit i LVM binarni edirorem a slo to, ale proc? Takhle mohu mit dva OS vedle sebe aniz by o sobe vedeli a nejak se navzajem ovlivnovali a nenarazim na limity partition table.

[xkucf03]

Pokud takove stanovisko zaujme druhy tabor, maji uzivatele Linuxu problem.

Jen ti, kteří potřebují střídavě bootovat do Windows a do GNU/Linuxu. Já s tím problém taky nemám – když už bych Windows potřeboval, dám je do virtuálu a z něj mi fyzický disk přepisovat nebudou.

Ale i když to budou UEFI binárky vedle sebe – kde bereš jistotu, že Windows nesmažou binárky ostatních OS nebo že nepřeflashují BIOS/UEFI tak, aby nešlo nabootovat nic jiného? Když můžou přepisovat MBR, můžou dělat i tohle – a to je daleko větší zlo (když nebudu mít zálohu BIOSu/UEFI a kde ho přeflashovat, tak jsem v háji – oproti tomu MBR si obnovím hravě).

Ja hlavne doma nemam zadne Windows,ale vsadim botky, ze vetsina lidi i zde ma dualboot.

To by chtělo nějakou statistiku… Ale spíš bych řekl, že ne – dnes už není důvod na fyzický HW Windows dávat – leda na hry. Ano, přiznám se, že na jednom (ještě k tomu půjčeném) notebooku jsem je nechal a občas si něco zahraji, ale jinak to smysl nedává – Windows patří leda do virtuálu.

[pc2005]

kde bereš jistotu, že Windows nesmažou binárky ostatních OS nebo že nepřeflashují BIOS/UEFI tak, aby nešlo nabootovat nic jiného?

Jedině, že by UEFI pouštěl OS jako hypervisor *brr_smajlík*

dnes už není důvod na fyzický HW Windows dávat – leda na hry

Možná už brzo ani na ty hry ne, viz Steam .

[pc2005]

agnosticke vuci pouzitemu OS

Třeba formátem binárky založeného na PE od microsoftu? (docela by mě zajímalo jak moc se Microsoft bránil, když někdo navrhoval jakej formát se má použít )

Pokud jsem dnes chtel mit Linux a Windows na laptopu, musel jsem mit MSDOS Partition Table se vsemi limity a problemy, navzajem si OS prepisovaly MBR a kontrolovat to slo rozumne jen z jednoho OS.

cat /dev/urandom > /dev/sda<windows_partition> ?

Linux Windowsům partition table nepřepisoval (pokud jsi to fakt nechtěl).

Pro mne je i jen UEFI boot a GPT velky krok vpred, vedle dalsich veci v UEFI

Krok od MBR do GPT by měl být pro mě OK (resp. teďka mě žádný fatální nevýhody GPT nenapadaj). Nicméně bylo by efektivnější použít to, co bylo dřív anebo po delší době koexistence vybrat kvalitnější design. Rozhodně je zbytečný patlat něco novýho a pak to pracně integrovat do všech OS, kdyby existovalo řešení, které by už bylo aspoň v určité množině OS.

Co se mě týče, tak aspoň podle wikipedie o GPT neflamuju, protože má stejně na začátku MBR . Kde navíc může být binárka pro zpracování GPT.

K UEFI pak výhrady mám viz celá diskuze.

[pc2005]

P.S.

Pokud chcete pouzivat PC jako generecke zarizeni sdilene vice OS, museji byt veci jako je bootloader a sdileni disku agnosticke vuci pouzitemu OS a museji byt vetsinou OS podporovany.

Ale kdo říká, že UEFI je to jediné pravé řešení (TM), co se musí nutit všem? .. A to i na platformu (ARM), kde je většina (a i v tom nejpesimističtějším odhadu ještě dlouho bude) OS něco jinýho než windows.

UEFI je jen jedno z mnoha řešení, pokud bych zachoval GPT a nějakej formát binárky, tak to můžu načíst čímkoliv (co je navíc používáno na více strojích než (U)EFI).

[little.owl]

Ale kdo říká, že UEFI je to jediné pravé řešení (TM), co se musí nutit všem?

Na tom se puvodne dohodly spolecne tyto firmy:

AMD American Megatrends Inc. Apple Inc. Dell Hewlett Packard IBM Insyde Intel Lenovo Microsoft Phoenix Technologies

Nelibi se ti to? Bojkotuj je!

[pc2005]

[naive] Takže to není z pozice nejlepšího řešení, ale z pozice síly? [/naive]

No myslím, že za další mooreovskou iteraci bych i mohl. Microsoft je jasnej, Intel mě štve svýma předraženýma CPU, AMI/AWARD/PT se dá odstranit corebootem/ubootem/redbootem apod., Apple , Dell/HP/IBM/Lenovo jsou jen výrobci kompů, Insyde vůbec neznám . Trochu mě vadí AMD, ale koneckonců to je stejně jen duopolní protipól Intelu. Horší kdyby tam byl původně třeba Samsung .

[Zopper]

No, některé systémy na výběr moc nedají... :D Nebo aspoň nevím jak donutit windows, aby mi nepřepsaly grub a musím pak prostě grub znova vrátit.

[Jendа]

Ale stejně tak můžou přece takové systémy během instalace „pročistit“ UEFI partition.

On dneska ještě někdo Windows používá jinak než ve virtualizaci? O_o

[xkucf03]

Proč by tohle měl řešit firmware? Já od něj očekávám nahrání nějakého sektoru z disku do paměti a skočení na začátek, nic dalšího mě nezajímá.

+1

Taky nemám zájem o přenášení logiky z OS/zavaděče (které mám celkem pod kontrolou) na nějaký čip na desce – alespoň ne do doby, kdy na tom čipu bude plně svobodný firmware a budu si s tím moci dělat, co chci. A i pak je to problematické – chci mít vše na disku, abych ho mohl v případě potřeby vyndat a dát do jiného počítače – proto chci, aby toho BIOS/UEFI dělal co nejméně.

[R]

Presne tak. Toto je velmi podobna chyba ako ked boli prve BIOSy, co mali vediet bootovat z CD-ROM. Fungovalo to iba s CD Windows NT 4.0. Robil to niekto podla konkretneho CD a nie podla specifikacie...

[little.owl]

Vyrobce nejaky standard ci specifikace nezajima, pro ne je dulezite ze to nabootuje Windows 7/8 ...

[smazáno]

A to je dost problem. Pak si zkus vysvetlovat prodejci, ze reklamujes notebook, protoze nepodporuje UEFI i kdyz deklaruje podporu ...

Jestli by vyrobce mel podporovat standardy a ne jen OS, ktery si vybere, je klasicky flamewar zejo . Ja si stejne myslim, ze urcita cechova hrdost _a respekt_ by vyvojare mela nutit, aby vydavali kvalitni kod a nejen "funguje to s windows, nic vic me nezajima", i kdyz pro to nejsou (na prvni pohled) ekonomicke duvody.

Stejne tak jako ja na konci projekt treba stravim tyden refactoringem, i kdyz to delam spis napric sefovi. Ale verim, ze az nekdo dostane projekt po pul roce po me, tak usetrim hrozne moc prace ...

[Jendа]

Jestli by vyrobce mel podporovat standardy a ne jen OS, ktery si vybere, je klasicky flamewar zejo .

Jednoznačné mi však přijde, že pokud podporuje pouze Windows, měl by napsat, že počítač funguje pouze s Windows.

[pc2005]

Jj na jedný 486 fungovala na AMI biosu cdromka jen pro w98 a ostatní linux live cd házely chybu. Po upgradu na poslední verzi (bios se změnil z AMI na award :-O) nabootovaly všechny (s vyjímkou i686 přirozeně ).

[Nereknu]

Jen pro zajimavost, o jaky skvost se jednalo, jestli si to pamatujes? :) jde mi predevsim o zmennu z AMI na award :)

[pc2005]

Přesné číslo nevím, ale byl to Axiomtek a FinALI čipset s ISA/PC104 only (myslím, že jsem to někde linkoval, průmyslové provedení, jediný PCI zařízení je integrovaný IDE řadič, který navíc není v lspci vidět ).

To AMI byla nějaká první verze, ale layout už byl docela povedený (prakticky stejný jako třeba na k7s5a), na netu jsem pak našel o několik desítek verzí (a pár let) novější award. V tý době bylo rozšíření tak 50:50 a čipsety jako finALI nebo sis478/9 (stále nemám datasheet ) byly deska od desky buď s AMI nebo s Award.

P.S. To že to byla nějaká první verze jsem poznal i podle toho, že měla pole pro 4 harddisky, ale vyvedený je jen jeden IDE header .

[R]

Aj na niektore bezne dosky (myslim, ze MSI) existovali dva BIOSy - AMI aj Award. Dalo sa to volne zamienat, len bolo nutne nezabudnut prepisat aj bootblock.

[pc2005]

Jj skoro jistě. Oba výrobci BIOSu ho maj dost modulární, dokonce se da editovat tabulka pro plnění registrů čipsetu.

[R]

Kedysi sa dali stiahnut aj nejake zdrojaky Award BIOSov, bol to pekny humus v assembleri...

[pc2005]

Já jsem někde našel i komentované zdrojáky BIOSu PC XT . Nebyly ale ty zdrojáky awardu jen dissasemblovaný a okomentovaný? Protože pokud je něco nečitelnej hnus, tak je to obvykle kvůli optimalizacím z kompilátoru. Když jsem rozebíral BIOS z LEO Designote, tak byl začátek docela dobře čitelnej (ještě se testovaly registry běžící jedničkou ) a jakmile to vlezlo do detekce paměti v PM, tak to bylo dost blé a třeba 10 vnořených funkcí (což by asi člověk v assembleru nedal).

[Ladislav Hagara]

Souhlasím, implementace UEFI by bylo přesnější.
Jako titulek zprávičky jsem použil název článku.

[ivan]

Nevim, jak je to u UEFI, ale v pripade BIOSu to bylo tak, ze Intel dodaval referencni implementaci BIOSu vsem kdo si koupi jejich chipset. Jednotlivi vendori si to pak jen poupravi. Pokud je v tom BIOSu chyba tak ji tam pak maji vsichni vendori a je jen na nich jestli si to fixnou anebo ne.

[little.owl]

Ano. Dokonce si tu referencni implementaci muzete stahnout. Chapu Garretta, ze odchazi z Red Hat, rok se denne rypat v tom kodu je na bednu.

[pavlix]

Nečekal jsem, že odejde, ale taky mi to dává smysl. Už jen proto, že jeho snahu mnozí tak úplně neocení.

[little.owl]

mnozí tak úplně neocení.

Ano, na UEFI v kernelu a shim-u udelal kus prace. Tohle je situace kdy Red Hat skutecne zachranili krk i ostatnim distribucim.

[pavlix]

Vždyť přesně o tom mluvím. Podle mě má na to mnoho lidí v RH značně odlišný názor.

[pc2005]

a shim-u udelal kus prace

zachranili krk i ostatnim distribucim

Takže UEFI je tu od toho, aby linuxovým (a jiným) distribucím znepříjemňoval život? Jsem myslel, že by měl jako Basic input output system (protože nic jiného ani není, když má jen inicializovat PC) libovolnému OS spíš sloužit.

P.S. BIOS má v tomhle ale taky máslo na hlavě, to je pravda .

[Jendа]

Takže UEFI je tu od toho, aby linuxovým (a jiným) distribucím znepříjemňoval život?

Ne, ale potřebuješ pro něj podporu.

[pc2005]

Což, ale může znamenat, že musíš napsat bootloader, který nabootuje jiný bootloader a pro ten první bootloader získat podpis, což už znepříjemnění je.

[little.owl]

Tim jsme ale zpet u toho, ze snazis nabootovat Linux na zarizeni designovane J-E-N pro Windows - cu hure - jen dodavane Windows ... mas to casto napsane na krabici. Pak proste cekejte komplikace.

[pc2005]

Já nemluvím o ARMu ale o shimu.

[Jendа]

a pro ten první bootloader získat podpis

Počkat, nepleteš si UEFI s nějakou jinou technologií?

[pc2005]

Secure boot je podmnožina UEFI ne? A když to budu mít v kompu, tak chci mít možnost využít všech vlastností.

[Jendа]

Secure boot je podmnožina UEFI ne?

AFAIK ne.

A když to budu mít v kompu, tak chci mít možnost využít všech vlastností.

Tak bereš zapnutí Secure Bootu jako využití vlastnosti (tj. plus) nebo otravu (a pro ten první bootloader získat podpis, což už znepříjemnění je)? Pokud to druhé, proč ho sakra zapínáš?

Btw. k čemu plánuješ SB využít? Mně se zdá, že každý máme v počítači tolik děr, že je SB jako nalepení fólie na okna, když jsou vedle otevřené dveře.

[pc2005]

AFAIK ne.

I když ta podmnožina může být někde prázdná? (pozor nepočítám TPM apod.)

No ono je to takové schizofrenní. Na x86 je to blíž plusu než na ARMu, kde to je mínus (čípak je to vina ). Secure bootu se dá ještě pochopit, pokud by byl apolitický (například, pokud budu moct smazat klíče na libovolné architektuře a přidat si kotel svých vlastních). Jakmile to je navázáno na jednu konkrétní firmu, tak se dají čekat problémy.

To, jestli je SB použitelný, resp. zda nějak pomůže je diskutabilní, ale pokud bude dobrovolně volitelný, tak proč ne.

Vzhledem ale k Bluebearovým problémům to ale vypadá, že implementace budou dosahovat kvality BIOSu () a tak je SB spíš přítěž a je v UEFI zbytečný.

P.S. Tedy abych to (hlavně pro sebe) shrnul, tak SB bych jako plus bral i přes potřebu podpisu jen pokud bych měl plnou kontrolu nad certifikací. Protože ale ARM, tak je SB jako mínus a pokud bude jako rozšíření UEFI, tak se nedá brát jako vylepšení oproti BIOSu (ale dokonce spíš zhoršení).

[smazáno]

+1

[Pali]

Keby len to. Na mojom HP EliteBooku UEFI firmware automaticky nabootuje iba jeden efi subor ESP:\EFI\Microsoft\BOOT\bootmgfw.efi Ine zavadzace je mozne nabootovat iba cez menu F9 a potom manualne vybrat EFI subor.

[Salamek]

lol to tam nekdo jako udelal:

if(os_name != "Windows Boot Manager" && os_name != "Red Hat Enterprise Linux")
{
 continue;
}
printf("%s\n", os_name);

Pri vypisovani nebo co ?

[little.owl]

To by bylo fajn ... stacilo by binarne prepsat Windows na "Fedora"

[Pali]

Keby to slo. Na novych notebookoch si smejdi uz podpisuju aj FW, ktory sa flashuje... Okrem ineho je tam sprosty whitelising ktory zabrani pripojit si inu ako povolenu wiki kartu ci pcie modem.

[Limoto]

Ten whitelisting už se dělá dlouhý léta, ale tam stačí ty IDs najít a přepsat je.

[Pali]

ak je to podpisane, tak to zial nezmenis.

[kralyk z abclinuxu]

To je teda docela svinstvo. To aby si pomalu člověk vlastní počítač crackoval jak nějakej PlayStation nebo něco podobně totálně zamčenýho. Kam ten svět spěje...

[pepe_]

podporuj raspberry a tím i směr vývoje.

[Vskutečnosti Saýc]

Raspberry je lautr to same.

[pc2005]

No tam si aspoň můžeš ten klíč odkoupit.

[little.owl]

Koukal jsem na board laptopu a je tam jen 2M FLASH, kterou jde vyndat a preprogramovat, a mozna ze by sla prepsat i bez vytahovani. Jeste mit vhodny CoreBoot.

[pc2005]

Vtipnější by bylo:

if (strcasestr(os_name,"fedora")) {
 fail;
}

[smazáno]

nice one

[bukk__e]

K tomu přece UEFI bylo zavedeno, aby povolilo jen Microsoft nebo RedHat. Kdo si myslel něco jiného musí být moc mladý nebo moc natvrdlý.

[ertwertwe]

takze jedine linuxbios.

[mankind_boost]

coreboot

[coder]

O co prichazim, kdyz pouzivam Legacy boot - emulaci biosu? (Muj setup je jeden MBR oddil s Archem, na ntbuku to staci).

[TM]

Nepřicházíte naprosto o nic.
Ale nejste pak správný mlamoj, který znalecky poučuje, že "BIOS je neudržitelný".

[pavlix]

Tak to mě hodně pobavilo. Naprosto souhlasím. Tihle „znalci“ mi jsou nesmírně protivní.

[TM]

U každé podobné blbosti, která primárně vznikla za účelem vykázání činnosti a udržování zdání neustálého pokroku (případně za účelem buzerace, šmírování a omezování), se najde vždy dostatek takových lidí.
Je pozoruhodné, že mlamoje zpravidla nenajdete u skutečně užitečných inovací - např. jsem nezaznamenal moc velký počet podobných "znalců", hájících opravdu užitečnou tabulku GPT. A co si například pamatuju, i nástup opravdu pokrokové inovace - LCD monitorů nebyl jimi kdysi příliš povšimnut. Zato i dost nebezpečné hovadiny jako veřejné cloudy "zdarma", ty je přitahují silou přímo magickou.

[pavlix]

opravdu užitečnou tabulku GPT

Co do funkcionality je podle mě GPT krokem zpět.

[JoHnY2]

Musim se GPT zastat. Nevim jak ostatni, ale mam rad predstavu, ze muzu na 3TB disk dat mnoho pártyšen (super slovo co ) a prectu je na vetsine OS .... Na druhou stranu se mi nechtelo u novyho 3TB disku pro storage resit veci jako je offset na 4KB sektory a proto jsem brtfs hodil primo na zarizeni bez toho abych na nem udelal MBR nebo GPT.

[pavlix]

Musim se GPT zastat. Nevim jak ostatni, ale mam rad predstavu, ze muzu na 3TB disk dat mnoho pártyšen (super slovo co ) a prectu je na vetsine OS ....

To nerozporuju.

[Sten]

Zatím o nic. Otázka ale je, jak dlouho legacy boot budete moct používat, protože třeba se Secure Boot nefunguje.

[coder]

? budu jej pouzivat dokud budu pouzivat soucasny lenovo notebook. Cca max 2 roky. Nejsem hnup, abych aktualizoval soucasne UEFI, ktere mam legacy boot na pripadne novou "lepsi" verzi Za rok, dva snad bude situace lepsi