Dotaz: Konverze z BIOS do UEFI nebo raději nová instalace?

[Pavel 'TIGER' Růžička]

Ahoj, zatím jsem to nepotřeboval, ale vyplatí se systém z BIOSU konvertovat do UEFI, resp. MBR do GPT, nebo je časově výhodnější čistá instalace? Co koukám na návody, tak to zas taková legrace není, nebo se mýlím?

---

---

Odpovědi

[billgates]

Robil som to uz na viacerych serveroch s CentOS 8 a nie je to az taky problem, ak teda clovek vie nabootovat do nejakeho livecd a upravit to tak. Zo ziveho systemu som to este neskusal. Ci to ale prinasa aj nejaku realnu vyhodu, to naozaj netusim. Ale technicky to ide.

Jediny problem som mal na serveri, kde nejaky plantaznik nastavil prvy sektor prvej particie uz od 1 a nie 2048, ako je bezne. Inak konverzia z MBR na GPT je bezproblemova a potom uz len nastavit grub2, aby bootoval v EFI rezime je tiez jednoduche. U nas som este riesil, aby to bootovalo aj cez EFI, aj starym sposobom a tam sa uz treba trochu pohrat. Ale aj to ide pomerne jednoducho.

Cize celkovo nejde o nic zlozite.

[Pavel 'TIGER' Růžička]

Ok, díky za info, zkusím si to.

[k3dAR]

