Názory k článku Jak funguje a jak nastavit bootování aneb GRUB 1, 2, MBR, UEFI

> rotože to hardwarové menu má každý počítač jiné, a je složité nastavit timeout, která volba bude výchozí, nebo třeba jednorázově nabootovat bez obsluhy jinou volbu a když to selže, tak nabootovat předchozí.

Pôvodne som chcel autorovi napísať, nech si pozrie man efibootmgr, ako toto nastaviť; ale hneď v ďalšom odseku efibootmgr používa, takže zjavne o ňom vie.

A teda aj to, ako nastaviť timeout (Timeout), ktorá voľba bude predvolená (prvá v BootOrder), alebo ako jednorázovo nastaviť inú voľbu (BootNext).

Systemd má tiež jednorázovú špecialitu: systemctl reboot --firmware-setup. Rebootne počítač do nastavení BIOS-u (fičúra je UEFI only).

Používanie EFI boot managera namiesto grubu má pointu, v spojení so Secure Boot: nemení obsah PCR registrov. Takže ak sa nebootuje Linux, hash grubu neovplyvní výsledok keďže v reťazi kontrolovaných bináriek grub vôbec nie je a nie sú problémy s BitLockerom alebo niečim podobným, čo validuje PCR.

To môže byť výhoda aj nevýhoda (napr. so Secure Bootom a kľúčom k zašifrovanému disku v TPM je pre používateľa bezpečnejšie, aby bolo jadro+initrd+cmdli­ne podpisané MOK-om).

Je to však trocha iná vec, ako bola komentovaná. Zavedenie jadra takto napriamo je EFI Payload;, komentovaný bol EFI boot manager, ako nastaviť menu, kde sa vyberá systém na nabootovanie, pričom vybraný systém vôbec nemusí potrebovať grub (ako napríklad Windows).

To bude vendor-specific, na HP laptopech (Insyde BIOS) je UEFI boot menu pěkně použitelné, včetně editace command line a volby jiného initramfs.

Za me hodne jsem se toho dozvedel, i kdyz priznavam ze nektere pasaze jsou pro me uz hodne podrobne a preskocil jsem je. Jako dokumentace a manual pro nastaveni, havarii ap. skvele. Diky!

Děkuji za pěkný článek. Po dlouhé době něco co využiji.

Jinak jsem před pár dny řešil, jak bootovat Raid 1, tak aby to fungovalo i v případě, kdy se jeden ze dvou disků pokazí.

Udělal jsem to tak, že na obou discích jsem vytvořil UEFI oddíl. Debian ale nainstaluje grub jen do jednoho, takže do druhého se musí nainstalovat ručně a myslet na to, že v případě upgrade grubu by se to možná mohlo rozbít. Konfigurační soubor si to bere už z toho raidu a lvm, takže by se nejspíš muselo jednat o nějaké větší změny v samotném grubu.

Samotný grub podporuje boot z raidu i lvm, přihlouplý je jen ten bios, který potřebuje fat32 bez raidu. Takže se uefi boot oddíl musí ručně zdvojit, aby měl každý fyzický disk svůj, skopírovat obsah oddílu uefi boot a pomocí efibootmgr nastavit, aby to zkoušelo bootovat postupně z obou disků.
Další možnost je pomocí parametru doisntalovat grub i na druhý disk a pak už jen zkontrolovat pomocí efibootmgr -v, že to bude zkoušet bootovat z obou.

Presne na riešenie tohto problému má Proxmox nástroj proxmox-boot-tool; pre každý disk v ZFS poole vytvorí ESP partition a udržuje ich synchronizované pri každom update jadra.

Inak technicky je možné do UEFI doplniť podporu ďalších filesystémov, RAIDu, apod. UEFI má koncept ovládačov, FAT32 je minimum, čo musí podporovať každý. Napríklad niektoré dosky od Intelu podporujú NTFS, aj keď to povinné nie je.

netreba na to myslet, myslim ze v novejsi verzi Grub2 (ci v zavyslosti na maintaineru balicku) uz to nejak je, nicmene ja to uz pred casem poresil automatizovane tak ze pridal Grub hook/file: /etc/grub.d/99_syn­c_efi

s obsahem

#!/bin/sh
set -e
efi2="/boot/efi2"
efi2_uuid="EF02-EF02"
echo "Sync EFI to ${efi2} (${efi2_uuid})..." >&2
mkdir -p ${efi2}
mountpoint -q ${efi2} || mount /dev/disk/by-uuid/${efi2_uuid} ${efi2}
rsync -a --delete /boot/efi/ ${efi2}/


kdy pri kazde aktualizaci Grubu (ci neceho co update-grub vyvola) se syncne obsah efi primarniho oddilu do toho druheho (v skriptu definovaneho pres jeho uuid)

