Názory k článku Je čas opustit BIOS a přejít na UEFI? Vývojáři Fedory o tom diskutují
-
BobTheBuilderStříbrný podporovatelNa to se nás ale nikdo neptá.
Intel už nějakou dobu (a inzerovali to dost dávno) nedělá legacy drivery grafiky pro BIOS, takže když máte integrovanou grafiku, nemáte na vybranou. -
U mna na doskach kde sa da prepnut medzi UEFI a BIOSOM bootuje kernel vzdy skor pri BIOSe. Netvrdim ze je to chyba UEFI je to asi konkretnou implementaciou - je mozne ze UEFI inicializuje niektore pre boot nepotrebne periferie navyse.
Takisto v KVM mi ubuntu bootuje ovela rychlejsie v SeaBIOS ako v Tianocore UEFI.
-
> ale stačí FAT16 který má o dost menší minimální velikost oddílu.
32MB, nebo 256MB. To mi neprijde nijak hrozne pri velikosti dnesnich disku.
I kdyz smysl to dava. Ja mam na notebooku s Linuxem na EFI oddilu zabrano 7,4MB.> For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 = 256 MB.
>
> Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 = 32 MB, which is less than the 100 MB minimum size for this partition.
>
> -- https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11 -
Pavel TišnovskýZlatý podporovatelNení minimální velikost FAT16 něco málo přes 4 MB? 4,1 MB nebo tak?
-
Jenže ten Grub musí někde ležet a kvůli mnoha historickým omezením je jeho start velmi komplikovaný. První úroveň leží v master boot sektoru, ale tam je málo místa. Pak je potřeba mít někde uloženou další úroveň, což se obvykle dělá do „prostoru nikoho“ mezi MBR a první oddíl, pak se teprve musí z disku načíst třetí část v podobě klasického souboru. Je tam spousta hacků, statických odkazů kvůli selhání načtení střední fáze a podobně.
Proti tomu v UEFI je Grub uložen slušně v jednom souborů na standardním oddíle. Ten se načte a spustí. Mně tedy přijde výrazně logičtější a elegantnější to, jak to dělá UEFI.
-
DannyStříbrný podporovatelAle ten problem prece je davno vcelku obstojne vyreseny. Grub2 proste funguje bez ohledu na to, jak stroj bootujes. A bez ohledu na to, ze sam pouzivam UEFI vsude kde muzu mi tenhle pristup vyvojaru Fedory prijde tak trosku zvraceny - aneb zase se omezi hardware, na ktery to muzes nainstalovat.
A ta prekazka je umele vytvorena. Naprosto zbytecne, kdyz beztak jako preferovany zavadec distribuce mas Grub2, co umi oboji. Takovej ten pristup ala Microsoft... ti taky hazej umele klacky pod nohy a padaji stejne argumenty :-)
Ono si to pak vyzereme zpet dost rychle - lidi proste zustanou na zastaralym SW, protoze kvuli vrtochum vyvojaru se jim novy HW porizovat chtit nebude (ala me ty XPcka stacej... zname z praxe). Ze to je problem danyho cloveka? Ne, neni - jeho deravej komp je pak zdrojem utoku i na moji infrastrukturu.
-
DannyStříbrný podporovatel
No, ale novou instalaci muze chtit clovek ucinit i na starsim HW, zeano. Aneb kdyz odejde disk, tak ho proste vymenim - nemusim kvuli tomu kupovat celou novou sestavu. Jiste, tak si nainstaluje starsi verzi a pak upgradne... ale jaky ma smysl dava takto hazet zcela zbytecne klacky pod nohy?
Argument "zdroj zbytecnych problemu" jde aplikovat na libovolnou situaci. Prave ze i samotne UEFI umi umi byt zdrojem problemu. Svet neni tak slunickovy, software obsahuje hromady chyb... a zdanlive jednotny standard ma hromady implementaci, co se lisi v detailech - ktere kdyz dojde na lamani chleba umi pekne zatopit.
-
GRUB asi tak snadno UEFI nahrazen nebude. Možná v případě, kdy startuje ten "jediný správný systém" (například na serveru), ale už jen obyčejný dual-boot (Win/Lin) je obvykle poněkud nepohodlný - o možnostech spouštět systém s různými parametry nemluvě.
(Tedy: ne, že by to bylo s GRUBem nějak extra jednoduché, pokud dojde na změny v konfiguraci, ale s běžnými UEFI je to poněkudvelmi nepřátelské
k jakýmkoliv úpravám.) -
No práveže klasický dualboot je pohodlnejší cez UEFI, ako cez GRUB. UEFI má zabudovaný boot manager, kde si používateľ môže vybrať operačný systém a ten potom bootuje pomocou svojho natívneho boot loadera, bez prípadného porušenia reťaze podpisov secure bootu. V prípade Grubu by tam bol strčený ešte aj Grub, len na to, aby urobil chainload.
Rovnako pomocou UEFI sa konečne podarilo dosiahnuť, že operačné systémy vedia vedľa seba koexistovať a neprepisujú si navzájom boot sektor. A pretože vedľa seba vedia koexistovať, boot manager o nich vie a umožňuje používateľovi vybrať si, ktorý chce nabootovať.
Uznávam, že zmeniť parametre existujúcej položky už jednoduché nie je (aj keď to sa dá tiež, cez shell).
-
Však já s Vámi v podstatě souhlasím.
Dual-boot přímo z UEFI bez GRUBu (či jiného bootmanageru) mi přijde jako dobré řešení tam, kde si vystačíte s instantními volbami: boot z několika disků, několika partition, dočasných médií (flashdisk...), atd. Běda však, pokud potřebujete (či chcete) nějakou fajnovost, třeba jen mít kontrolu nad pořadím voleb (i můj předškolní syn umí vybrat "první Linux" nebo "poslední Windows").
Bootmanager (GRUB....) má smysl tam, kde člověk potřebuje mít věci víc pod kontrolou - a shell z UEFI opravdu není pro každodenní používání. (Snad kromě případů, kdy se chce člověk vytahovat před ostatními geeky, co všechno umí - což považuji za exhibicionisticko-masochistickou úchylku.) ;o)7. 4. 2022, 23:13 editováno autorem komentáře
-
Ono ani to poradie nie je problém: je na to premenná (BootOrder) a dá sa nastaviť aj z bežiaceho systému pomocou efibootmgr (to je ďalšia pekná vec UEFI: dá sa meniť nastavenie aj z OS, vrátane cieľa budúceho rebootu, a dá sa rebootnuť aj priamo do setupu: systemctl reboot --firmware-setup).
Pri grube mi vadí to, že nie je celkom pod kontrolou ako by mal byť - on síce má svoj pôvodne jednoduchý config, ale nejde editovať, pretože distribúcie ho generujú a prepisujú, pričom zdroj toho generovaného configu je porozhadzovaný všelikde, v každej distribúcií inak, že ani srnka netuší, čo sa tam nakoniec dostane a kde treba požadovanú vec nastaviť. Na Silverblue som doteraz nezistil, kedy a ako sa generuje (tam to má na starosti ostree).
No a na normálnej fedore ma aktuálne irituje taká blbosť, že grub je síce nastavený, aby bol ticho, ale chybovú hlášku s ktorou nikto nikdy nič nespraví (/boot je v btrfs a grub tam nevie zapisovať, čo samozrejme z tej hlášky nie je zrejmé) na obrazovku vypísať musí.
-
> Na Silverblue som doteraz nezistil, kedy a ako sa generuje (tam to má na starosti ostree).
Tohle nefunguje?
https://ask.fedoraproject.org/t/change-grub-configuration-and-apply-in-silverblue/15436
-
Nie, už aj preto, že neodpovedá na otázku: kedy a ako sa generuje.
Môj problém je, že generuje nesprávnu cestu k jadru a initramfs (dôvod: generátor kašle na subvolume, bug ostree#2017), takže tam mi /etc/default/grub nepomôže. A kedže cesta obsahuje plné id k sysrootu (to je silverblue-specific, readonly checkout rootu), tak sa zmení po každom jednom update. Akurát nie hneď po prebehnutí samotného update - to je tam starý config (oba: aj grub.cfg, aj BLS). Ale keď urobím reboot, už tam je nový config (znova oba: grub.cfg aj BLS), ktorý je samozrejme nesprávny, systém nenabootuje, ručne zeditujem cestu v grube, systém nabootuje, a až potom môžem zmeniť grub config.
No a preto potrebujem zistiť, kedy a ako sa generuje grub config, pretože aktuálne je to niečo opaque na pozadí, skryté pred používateľom.
-
Jan HrachStříbrný podporovatel> UEFI má zabudovaný boot manager, kde si používateľ môže vybrať operačný systém
UEFI boot manager je na každém počítači jiný, někdy nepohodlný (musí se ve správný okamžik zmáčknout nějaká F klávesa, ještě k tomu také na různých počítačích jiná, místo GRUBu s timeoutem), a neumí to třeba takovou tu věc že když se boot nepodaří, tak GRUB automaticky při dalším pokusu zvolí jinou položku.
-
Jan HrachStříbrný podporovatel
Používá se k tomu mechanismus grub-reboot - set the default boot entry for GRUB, for the next boot only, který spustíš po každém úspěšném bootu.
Ale nikdy jsem to, přiznám se, nenastavoval a neprovozoval.
-
A ta prekazka je umele vytvorena. Naprosto zbytecne, kdyz beztak jako preferovany zavadec distribuce mas Grub2, co umi oboji. Takovej ten pristup ala Microsoft... ti taky hazej umele klacky pod nohy a padaji stejne argumenty :-)
Vám to přijde uměle vytvořené a zvrácené, já to vidím z druhé strany. Bootloader tým je jeden z nejpřepracovanějších týmů v Red Hatu. Jedno velké hašení požárů. A není to tak, že by jen tak mávnutím kouzelného proutku mohli najmout další lidi. Těch, kteří rozumí zavaděčům na úrovni, kterou potřebují, opravdu po světě mnoho neběhá. Já se jim nedivím, že chtějí zmenšit počet use casů a množství kódu, o který se musí starat. Nedělal bych v jejich situaci nic jiného.
-
Jan HrachStříbrný podporovatel
Zajímavé, můžete nastínit co se třeba řeší? Já musím zaklepat, ale jako k adminovi ke mně ještě žádný bug nikdy neprobublal (až na jeden bios co odmítal vidět disk když tam byla partition table ve které nebyl žádný oddíl označený jako bootovací -- grubu je to jedno, ale tady to nebootovalo), ale tu práci baličů přímo nevidím (pozn. používám Debian).
-
Asi stačí zamířit do Red Hat BZ a mrknout se, co je všechno nahlášené pod balíčky jako GRUB2, shim atd. Dost toho ale asi nebude úplně veřejného (různé problémy na předprodukčním hardwaru od partnerů). Ono samo o sobě stačí CVE, kterých taky neřeší málo. Navíc je to kritický kus softwaru. Když něco pokazíte, tak nemusí nabootovat stovky tisíc serverů po světě (už se stalo, i když v menším rozsahu). Na jednu stranu je člověk tlačený časem (opravy kritických CVE musí být vydané do 5 pracovních dní) a na druhou stranu nesmí udělat chybu. Jestli bych nechtěl něco v distribuci maintainovat, tak jsou to bootloader balíčky. :)
-
Akurát že niekoľko rokov sa dodávajú už len počítače s Class 3 UEFI, najvyšší čas zvyknúť si, že na ďalšom to nebude možné.
Čo je to Class 3: https://uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf
-
Velkou část ale budou tvořit uživatelé s modernějším hardwarem, kteří mají jen nedopatřením přepnutou základní desku do režimu podpory BIOSu (legacy). Pro takové uživatele je snadné problém napravit a podporu UEFI jednoduše zapnout.
Asi si ve svém obrazoboreckém nadšení neuvědomují, že řada uživatelů to tak nemá přepnuté nedopatřením, ale záměrně, takže možnost UEFI jednoduše zapnout je moc neláká.
-
Ja mam myslim UEFI s podporu legacy boot .. proc? no proze vubec neni pravda, ze nejaky disk ktery ma jen GRUB a /boot nebo jeste lepe jen "/" part. nebot omezeni grubu2 na velikost disku ze ktereho umi bootovat/blok ze ktereho natahne kernel uz neni v UEFI modu nabootuje a ze staci jen prepnout BIOS na UEFI ... ne je treba kompletne prekopat cely boot, partitions, dat tam tu UEFI part. pokud se nemylim.
A urcite to neni pro vsechny trivialni zalezitost .
Takze prepnutim do rezimu UEFI dostanete nenabootovatelny OS ;-))
Nove instalace jsou jasne, tam je to jedno, tam si to vyrobi sami, nebot to clovek vytvori rucne
-
Takze prepnutim do rezimu UEFI dostanete nenabootovatelny OS ;-))
No tak to je snad jasný, že když v autě vyměním (jen) benzínový motor za elektrický, že to nenastartuje, že bude potřeba těch úprav trochu více...Nikdo nečeká, že se v BIOSU přepne na UEFI only a pokračuje se dál. Je samozřejmé, že systémy nainstalované v Legacy módu na disk nemající GPT nepojedou a bude potřeba začít zformátováním celého disku na GPT tabulku, vytvoření UEFI oddílu atd. Proto se taky mluví o tom mezistupni, kdy systém nepůjde nově nainstalovat jinak, než v UEFI, ale aktualizovat půjde...
Osobně si myslím, že je dobrý nápad odstranit z jádra podporu dnes už notně zastaralé technologie a zaměřit se jen na aktuální mj. aby byly síly místo oprav té historické raději doimplementovat a opravit tu novou...
-
@jinejmuf
"bude potřeba začít zformátováním celého disku na GPT tabulku, vytvoření UEFI oddílu"z MBR na GPT NEni potreba "formatovat", staci tu tabulku prevest, tedy se zachovanim oddilu a dat na nich...
pridat EFI oddil (foramt fat32, priznaky esp a boot) lze snadno pokud je kousek mista volne, trochu mene snadno pokud neni ale disk je bez sifrovani/lvm/raid, komplikovaneji s tim...
lze to cele provest z nabehleho systemu (v Legacy rezimu s MBR na disku), po te uprave oddilu uz jen nainstalovat grub efi:
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi /dev/sda
a pak restartovat s prepnutim do UEFI rezimu v "BIOSu"...
-
no od vydania Fedora core 4 som prestal uplne sledovat Fedoru.
pre mna nepouzitelne ked mam robit testera pre RH. Tak dufam ze Debian sa nebude opicit ako so systemdlen je skoda ze sa im podarilo kopec blbin pretlacit aj do Debianu.
Osobne pouzivam na novom pc UEFI ale ked mam moznost prepinam legacy.
-
Na druhú stanu v Debiane do toho kecá stašne moc ľudí, hlavne takí, čo majú veľa rečí ale moc toho na vývoji alebo údržbe nerobia. Preto sú tam stále problémy, ako napr. s /usr merge, ktoré ostatné distribúcie vyriešili 10 rokov nazad.
Vďaka takémuto prístupu je stav systémy zamrznutý v minulosti a nevie sa pohnúť z miesta vpred.
-
DannyStříbrný podporovatel
Ale ted kecate vy :-) https://wiki.debian.org/UsrMerge
In February 2021, the Technical Committee has resolved that Debian 'bookworm' should support only the merged-usr root filesystem layout, dropping support for the non-merged-usr layout. -
DannyStříbrný podporovatel
To bych zachlivkoval do kategorie bulvar :-) Vyvoj deb12 je aktualne v behu, mezi vydanimi jsou obvykle dva roky, od toho posledniho ubehl sotva pulrok... tzn. je jeste tak rok a pul cas. Ale nekdo holt potrebuje psat senzace o vecech z kategorie work-in-progress....
-
DannyStříbrný podporovatel
apt install usrmerge.. kde ze je problem? :-) Budete se divit, ale ono to ve vetsine pripadu (beznych use-case) bez problemu funguje uz davno. -
DannyStříbrný podporovatel
No jo, holt ne kazdy uplatnuje pristup buldozeru, kdy on neco o sve (libo)vuli rozbije a "nezajem, se prizpusobte". V Debianu se proste snazi byt ohleduplni - ale podle Vas je zda se ohleduplnost vada.
Problem delaji predevsim 3rd-party baliky - coz ostatne v te diskuzi na lwn, kterou jste sem hazel mate take zminene. Obcas je dobre si pozorne precist, co odkazujete :-) -
A napr tohle maji uz panove z fedory vyreseno nebo si to musi kazdy bastlit po svem ? https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/
-
Tohle se snazi resit v proxmoxu a celkem to funguje
https://pve.proxmox.com/wiki/Host_Bootloader#sysboot_proxmox_boot_tool
-
Diky za info - to jsem si nevsiml. Kazdopadne tohle by melo byt asi reseno vice systemove (base system), resp. maximalne transparentne pro uzivatele/admina aby vse pri updatu jadra probehlo pokud mozno bez dalsich nestandartnich prikazu. Cekal bych to napr u debianu v update-grub apod. Jinak ja osobne proti UEFI nemam vubec nic ale nez to zacnou lidem tlacit bez moznosti volby tak bych byl rad aby to fungovalo minimalne aspon tak jako obycejny BIOS :-)
-
Ja se vsadim ze ne ;-)) ... ze si clovek musi rucne naflakat 2x ne raid FAT a v biosu rict bootuj odsud a pak odsud ;-))
Ja myslim, ze RHEL nebude mit ani vyresen grub zavadec na SW raid, protoze je v casti disku, kde neni part, tak logicky neni mirrrovany ... tedy je treba jej rucne pridat jeste na 2 disk, kdyz ten 1. vypadne ... pak totiz server nenabootuje ... no ale jde to opravit rucne a opravdove servery maji HW raid slusneho vykonu ... kdyz uz nic tak aspon pro OS ... ja mam doma SW raid? proc? 1) nepotrebuji slot pro areca kartu a hlavne je to prenositelne bez zavislosti na HW, coz HW-RAID neni ... jasne staci koupit ARECA co to zarucuje nebo jineho vyrobcem u dellu o tom pochybuji ;-)) ale HPE a ten jejich smart array asi bude kompatibilni mezi modely ... kdysy to tak nebylo a nesehnal jsi stejny model karty - smula, kup novy a obnov ze zalohy
-
Bohuzel pouze prepnuti startu pocitace do UEFI, pokud mate nastaveno a instalovano na BIOS/legacy samozrejme nestaci. K tomu abyste mohli prejit na UEFI je potreba predelat celou zavadeci strukturu OS, pridat oddily na disk, idealne konvertovat MBR na GPT. V clanku tedy postradam zasadni informaci o tom, jakym zpusobem (ne)budou fungovat existujici mnohalete instalace delane na BIOSu.
Osobne nemam UEFI rad - BIOS byla rekneme ovladanim za roky vicemene jasna komponenta, ktera v urcitem okamziku predala rizeni zavadeci a zavadec zavedl jadro. UEFI prineslo modularni strukturu, ktera znamena totalni chaos - kazdy vyrobce ci dokonce OS si do UEFI naplaca co chce. Ve vysledku se kazdy OS zavadi jinak, u kazdeho jsou jine omalovanky pro nastaveni "BIOSu", ktere potrebuji mys a graficky monitor s dostatecnym rozlisenim jinak to dela psi kusy a to opet nemluvime o problemech pokud dojde na UEFI systemech k nejake havarii a je potreba je ozivovat. Moje zkusenost s UEFi je tedy spise spatna. Netvrdim ze je to samotnym UEFI, ale spis tim, ze jeho modularita umoznila OEM vyrobcum a vyvojarum OS nebyvalou kreativitu jak i ze zavadeni OS udelat necitelny proces.
-
> V clanku tedy postradam zasadni informaci o tom, jakym zpusobem (ne)budou fungovat existujici mnohalete instalace delane na BIOSu.
Staré inštalácie pokračujú v MBR. Odstránenie podpory je v tejto fáze z inštalátora - t.j. nenainštalujete novú inštalácu na MBR. Stará inštalácia pôjde upgradovať.
> BIOS byla rekneme ovladanim za roky vicemene jasna komponenta, ktera v urcitem okamziku predala rizeni zavadeci a zavadec zavedl jadro.
To nie je celkom pravda, BIOS poskytoval runtime funkcie, ako je ACPI.
> UEFI prineslo modularni strukturu, ktera znamena totalni chaos - kazdy vyrobce ci dokonce OS si do UEFI naplaca co chce.
Oni si to plácali aj do BIOS-u, akurát to nemohli robiť v C a museli to písať v ASM, muselo to byť v textovom režime, nemali k dispozícií knižnicu hotovej funkčnosti apod.
> Ve vysledku se kazdy OS zavadi jinak
Paradoxne, každý OS sa zavádza presne rovnako, cez ESP. Je definovaný spôsob, ako sa systém zaregistruje a prvý krát v histórii PC nie je problém multiboot a to, že by jeden systém prepisoval druhý.
> kazdeho jsou jine omalovanky pro nastaveni "BIOSu", ktere potrebuji mys a graficky monitor s dostatecnym rozlisenim jinak to dela psi kusy
Aké? Jediný psí kus čo som si všimol je, že na jednej Asrock doske a AMD grafike neviem donútiť použiť Full HD, stále to ide na 720p. (S Nvidia grafikou to išlo Full HD). Myš nie je potrebná.
> o problemech pokud dojde na UEFI systemech k nejake havarii a je potreba je ozivovat.
Toto je len o oboznámení s možnosťami, na UEFI je to oveľa jednoduchšie, UEFI má k dispozícií shell a neexistujú žiadne magické prvé sektory. Všetko je v súboroch vo filesystéme. Rozchodiť zhavarovaný UEFI systém sa dá rovno z konzoly, na rozhodený MBR systém treba minimálne ďalší bootovací disk.
-
Jan HrachStříbrný podporovatel
No hlavně tohle je v podstatě ekvivalent „syscallu“ a to se neobejde bez kousku nějakého takového kódu asi kdekoli. (ať to ostatní nemusí hledat, je to https://github.com/coreboot/seabios/blob/master/src/kbd.c#L198 )
6. 4. 2022, 18:24 editováno autorem komentáře
-
Sice je to uplne off topic, ale je v dnesni dobe nejaka moznost implementovat https://www.abclinuxu.cz/clanky/tipy/jak-na-animovane-lilo ?
Bylo to sice naprosto k nicemu, ale pochodujici tucnaci, nebo moznost hrat breakout primo v zavadeci byla zabavna :-D
https://www.abclinuxu.cz/images/clanky/krcmar/penguins.png
https://www.abclinuxu.cz/images/clanky/krcmar/breakout.png -
Nj, a presne pre taketo kraviny sa moze zdat niekomu ten UEFI boot pomalsi. Klasicky BIOS "skace" v textovom rezime rovno do loaderu. UEFI je to viac vycackane (a to aj na midrange serveroch) a ide to proste pomalsie. Este aj ten vypis na konzolu mi laguje oproti klasickemu textu.
Ja viem, ze UEFI dokaze zostat v klasickom textovom rezime. Len ludom asi kvoli eye-candy podsuvaju tieto veci.Osobne by som bol za kebyze sa uz nemusia riesit veci typu "je tato sluzba v BIOSe podporovana?", viem povolit A20 gate cez BIOS, pozna BIOS extended read a pod. Tato podpora veci na 8086 pri novych procesoroch je bolestiva. Toto by UEFI vyriesilo.
-
Na jednu stranu chápu tenhle krok a důvody za ním, ale na druhou jej odsuzuju.
Sice je UEFI "modernější", ale je to jedna prasárna vedle druhé. Například můj PC s UEFI nabíhá skoro 30 vteřin než dojde na GRUB. Tohle je způsobené jedním z problémů UEFI a to je absence kontroly závislostí mezi jednotlivými aplikacemi které v UEFI běží, a tak je naprosto běžné že se zmíněné aplikace dokola spouští a selžou protože jiná aplikace na které jsou závislé ještě neběží (často počínaje na jednotkách tisíců selhaných spuštění).
Argumentace pro GPT je size hezká, ale zde mám několik bodů:
- systémový disk větší než 2TB není moc bežný, obzvláště s oblibou SSD disků které jsou většinou menší
- v Linuxu je možné mít GPT tabulku i na legacy-BIOS zařízení, byť to není tak jednoduché tak to jdeUEFI má mnoho dalších problémů, které nyní postupně vyplývají na povrch kdy se nachází nové a nové bezpečnostní chyby v UEFI.
Já jsem velký fanoušek otevřených náhrad za BIOS a UEFI jako je například coreboot. Tyto náhrady jsou blíže legacy-BIOS než UEFI. Je možné tam přidat UEFI podporu, ale není to pravé ořechové a jde to proti jejich filozofii - třeba coreboot zastává přístup že po inicializaci a spuštění bootloaderu by nemělo z corebootu nic zůstat běžet. Zatímco třeba UEFI pořád běží na pozadí aby mohlo poskytovat všelijaké servisy operačnímu systému. Doma provozuji několik počítačů s corebootem a tedy vyžaduju systém co podporuje legacy-BIOS.
Dalším z argumentů pro tyto otevřené náhrady je eliminace (nebo alespoň redukce) systémů jako jsou Intel Management Engine nebo AMD Platform Security Processor, které jsou běžně považované za svinstvo.
-
disk bez GPT - max 2TB jo jde to a je to jedno, ale uz neni mozno zbytek disky vyuzit ... ja resil podobny problem na stare 386, mel jsme tam vetsi disk nez podproval BIOS a udajne i radic (coz nebyla pravda) ... reseni byly 2 - boot z FDD ;-)) a nebo se tam udelala max 512MB z te se nabootvalo, kupodivu mu nevadilo, ze tam pak byla i jina part. kterou bios nevidel ,ale linux po natazeni kernelu uz ano ... to byla doba, kdyz jsme mel i par starych kramu i jako terminaly a pozival jsme i vyrazene disky, kde jsme pres part. preskocil vadne bloky ... v te dobe byl HW drahy a srot sel ziskat zadarmo ;-)
-
Pokaždé, když musím něco řešit s UEFI, vzpomenu si na první přednášku o UEFI, kterou jsem slyšel ještě v době, kdy to byla horká novinka, konkrétně na tuto část:
Pamatujete si ten slavný Linusův výrok, kde autory BIOSů označil za crack addicted monkeys? Tak věc se má tak, že implementace UEFI píší ti samí lidé, kteří doteď psali BIOSy, a hlavní rozdíl je v tom, že UEFI je mnohem složitější.
-
Tady neni az tak problem s BFU - ti maji computery s parametry, ktere nema ani nas server v praci. Tady je spis problem s embeded zarizenimi, ruznymi all-in-one, kde se dodnes prodavaji PC, na kterych nebezi ani Ubuntu 14. Spousta nasich zakazniku ma hardware z pocatku stoleti koupeny nedavno a na nem Connectiva. Kdo ji nezna, je to odvar Redhat 8. Mnoho ctenaru Roota jeste nebylo na svete, kdyz byl tento system vydany.
Mimochodem, pamatuju doby, kdy Linux bezel na 4M RAM. Ne GIGA, ale MEGA. To bylo v dobach kernelu 0.99RC2 :-) Dnes by 4M nestacilo ani na GRUB :-) -
Já pamatuju "až" Debian 2 (předtím jsem byl moc BFU než abych věděl že vůbec existuje něco jiného než DOS a Windows). Nedávno jsem se nudil tak jsem si na historický HP Vectra VL s Pentiem 90MHz instaloval Debian 2.2r7. Napřed jsem musel vyměnit IDE mechaniku, protože ta co tam byla už nečetla. Ale pak OK a po instalaci fungovalo všechno včetně 10Mbps síťovky. Sranda... :-)
-
BobTheBuilderStříbrný podporovatel
HTTP EFI boot není slavná ani na fyzických deskách - potkal jsem ji jen u Gigabyte.
-
konkretne s KVM/QEMU s PXE UEFI nemam roky problem, co za bugy mas na mysli? startuju v tom bezne Live ci instalace *buntu, Clonezilla, instalace Windows (W7,W10,W11)...
s UEFI HTTP netusim, nepouzivam, ale pokud se nepletu Legacy-PXE-HTTP neexistovalo, takze jeho problemy pri prechody na UEFI jsou prekazkou jak? :-)
-
HTTP UEFI boot je vec od UEFI 2.5, takze kazdy kompatibilni firmware by to mel podporovat.
Prekazkou k migraci na UEFI to ale samozrejme neni.UEFI navic oproti legacy bootu nabizi i podporu bootovani po siti po IPv6 (po IPv4 i IPv6), coz jsem v BIOS svete nikdy nepotkal.
Na fyzickych serverech je bootovani v UEFI rezimu obvykle rychlejsi nez v legacy (nemusi se zbytecne inicializovat BIOS kompatibilni oprom na pridavnych kartach), nekdy je potreba flashnout spravny firmware (naposledy na Mellanox sitovkach, built in firmware bylo potreba flashnout a pak jeste podporu UEFI bootu zapnout).
KVM/QEMU je zabugovane, to je pravda. Muj oblibeny bug je ten, kdy nelze zmenit poradi bootujicich UEFI aplikaci ani povolit boot po siti po IPv6.