jeste zalezi zda mas nejaky oddil (nemusi byt nutne na zacatku) ktery muzes o 100-200MB (v extremu asi o aspon 10MB) zmensit a udelat tam EFI oddil (nastavit mu priznak boot a esp, format (radeji) FAT32)...
a se secureboot doinstalovat "grub-efi-amd64-signed shim-signed", pripadne misto Grubu pouzit sicherboot (pro nej EFI oddil 500-1000MB (podle toho kolik ocekavas nainstalovanych kernelu, kazdej zabali s initramfs, podepise tvejma klicema a hodi do EFI)

[Pavel 'TIGER' Růžička]

Ono to půjde na nový (větší) disk, takže v prostoru problém nebude. Přemýšlel jsem, že bych na tom novém disku vytvořil GPT na něm EFI a k němu z MBR překopíroval oddíly. Nebude problém, když budu kopírovat oddíly z MBR do GPT? Teoreticky v tom problém nevidím, prakticky jsem to ještě nikdy nedělal, respektive nepotřeboval.

[billgates]

Jedine, ak sa zmenia UUID, resp. nazvy oddielov a pouzivaju sa vo fstab. Inak by to problem robit nemalo.

[Pavel 'TIGER' Růžička]

Jasně, díky.

[k3dAR]

pokud budes kopirovat bitove tak problem neocekavam...
a kdyz pujde o novej disk doporucuju dat EFI na zacatek, resp. pokud chces mit moznost Legacy i UEFI tak na GPT disku dat i pidi oddil pro GRUB legacy:

2048s az 4095s - 1 oddil, velikost 1MiB, pridat priznak "bios_grub"
4096s az XXXMiB - 2 oddil, EFI, priznak "boot" a "esp"

a nainstalovat pak gruby oba (variace kde neni potreba uvadet --target zalezi od toho kterej z vylucujicich se primarnich metabaliku mas, zda grub-pc ci grub-efi)

# pro Legacy
grub-install --target=i386-pc /dev/sdX

# pro UEFI
grub-install --target=x86_64-efi /dev/sdX

[Jendа]

Ono to půjde na nový (větší) disk, takže v prostoru problém nebude.

Tak v tom případě vůbec netuším, co řešíš, myslel jsem, že jde o in-place konverzi. Vytvoříš na novém disku nové oddíly (jak velké? mně žere dohromady 100 MB nějaké HP SystemDiags které se bojím smazat + kopie aktuálního a upgradovaného BIOSu; GRUB samotný je malý, defaultně má asi 2 MB a když si uděláš vlastní image jen s potřebnými moduly, tak ~300 kB), zkopíruješ, upravíš fstab a hotovo, ne?

Nebude problém, když budu kopírovat oddíly z MBR do GPT?

Nebude, ale já vždycky vytvořím nový filesystém a kopíruju soubory rsyncem (--inplace --numeric-ids -avzhP a možná ještě -HXS).

[Petr Fiedler]

Je dobré použít i parametr --exclude (sekce "Full system backup").

# rsync -aAXHv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /path/to/backup

Plus tedy i ty tvoje parametry. O těch se tam níže také píše.

[k3dAR]

To nezkopiruje z /dev staticke zarizeni co tam maji byt (videls bys je v rootfs z live, kdy do /dev neni pripojen dynamickej generator udevfs), takze lepsi je:

sudo mount --bind / /mnt/zdroj
sudo rsync ${parametry} /mnt/zdroj /mnt/cil

[Petr Fiedler]

Jaká statická zařízení? V Live se pak podívám.

[k3dAR]

rootfs ma v /dev "soubory" pro zakladni zarizeni, nez se dostane ke slovu udev, ktere do /dev pripoji udevfs zobrazujici "soubory" pro realne (vicemene) zarizeni, to co nemas rsyncovat je obsah /dev generovanej tim udev, ale mel bys tam mit obsah "pod tim" to co ma v sobe rootfs... to co je v /dev "napevno" v rootfs krome live uvidis prave i kdyz rootfs bindnes jinam, tak uz nejsou na nem povesene/pripojene zadne jine filesystemy, takze vse je ciste rootfs...

[j]

viz Jenda, neni co resit. Delat nejakou konverzi je obecne pitomost, nic tim neziskas, snad leda kdybys ten disk byl nucenej dat do HW kterej neumi MBR.

Pokud to davas na novej disk, tak si nejdriv priprav ten novej disk, a pak na nej syncni soubory, opet nema smysl resit nejaky nesmyslny dd a podobny hruzy. Maximalne pak upravis fstab, ale pokud v nem pouzivas nazvy partysen a v ramci pripravy pouzijes stejny netreba ani to. Navic muzes timhle zpusobem (narozdil od dd) i zmenit fs, pokud by se hodil jinej nez co mas aktualne. A jako bonus nemusis nasledne resit nejaky roztahovani partysen, coz je taky specielne s nekterejma fs adrenalinova zabava.

BTW: Prakticky je to predevsim o tom adrenalinu, zvlast kdyz to delas inplace na bezicim systemu. Jde to, ale ... (za chodu odstranujes a vytvaris partysny a tak podobne, pokud neco failne/vypadne elektrina/... tak ti system uz nenabehne)

Apropos, a najednou se taky velmi hodi, kdyz mas boot jako samostatnou partysnu, protoze pro efi ... potrebujes jednu s fatkou, takze mas kde ji vzit.

---

Dete s tim guuglem dopice!

[lertimir]

Na nezašifrovaném systému bych to asi dělal úpravou. na plně zašifrovaném root i boot bych volil novou instalaci. zase tolik práce zazálohovat konfiguraci a seznam balíků a pak je tam vrátit, může být jednodušší než opatrné šudlení s přechodem, s tím, že když uděláš chybu, ani to nebootne.

[Pavel 'TIGER' Růžička]

Nešifruji, takže tento problém odpadá. Disků je dost, pracovat budu se zrcadli, takže když udělám chybu, budu se moct vrátit do výchozího bodu.

[Jendа]

Nová instalace je blbost vždycky, v nejhorším to budeš muset někam zkopírovat a pak to zkopírovat zpátky.

Naprosto zásadní je aktuální rozdělení disku. Pro výrobu GPT budeš potřebovat na začátku trochu volného místa. Pokud máš na začátku jako první oddíl /boot, bude to easy, protože se snadno zruší a vytvoří trošičku menší posunutý. Pokud ne, i tak by to možná mohlo jít, pokud ti nezačínají data na 63. sektoru (jako to dělaly pre-2013 cfdisky), ale až na 2048. - nevím z hlavy, jestli 1 MiB stačí. Když je toto splněno, provede se konverze gdiskem. Následně pro UEFI boot vytvoříš EFI-boot oddíl a nainstaluješ grub-efi.

[Livan]

Marně přemýšlím nad tím, k čemu by taková konverze byla dobrá. Nepřináší to žádné výhody.

[k3dAR]

Napr. SecureBoot (idealne s vlastnima klicema), pak treba polozka "Vlez do BIOSu" v Grub nabidce, moznost mit vice zavadecu a ne jen 1 v mbr, urceni primarni boot polozky ci boot poradi v OS, atd...

[Jendа]

Přenos disku do počítače, který nepodporuje legacy boot?

[Pavel 'TIGER' Růžička]

Ty jsi na to přišel, tohle je přesně ten důvod.

[Jendа]

A když píše že to ve skutečnosti kopíruje na nový disk: pořízení disku přes 2 TB, takže MBR tam nemůže vytvořit oddíly?

[trekker.dk]

To ještě neznamená, že je potřeba i UEFI boot, legacy nabootuje i z GPT (přesněji: nesetkal jsem se hardwarem, kde by to nefungovalo)

[Pavel 'TIGER' Růžička]

Tak třeba ASRock B450 Pro4 na NVME nenabízí legacy boot. Na USB a SATA ano.

[jiwopene]

Ano. Legacy BIOSu je úplně jedno jak je disk rozdělený. Ten si jenom prohlédne disky (zpravidla v uživatelem určeném pořadí) a první, který je bootovatelný (tj. jeho 1. sektor¹ končí 0x55aa), nakopíruje tento sektor ho na 0x7c00 a skočí na tuto adresu. To je proveditelné jak u MBR, který nechává právě 440 prvních a 2 poslední byty tohoto sektoru volné, tak i u GPT, kde je tento sektor k použití volný celý².

---

¹ 1 sektor = 512 bytů, tedy alespoň v tomto případě

² To umožňuje vytvořit tzv. hybridní GPT, kde jsou použity obě tabulky na jednom disku zároveň.

[LarryL]

Myslím, že tady je to na obrázku.

[jiwopene]

Proč konvertovat MBR→GPT? Počítače UEFI většinou umí pracovat a bootovat i s diskem naformátovaným s MBR. Pro boot z MBR pomocí UEFI stačí vytvořit EFI partition¹ (0xef) a tam nainstalovat GRUB (grub-install --target=x86_64-efi --efi-dir=/efi …, kde do /efi je přimountován zmíněný EFI partition).

Doporučuji zůstat při MBR a jenom zajistit bootování z EFI system partition, pokud Vás MBR neomezuje (např. max. velikostí disku).

Pokud přecházíte na GPT z důvodu pořízení nového disku, tak je cesta jednoduchá: rozdělit disk, překopírovat data a nastavit GRUB (nebo jiný zavaděč).

---

¹ Jmenuje se to EFI System Partition, nebo tak nějak.

[Pavel 'TIGER' Růžička]

Tak jsem skončil v grub shellu, ale po následujícím systém zavedu:

grub> set root="(hd0,gpt2)
grub> set prefix=(hd0,gpt2)/boot/grub
grub> insmod normal
grub> normal

Po naběhnutí update-grub se provede bez chyby, ale po restartu skončím zase v grub shellu. Zkoušel jsem celý grub odebrat a znovu nainstalovat, ale se stejným výsledkem. Koukal jsem i do grub.cfg v EFI oddílu, ale i tam to vypadá správně.

search.fs správné-uuid root
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

Nějaké nápady? Já už jsem zacyklen ...

[k3dAR]

preinstaloval si jen balicky (asi zbytecne) nebo i grub na disk? a jete me napadlo, v nebehlem systemu mas EFI oddil pripojen pres fstab do /boot/efi ?

[Pavel 'TIGER' Růžička]

Balíčky i grub na disk, pro jistotu jsem i smazal obsah EFI oddílu, před reinstalací, abych měl jistotu, že se to tam zapíše. Ano, EFI mám v fstabu do boot/efi a dále cesta pokračuje /EFI ... Jsem přesvědčen, že to bude nějaká kravina, na kterou nemohu přijít. Jinak je to aktuální devuan. Ele nikde jsem nenalezl, že by v tom měl mít bug.

[k3dAR]

netrkne te neco v "efibootmgr -v" ?

[LarryL]

Ano k tomu jsem směřoval s mým dotazem jestli opravdu spouští správný EFI, ale kdyby bylo špatně EFI, tak by to IMHO mělo skončit v EFI shellu a né v grub shellu. Je to taková víkendová hádanka

[Pavel 'TIGER' Růžička]

Ja to napůl nečitelné, ale to co přečtu sedí.

BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001
Boot0000* devuan	HD(1,GPT,f8ac0ac2-eb05-49cb-8ec4-fb30ef59a77f,0x800,0x200000)/File(\EFI\devuan\shimx64.efi)
Boot0001* Hard Drive	BBS(HD,,0x0)..GO..NO.........K.I.N.G.S.T.O.N. .S.A.2.0.0.0.M.8.2.5.0.G....................A.......................................&.hI}k5.....6..Gd-.;.A..MQ..L.5.0.0.2.6.B.7.6.8.4.9.7.D.6.B.3........BO

