Vlákno názorů k článku Je čas opustit BIOS a přejít na UEFI? Vývojáři Fedory o tom diskutují od CX - Ja osobne mam radsej BIOS, lebo startuje rychlejsie...
-
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