Ja spis nechapu, proc obsluha bootu/update sw raidu neni davno nejak implementovana...

To náhodou vím, protože jsi ji zatím neimplementoval. Nebo co podle tebe u opensource, tvořeního dobrovolníky znamená "není to dávno 'nějak' hotové"?

Nejsem si jist, že je to o OpenSource. Ta nedomyšlenost je v implementaci UEFI

Tady je to rozebrané:
https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/

Já tohle použil u nějakého SuperMicro serveru (ten raid1), ale u Dell serverů, které mi do té ESP zapisují jsem to nakonec zrušil, nechal ESP samostatně, a pořešil také synchronizací Unisonem.
Ten raid1 by byl nekonzistentní. Prostě se tady bohužel střetává UEFI close source s provozovaným OpenSource. Nejlepší by byla otevřená implementace UEFI, kam by to někdo do-implementoval. Anebo nějak pořešit, aby BIOS do té ESP fakt nehrabal. Já to tedy úplně detailně nehledal na R7515...

>Při startu počítače je potřeba nějak dostat do paměti linuxové jádro a
>initramdisk, předat mu parametry a spustit ho

V embedded systémoch som často mával jadro s boot kritickými ovládačmi v jadre a teda som nepotreboval initramdisk

Nejde jen o moduly, v initramfs se typicky (např. projekty genkernel, dracut) odemyká LUKS pomocí hesla nebo biometrie od uživatele a spouští různé bootsplash grafické ptákoviny. Můj initramfs má taky prázdný /lib/modules protože vše, co k bootu potřebuju, mám v jádře...

Tohle jsou uplne zaklady. Zajimavejsi by byl popis jak na UEFI rozbehat Secure boot ze zavedenim klice k sifrovanemu disku z TPM

Souhlasím, takový článek by byl moc fajn. Napíšete ho, prosím?

Nenapisu, protoze by me to naopak zajimalo.
Zatim nebyl cas to prozkoumat. A predevsim to asi nejde v dualbootu, kde Win vedle maji zapnuty bitlocker tim potrebuji TPM pro sebe.

není problém využiť libtpms či rovno swtpm

zajimavy clanek by to byl, ale jestli to chapu, tak tento postup znamena automaticke odemceni LUKS pokud se nezmeni HW, tedy odemkne to nezmeneny HW i kdyz se zmeni majitel (= nekdo mi vyplej NB ukradne ;-)

to ze to zamezi auto-unlock pri vyjmuti disku samozrejme chapu...

To ne, LUKS a SecureBoot jsou úplně nezávislé věci. SB odmítne boot když nesedí podpisy nebo jiné metriky, a teprve potom se předává řízení Linuxu s LUKSem. A tam záleží, co za threat model máte... většina řeší právě tu autentifikaci (jestli před počítačem sedí oprávněná osoba), takže chce heslo nebo nějaké další faktory.

Ale jinak LUKS (resp. obslužné skripty v initramfs) lze nastavit tak, že dostanou klíč z TPM a neinteraktivně ho použijí. To se hodí třeba u nějakého serveru, kde ani lokální terminál neexistuje, a naopak tu změnu hardwaru chcete hlídat (např. že si obsluha datacentra připojila něco).

ze je to oddelene vim, ja reagoval prave na "Secure boot ze zavedenim klice k sifrovanemu disku z TPM"

jinak ja prave pouzivam sicherboot (skripty nad systemd-boot) bez TPM, v UEFI smazane vendor klice, dane jen svoje, kterejma podepsana efi binarka co sicherboot sestavuje+pode­pisuje automaticky po aktualizace jadra z jadra+initrd+cmdli­ne

Aha, nedával jsem pozor :-)

Ty klíče ale taky bývají šifrovaný, ne? Měl jsem (v dobách před TPM) LUKS klíče na USB flashi, a k nim heslo v hlavě... takže to byl dvoufaktor, klíček a heslo.