[LarryL]

shimx64.efi

Aha, tak to ale musíš mít zaplý SecureBoot. Tímto příkazem bys měl ověřit zda ho máš enabled:

mokutil --sb-state

[Pavel 'TIGER' Růžička]

Počkej, to jako nemohu nainstalovat grub na efi, bez zaplého secure bootu? Ten já nechci.

[Jendа]

Samozřejmě můžeš. Ale pak je zbytečné používat shim.

[k3dAR]

zkus odinstalovat balicek shim (a/nebo shim-signed), pak radeji znovu grub-install /dev/nvme0n1, a pak zkontrolovat "efibootmgr -v" zda uz misto na shimx64.efi ukazuje na grubx64.efi

[LarryL]

Nepoužívám Devuan, takže možná je to tam jinak a shim se používá i když nepoužíváš SecureBoot, ale třeba u Fedory po příkažu efibootmgr -v jsou dvě verze efi a to:

Boot0000* Fedora HD(2,GPT,...)/File(\EFI\FEDORA\GRUBX64.EFI)

...

Boot0003* Fedora HD(2,GPT,...)/File(\EFI\FEDORA\SHIM.EFI)

A nejsem si teď jistý jestli se SHIM.EFI mohlo použít i když SecureBoot byl vyplý.

[Pavel 'TIGER' Růžička]