Ještě doplňková poznámka: pokud z EFI bootmgr zcela vyhodíte Windows Boot Manager (bootuju přece jen ten debian) a máte tam dualboot (řešený grubem v debianu, tak při updatu Windows se chybějící Windows Boot Manager doplní a dá na první místo.
Windows Boot Manager tedy nesmíte smazat, jen debian dát na první místo, např.:
efibootmgr -o 7,0

Mám pocit, že nově přidaná položka se vždy nastaví jako default (víceméně to je logické - když instaluji nový systém, tak do něj pak chci nabootovat).

Je ale možné, že to má každý výrobce jinak - nezkoumal jsem to podrobně.

Jo, je to možný. A taky je možný, že jakmile pustím Windows a ony zjistí, že tam není jejich položka, přidají ji tam i bez aktualizací.
Like it or not, asi je to v pořádku, že si systém zajistí, aby vůbec šel znovu spustit.
Taky jsem to dál nezkoumal, stačilo mi zjištění, že Windows Boot Manager nemazat, jen změnit pořadí. To, zdá se, je celkem odolné.

Ďakujem za prínosný článok.

... a byly tam nějaké problémy s disky s velikostí nad 2 TiB.

Jen takovej "drobnej".. MBR ktera obsahuje PT+bootcode umi adresaci zpusobem, ze vice nez 2T tam nezadate ani pro offset ani pro velikost, takze nejvice skrze MBR lze zpristupnit 4TB disk jako 2T+2T partisny (ta druha zacina na poslednim 32bit adresovatelnem sektoru). Jen podpora v ruznych OS je ruzna, tento hack se nedoporucuje.

MBR pouziva LBA32, a vse co ma kapacitu >2TB pouziva LBA48.

Otázne je, kto bootuje z disku väčšieho ako 2TB. SSD v tejto veľkosti sú stále dosť drahé a rotačný disk na systém sa už dnes snáď nepoužíva.
Zistil som, že možnosť OS zasahovať do FW (teda primárne do UEFI) nie je až taká výhoda. Oddelenosť v BIOS+MBR mi vyhovovala viac.
Mám počítač, kde je na jednom NVMe disku (s MBR) Windows 10 a na druhom SATA SSD Ubuntu. Nepoužívam dual boot cez Grub, ten Linux využívam len občas, manuálne ho bootujem z UEFI.
Upgradoval som Ubuntu 20.04 na 22.04. Po upgrade som zistil, že Windows zmizli z UEFI a nedajú sa nabootovať. Problém bol našťastie len v tom, že ten upgrade vyhodil (v UEFI) disk na ktorom sú Windows, zo zoznamu bootovateľných diskov. Viem si ale predstaviť aj horši problém, keď systém na jednom disku pokazí bootovanie systému, ktorý je na úplne inom disku.

Super. Koukam, ze krome tradicne skvelych clanku Pavla Tisnovskeho se vraci na root.cz navody a postupy jak za starych casu. SUPER - jen tak dal :)

Díky za užitečný článek.

Máte někdo zkušenost jak pomocí GRUBu vyřešit bootování z image uloženého na serveru?

Ideálně tak, aby se teprve podle informace na serveru rozhodlo, jestli se dále zavede síťový image systému nebo se nabootuje lokální systém?

Rád bych měl možnost si na serveru zapnout, že stanice po spuštění nabootují systém ze sítě a vykonají akce, které jim určím.
Pak si stanice bude přes wake on lan a nechat je to udělat (typicky, automatizovanou obnovu image, antivirové testy, kontroly disků, ...)
Pokud bych to na serveru nenastavil, tak by stanice pokračovaly v bootu z lokálního disku.

GRUB by měl bootování ze sítě podporovat.
https://www.gnu.org/software/grub/manual/grub/html_node/Network.html

Cca před 10 lety, jsem to řešil přes generování a uložení zavaděče do bootromu síťové karty pomocí projektů:

https://web.archive.org/web/20170624003424/http://rom-o-matic.net/
a
http://etherboot.org/

Na serveru byl image s Tiny Core Linuxem (12MB image)
http://tinycorelinux.net/welcome.html
který si zavadeč stáhl přes HTTP GET

A v něm byl init script, který si stáhl přes ftp aktuální scripty a vykonal je.

Šlo tak pěkně vzdáleně obhospodařovat stanice i v případě, že tam byl úplně zbořený systém, nebo nový disk.

Nevim ted zda pres Grub, ale urcite by slo pres iPXE na serveru, stroje by meli vychozi boot PXE a na serveru bys jejich MAC priradil patricnou single-auto-boot polozku, bud boot next efi (ci legacy disk), nebo clonezilu co obnovi image, ci nejakej live s prirazenym tohle_udelej.sh skriptem

10. 9. 2022, 16:22 editováno autorem komentáře

Díky za tip. iPXE je vlastně nástupcem gPXE a ten vychází toho řešení co jsem použil před léty.

Říkal jsem si, že kdyby se dalo vyhnout hrátkám s bootromkou síťovek a pořešit stejnou funkčnost zápisem pár řádků do konfiguráku GRUBu, že by se mi to líbilo o trochu víc. I za cenu toho, že kdyby tam ten disk někdo zbořil kompletně, že bych tam musel s flashkou.

iPXE ale NEmusis flashovat do bootrom sitovky, lze jednoduse jako PXE "mezi-zavadec" kterej mas na serveru a pres dhcp&tftp ho poskytnes do site a stroje ho nactou ze sve bezne PXE rom

Aha, to už jsem zapomněl. Díky. Mrknu na to.