No zkusím to, ale moc tomu šanci nedávám, protože tu na jednom sata mám čistou instalaci, která správně startuje i bez secure bootu a:

BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001
Boot0000* devuan        HD(1,GPT,f8ac0ac2-eb05-49cb-8ec4-fb30ef59a77f,0x800,0x200000)/File(\EFI\devuan\shimx64.efi)
Boot0001* Hard Drive    BBS(HD,,0x0)..GO..NO........u.K.I.N.G.S.T.O.N. .S.U.V.4.0.0.S.3.7.2.4.0.G....................A.................................>..Gd-.;.A..MQ..L.0.5.2.0.B.6.2.7.B.6.4.0.B.A.2.4. . . . ........BO..NO.........K.I.N.G.S.T.O.N. .S.A.2.0.0.0.M.8.2.5.0.G....................A.......................................&.hI}k5.....6..Gd-.;.A..MQ..L.5.0.0.2.6.B.7.6.8.4.9.7.D.6.B.3........BO

[k3dAR]

tak rovnou porovnej nainstalovane balicky grub* shim* :)

[Pavel 'TIGER' Růžička]

Díky, jsem tam, sice nevím, proč mi to při aktualizaci balíčků grubu z MBR na EFI natáhlo i ten shim, ale nechal jsem jen shim without secure boot a jsem tam. Každopádně Vám všem díky za trpělivost. Já psal, že jsem to ještě nikdy nedělal, protože jsem to nepotřeboval. DÍKY!

BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0000,0001
Boot0000* devuan	HD(1,GPT,f8ac0ac2-eb05-49cb-8ec4-fb30ef59a77f,0x800,0x200000)/File(\EFI\DEVUAN\GRUBX64.EFI)
Boot0001* Hard Drive	BBS(HD,,0x0)..GO..NO.........K.I.N.G.S.T.O.N. .S.A.2.0.0.0.M.8.2.5.0.G....................A.......................................&.hI}k5.....6..Gd-.;.A..MQ..L.5.0.0.2.6.B.7.6.8.4.9.7.D.6.B.3........BO
Boot0002* UEFI OS	HD(1,GPT,f8ac0ac2-eb05-49cb-8ec4-fb30ef59a77f,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)..BO

[Jendа]

Když do grub shellu zadáš ty příkazy

search.fs správné-uuid root
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

místo tamtoho, tak to proběhne OK?

[Pavel 'TIGER' Růžička]

Ano, nastartuje, jsem tam. Tak to už fakt nemám tušení, čím by to mohlo být. Už přes den si hraji jen s grubem.

[LarryL]

Možná napíšu blbost, zas tak často se v grubu nehrabu, ale nebootuješ náhodou pořád do toho starého grubu? Jsi si jistný, že bootuješ EFI?

[Pavel 'TIGER' Růžička]

Domnívám se, že starý grub by se z gpt nespustil a to ani do grub shellu. Navíc efi oddíl byl vytvořen úplně nově. Chyba je v tom, že grubová část na efi z nějakého důvodu automaticky nespustí tu část v boot na ext4. Manuálně to z grub shellu funguje. Takže se domnívám, že části jsou nainstalované správně, jen mají z nějakého důvodu problém s komunikací mezi sebou.

[LarryL]

Myslel jsem to tak, jestli na disku pořád nemáš grub v MBR a jestli jsi v Biosu nezapomněl přepnout bootování z "Legacy Mode" do "UEFI mode". Mám dojem, že jsi tady někde psal, že cílem je přenos do PC, které neumí Legacy boot, takže tvůj problém bude asi fakt někde jinde.

[Pavel 'TIGER' Růžička]

Disk je v GPT, takže MBR je mimo hru.

[jiwopene]

Není.

[Pavel 'TIGER' Růžička]

To ale jen v případě konverze. To už tu také bylo psáno.

[Jendа]

Domnívám se, že starý grub by se z gpt nespustil a to ani do grub shellu.

Spustil, pokud se při vytváření GPT nepoškodila stage1.5 (která je nainstalovaná za 1. sektorem, a kdysi se vešla do 31.5KiB když člověk neměl moc modulů.

[Pavel 'TIGER' Růžička]

Ale to by bylo pouze v případě konverze, ne? Já kopíroval oddíly na nově vytvořený gpt a žádný z těch oddílů neměl příznak boot. Takže si nemyslím, že bych si ho tam mohl nějak zavléct.

[Jendа]

Aha, tak to ne, no.

Btw. na tohle pozor, některé desky mají bug (misfeature) a když žádný oddíl nemá bootflag, tak odmítnou nabootovat (bavíme se o MBR/DOS tabulce).

[LarryL]

Chyba je v tom, že grubová část na efi z nějakého důvodu automaticky nespustí tu část v boot na ext4

Takže když při startu podržíš F11 (nebo co se u tebe mačká pro vstup do UEFI Boot Menu), tam vybereš "UEFI: tvůj OS", dáš enter, tak pak ti to hned skočí do grub shellu?

[LarryL]

...vlastně tam nebude "UEFI: tvůj OS", ale "UEFI: tvoje zařízení".

[Pavel 'TIGER' Růžička]

Mám obé, nakonec jsem přeci jen vybral desku, která nějak i podporuje MBR. Leč vypadá to, že ne NVME podpora pro MBR není. Ale moc jsem to nezkoušel.

[Pavel 'TIGER' Růžička]

Přesně tak, vyberu "UEFI:devuan" a šup, je tam grub shell. Je to šílené, člověk musí projít dva "operační systémy" (UEFI a grub], než se dostane do toho co potřebuje. S láskou vzpomínám na lilo. Tam nebylo co nastavovat.

[LarryL]

Až přežiješ první porodní bolesti, tak uvidíš jak si budeš pomlaskávat s EFI

[Pavel 'TIGER' Růžička]

Mno nevím, subjektivně se mi zdá, že než se dnešní stroje dostanou k zavádění systému, tak 486ka už zaváděla. Tím nechci psát, že by systém zavedla rychleji, to určitě ne.

[trekker.dk]

Já je přežil a žádné pomlaskávání nenastalo, považoval jsem to za překomplikovaný křáp předtím už od pohledu a považuju to za překomplikovaný křáp i teď, když jsem si to vyzkoušel. IMO příspěvek #22 je jediný důvod, proč dneska přecházet na EFI boot

[Pavel 'TIGER' Růžička]

Bohužel už jsem potkal stroje, kde ten Secure Boot byl natvrdo zadrátovanej a nešlo to nikterak obejít. Navíc třeba nový VirtualBox potom vyžaduje podpisy svých modulů. Ano vím, je tu i VMM, ale bohužel nezvládá přímé sdílení složek, na které jsem si dost rychle zvykl. Takže nepoužívat Secure Boot zjednodušuje život.

[LarryL]

Já je přežil a žádné pomlaskávání nenastalo

Tak, že by to u tebe bylo podle pořekadla, že starého psa novým kouskům nenaučíš?

Správa EFI souborů se mi zdá jednodušší.

IMO příspěvek #22 je jediný důvod, proč dneska přecházet na EFI boot

Nemožnost bootovat legacy určitě není jediný důvod. Někdo chce SecureBoot nebo Sicherboot. To bez EFI neuděláš.

[Pavel 'TIGER' Růžička]

Já nemám nic proti inovacím a učením se novým věcem, ale musí to dávat nějaký smysl. Dnes každá deska má různě rozházená grafická klikátka, a než to člověk všechno projde, tak to trvá. Troufám si napsat, že tui biosu přineslo větší efektivitu. Grub se nám také od první verze trošku pozměnil a to jej raději nebudu přirovnávat k lilu. A to všechno jen kvůli zavedení systému! Většina těch věcí by šla řešit na systémové úrovni a ne to takhle pytlíkovat od nadstavby k nadstavbě. Pochopitelně to neplatí jen pro Linux. Zkrátka od minimalismu jsme přešli k neuvěřitelnému plýtvání a to nejen v počítačovém světě.

[LarryL]

Příloha:

• Difference-between-UEFI-and-BIOS.jpg (25503 bytů)

pytlíkovat od nadstavby k nadstavbě

Když si to hezky namaluješ (v příloze), tak u UEFI je o jeden krok méně - chybí Bootloader.

[j]

lol ... kdyz udelam chlivek [boot], tak sem z toho udelal jeden krok, ze?

Az na to, ze MBR === spust kod (max necely 1/2kB) kterej je na zacatku disku X ... TECKA. Takze jediny co ten bios udela je to, ze si najde disk, podle nejakyho poradi ktery si mu nastavil, a z toho disku precte prvni sektor a to co je v nem spusti.

Kdezto EFI === nastartuj operacni system z nejaky epromky ... az tady nekde pripoj fat ktera je (mozna) nekde na nejakym disku ... na ty si precti nejaky XML ... v tom XML mozna najdes (a mozna taky ne) odkaz na nejakej soubor ... mam pokracovat?

A vysledek je ... exaktne stejny, jen je na to potreba o nekolik radu vic naprosto vseho, ze? O bezpecnosti radsi nemluvit, protoze neexistuje. A to se virus vpohode vejde i do toho mbr. Jenze to soudobi patlalove davno netusej.

BTW: Bejvaly casy, kdy se i ten grub (lilo pochopitelne taktez) do MBR vesel celej, ze?

---

Dete s tim guuglem dopice!

[LarryL]

O bezpecnosti radsi nemluvit, protoze neexistuje

Mluvíš o MBR nebo EFI? Ty nedůvěřuješ SecureBoot a Sicherbootu? Je nějaká alternativa SecureBootu/Sicherbootu na MBR?

[Jendа]

BTW: Bejvaly casy, kdy se i ten grub (lilo pochopitelne taktez) do MBR vesel celej, ze?

Ne, nebejvaly. Vešla se tam stage1. Zbytek se nainstaloval do volného místa před první partition. Tohle „grub se najednou nevejde“ je způsobeno tím, že staré cfdisky (a asi i další nástroje) vyráběly 1. partition na sektoru 63, takže pro stage1.5 bylo jenom 31.5KiB místa. Takže když pak lidi začli do stage1.5 image strkat podporu pro RW ext4 a degradovaný RAID5 a další věci, tak to přestalo chodit. A nové cfdisky už zarovnávají partition na celé megabajty, takže se stage1.5 vejde.

[jiwopene]

[…] takže pro stage1.5 bylo jenom 31.5KiB místa. […]

Tuším, že GRUB 2 dokonce odmítne vytvořit image pro BIOSy, pokud tuto velikost přesahuje.

[trekker.dk]

Správa EFI souborů se mi zdá jednodušší.

Pro správu EFI souborů jsem si musel napsat nástroj, protože distribuční nepočítá s tím, že bych chtěl mít zavaděč na víc než jednom disku. Ano, mám tak přemrštěné požadavky, že chci, aby systém nabootoval, i když odejde ten správný disk. Narozdíl od toho grub pro legacy boot má zápis zavaděče na disky dle seznamu a nebylo potřeba dělat nic dalšího, než ho nechat nainstalovat distribučním nástrojem na správu balíků

Ergo: správa EFI souborů není jednodušší

[Pavel 'TIGER' Růžička]

Tak mne třeba zarazilo, že u EFI oddílu nelze změnit UUID, je třeba oddíl odstranit a vytvořit znova. Ale ani potom nešel znova zapsat grub na disk, hlásil něco, že rozšířené možnosti nejsou k dispozici, či tak něco, přesnou citaci jsem si nezaznamenal. I když je secure boot vypnuté, tak jsem musel do UEFI, vymazat certifikáty (co má co vůbec zapisovat nějaké certifikáty při vypnutém secure bootu?) a teprve potom šel opět grub nainstalovat. Očekával bych, že se certifikáty aktualizují, či jen zapíší nové, ale že je musím manuálně vymazat a teprve potom mám zpřístupněnou jednotku, tak to není moc praktické.

[LarryL]

(co má co vůbec zapisovat nějaké certifikáty při vypnutém secure bootu?)

Za to přece nemůže UEFI. Když jsi mu dal příkaz na zapsání certifikátů, tak se zapsaly. Příkaz efibootmgr (s patřičnou volbou) ti taky zapíše do EFI Boot Manageru. Když intaluješ Windows tak si tam zase zapíše licenční klíč. Počítač musí poslouchat a když přikážeš, aby zapisoval, tak zapíše.

[jiwopene]

Počítač musí poslouchat a když přikážeš, aby zapisoval, tak zapíše.

Jak který… Zrovna u EFI jsem se setkal s tím, že po několikátém nabootování takto zapsané informace zmízely. Zlatý BIOS, kde stačilo jen mít na disku magické číslo (0x55aa) a často i bez nutnosti jakékoliv další konfigurace to bootovalo.

[LarryL]

po několikátém nabootování takto zapsané informace zmízely.

Dneska aby člověk zálohoval i EFI partišnu , ale zas co bys chtěl od FATky, která pamatuje ještě Lenina.

[jiwopene]

Zapoměl informace o tom, z čeho má bootovat.

[LarryL]

Boot Order se ukládá do CMOS, tak že by slabá baterka, která vymazala CMOS?

[j]

To nemusi mit s baterkou vubec nic spolecnyho ... totiz soudruzi (predevsim vyrobci NB ale nejen) neumej vubec nic ... a pak to vypada tak, ze specielne s nonwidli konfiguraci to funguje metodou nahodnych cisel = nekdy to nastartuje, nekdy ne, nekdy to vidi co ma, nekdy ne, nekdy tomu poumuze upgrade biosu, nekdy naopak downgrade (coz uz soudruzi vymysleli, takze to prosychr nejde) ...

Opakovane sem tohle resil na notesech od HP, vs veracrypt. Klidne exaktne stejnej model se stejnym PN, a kazdej jeden se chova jinak. Jediny co to jakoze "umelo" nastartovat byly widle. Takze nekdy bylo "resenim" jim proste tvrdit, ze ten loader sou widle.

Kdyz to pak zkombinujes s widlema, jejichz chovani se od dob w9x nijak nezmenilo, a prepisou ti jak mbr tak efi tema svejma srackama, mas o zabavu postarano.

BTW: Normalne se chovajici HW ma bydefault nejaky poradi bootu, a pokud je z ceho nastartovat, tak nastartuje. Jediny co se ti tudiz muze stat je to, ze nastartuje neco jinyho nez bys chtel.

---

Dete s tim guuglem dopice!

[jiwopene]

BTW: Normalne se chovajici HW ma bydefault nejaky poradi bootu, a pokud je z ceho nastartovat, tak nastartuje. Jediny co se ti tudiz muze stat je to, ze nastartuje neco jinyho nez bys chtel.

Např. moje desktopová deska od ASUSu by default nebootuje, tedy, abych byl přesnější, bootuje jen z removable¹ médií. A navíc pokud odpojíte pevný disk (i pokud na něm není EFI partišna), nastavení pořadí i s disky zmizí a oživit to můžete jen z EFI shellu nebo jiného nástroje, který máte na removable disku. Hardware, který bootuje s EFI rozumně mi připadá jako poměrně vzácně se vyskytující věc. Některé počítače jsou vyloženě podivné. Např.:

• Notebook Acer — Pokud chceme přidat položku k bootování z ne-removable média, nastavíme heslo pro vstup do Setupu (ano, je to nutné), zapneme Secure Boot, přidáme položku prostřednictvím k bootování (výběr souboru, názvu), nastavíme si Secure Boot dle libosti a, chceme-li, heslo zrušíme. Mezi tím prokládáme restarty, už nevím jak. (Druhá možnost je tuším přidat položku z běžícího OS nebo EFI shellu, který máme na svém removable (bootujícím) médiu.) Pokud zapneme boot z MBR, tak po zapnutí roztočí disk, zastaví ho, roztočí ho a potom bootuje.
• Tablet Acer – Když už se nám povede přidat položku do seznamu k bootování (zpravidla s novou položkou nabootuje max. jednou), může nám kdykoliv zmizet. Hledal bych souvislost s nevhodným spuštěním/vypnutím, je to celkově divný² HW.
• Deska výše

---

¹ USB disk, CD, …

² Při zapínání se někdy „zapne jen kontrolka“, jindy se třeba kontrolka nerozsvítí, zapomíná nastavení, …

[jiwopene]

Ostatní nastavení (vč. času) zůstala. A navíc bych nečekal, že tam je baterkou zálohovaná RAM (je to tablet).

[LarryL]

(je to tablet)

EFI na tabletu jsem ještě neřešil, to muselo být zajímavé dobrodružství

[jiwopene]

Je to Acer Aspire Switch 10E (nebo tak nějak). Prodávali to s Windowsem. WiFi (myslím, že SDIO) občas přestala fungovat (do restartu), klávesnice+trackpad+USB3 je v dokovací stanici s mizerným kontaktem (nějaký 10pinový konektor), paměti je pro používání s Windows 10 celkem málo a navíc několikrát do týdne při denním používání Windows spadl.

Teď tam mám Gentoo¹ (kompilovaný na jiném HW) a po pár komplikacích funguje bez problému. (Až na tu kontrolku napájení, která indikuje stav velmi špatně – při běhu někdy nesvítí, nebo naopak tan tablet zapínám a zapne se mi jenok kontrolka ☺. A také zmiňovaný konektor.) Někdy bych sem mohl o tom něco napsat.

---

¹ Měl tam jít Arch, ale tam jsem byl rád, že nabootoval. Většina aplikací padala se SIGILL nebo něco takového.

[Jendа]

Tak třeba EliteBug 8470p vyžaduje partition tabulku s nastaveným aktivním oddílem, jinak disk nevidí.

[k3dAR]

HP EliteBook 8460p take...

[Pavel 'TIGER' Růžička]

A kdo tedy za to může, když UEFI jasně ví, že má vypnutý secure boot a přesto dovolí zapsat certifikáty? Minimálně by UEFI na tu skutečnost mělo instalační program upozornit.

[LarryL]

No ale ty bys nebyl schopen nabootovat kdybys nejdřív povolil SecureBoot a až pak chtěl instalovat certifikáty, SicherBoot nebo cokoliv co je závislé na SecureBootu.

[dustin]

Takže vlastně když nebude disk s aktualizovanou EFI partišnou, tak to nenabootuje. Zatímco u legacy stačilo jen na disk nainstalovat grub. To mě nenapadlo.

[k3dAR]

nejspis narazel na to, ze pri konfiguraci balicku grub-pc (=legacy) je dotazan na 1 ci vice disku, kam se ma (do mbr) nainstalovat a nasledne pri aktualizaci balicku aktualizovat grub, naproti tomu grub-efi se na to nepta(?) a instaluje do /boot/efi/ tzn. musel by nejakej hook dle pripraveneho seznamu pripojit ze vsech dalsich disku EFI oddil nekam a naintalovat grub do teto cesty, nebo provest rsync z /boot/efi

[jiwopene]

Já jsem na tohle našel jednoduché řešení: napsat si vlastní konfigurační soubor a nespoléhat se na update-grub.

Nemáte na disku více oddílů s daty GRUBu (jako např. jeden na EFI oddílu a druhé na systémovém/bootovacím)?

Dle prvního <pre> to vypadá, že jste v emergency GRUB shellu (nebo jak se to jmenuje – prostě ten, který si nenačídá moduly z disku). V tom případě by mělo stačit přeinstalovat binárku GRUBU na EFI oddílu: grub-install --target=x86_64-efi --efi-dir=… --boot-dir=…, protože si GRUb hledá data jinde než by měl.

(Doporučuji mít EFI i boot adresář stejné, tj. instalaci GRUBU přímo na EFI oddílu. Můžete potom vyměnit systémový oddíl bez nutnosti reinstalace GRUBu.)

Jako „poslední“ možnost by mohlo jít použít grub-mkimage ručně a přibalit do obrazu GRUBu early config soubor, nebo ramdisk. To je spolehlivé řešení, ale ne zrovna nejjednodušší na pochopení. S EFI jsem to ještě nedělal. grub-mkimage je program, který vygeneruje binárku GRUBu, což by v případě EFI targetu měl být spustitelný soubor (u BIOSu z toho vyjde blob, který musíte umístit na daný offset na disku (pokud se nepletu, tak začátkem na 2. sektor)).

[k3dAR]

btw: uz ma vyreseno