Názory k článku EFIStub: startujeme linuxové jádro bez zavaděče GRUB

EFI partition používá FAT32, ne?

MP

To je (skoro) totéž. VFAT má navíc dlouhá jména.
Linux partition FAT32 označuje jako VFAT, Windows jako FAT32, ale je to taky VFAT.
Což neodpovídá na otázku, zda EFI spolkne dlouhá jména souborů: "the UEFI specification explicitly mandates VFAT support for the EFI partition".
LFN je tady s námi už hodně dlouho, bylo by dost divné, kdyby to EFI neuměl.

16. 6. 2026, 08:36 editováno autorem komentáře

Spis beru ze VFAT je hlavne driver, ne filesystem. Ten je bud FAT12, FAT16 nebo FAT32 (potazmo ExFAT) - navzajem nekompatibilni, lec podobne.

Je to označení extension pro FAT.

Ne.VFAT je FAT s extension pro dlouhá jména. Ta fungovala třeba i na FAT16 s VFAT extension.
Takže treba FAT16 může byt označení jako VFAT.

Ano, je to extension, které se objevilo pro FAT v NT 3.51 - příprava na W95 - kde se to poprvé dostalo k masám.
To je opravdu natolik dávno, že nás dnes spíš oprávněně překvapí, že by ve FAT nebyla LFN.

Neni to extension filesystemu (ve smyslu typickych extensions znamych napr. z EXT nebo jinych dospelych FS).

FAT FS totiz neobsahuje zadny feature bits, kde by bylo receno, ze "tenhle volume vyzaduje VFAT".

VFAT je zpusob prace driveru FS, v podstate na analogicke urovni jako UMSDOS pripadne UpFS - opt-in na per-directory bazi. U VFAT nejde jen o LFN, taky jde o case-aware a hlavne tedy Unicode support. Prava ale neumi.. na to je treba UpFS napr.

Je to tedy quirk v driveru FS, nebo extension driveru - ale ne samotneho FS.

Trochu mě překvapilo tvrzení že sw raid-1 ma poloviční rychlost zapisu nez samostatny disk. Myslel jsem že dnes v době SATA a nvme jde zapisovat na disky paralelně.

Samozřejmě že to platilo v době MFM, RLL, IDE a EIDE disků. A ani v té době to neplatilo pro SCSI disky. Dnes má mdadm RAID1 na SATA i nvme prakticky stejnou rychlost zápisu jako jeden disk a prakticky dvojnásobnou rychlost čtení.

Záleží, kde je bottleneck. Může se například stát, že narazíme na počet PCIe lanes, a místo x4 pojedou SSD v režimu x2 nebo x1. Pokud SSD jsou tak rychlá, že zvládla plně využít všechny lanes, pak toto násobně zpomalí jak čtení, tak zápis.

Mě to také překvapilo, když jsem to na tom serveru měřil. A nebylo to nějaké ořezávátko, ale výpočetní stroj na Gausian. Potřeboval jsem přesné číslo jako argumet proč dokoupit HW RAID řadič pro NVME disky.

Nemám žádné zkušenosti s Gausianem. Ale výkon, případně rozdíl může být velmi závislý na konkrétním hardware a workloadu.

Osobně mám RAID řadiče na systémový mirror spíš jako věc zjednodušení bootování, správy a zvýšení spolehlivosti při kritických situacích. Zjednodušení je jasné - nemusí se řešit synchronizace EFI oddílů po aktualizacích, předstírat, že mdraid oddíl je FAT32, řešit správné záznamy pro bootování v EFI vars.
U té spolehlivosti jde o to, že člověk pouze doufá, že UEFI firmware správně přeskočí, když nastane chyba na prvním disku atp. Těch druhů chyb disku může být celá řada a je tam spousta situací, kdy to při pokusech o čtení nebo zápis na nahnilý disk může selhat (např. systemd-boot / gummiboot standardně při každém startu mění random-seed v souboru na EFI oddílu).
HW řadič (nebo i nějaký polo HW RAID, jako Intel VROC/VMD) tohle řeší, protože když dojde k problému se zařízením, tak ho prostě od té doby úplně vyloučí ze všech následných operací.

Stran toho výkonu je to u mdraid mirroru obecně tak, že čtení se víceméně rozkládá na oba disky (čte bloky cik-cak jako při RAID0) a zápis je pak výkonově zhruba podle pomalejšího z těch dvou disku (lepší to být nemůže).
V HW raidu je základní princip mirroru stejný a platí i tahle obecná charakteristika, ale vstupuje do hry navíc dedikovaná cache, pokud je přítomná a v režimu writeback (většinou automaticky s baterkou/supercapem nebo vynucená, pokud to stojí za risk).
V případě, že systém vynutí stabilní zápis/pošle příkaz blok. zařízení, aby flushnul cache, tak to RAID řadič s writeback cache odbaví ještě předtím, než to zapíše do obou disků.
Podobně se pak chovají i lepší serverové SSD s PLP (power loss protection) - také většinou implementují okamžité potvrzení do systému, i když je to jen v jeho cache a teprve se to bude zapisovat do NAND pamětí (protože díky PLP dokáže garantovat že se cache dopíše i po výpadku napájení).
Nicméně ty interní cache na PLP SSD jsou v porovnání s HW RAID řadiči relativně malé (většina DRAM uvnitř je použitá na FTL mapu a jen malá část na data), ale i to může být někdy poznat.

Čímž se dostávám konečně k workloadu. Za normální situace, pokud aplikace používá klasické bufferované zápisy, spousty latencí "zahladí" page cache v systému. Potvrzené krátké zápisy až do hardware jsou pak víceméně jen operace s žurnálem.
Nicméně to se může zásadně změnit, pokud soubory otevře s příznakem O_DIRECT, O_SYNC nebo často sama flushuje přes fsync().
Takže u toho prvního typu přístupu je mdraid i s běžnými disky víceméně stejný jako dedikovaný RAID řadič. U toho druhého (což bývají typicky třeba databáze, virtuální disky atp.) se může projevit jak do jisté míry jak PLP, tak pak writeback cache na HW RAID řadiči.
Ale mluvím obecně z nasbíraných zkušeností, neznám přesný workload ani ostatní okolnosti u vás.

Noooo u SATA clovek narazi dost na limity serializace a ve scenarich pouziti kde je hodne kombo paralelni read-write, narazi na to ze SATA je half-duplex.
Takze bych radeji srovnaval jablka s jablky a ne hruskami :-)

Ohledne IPv6 pri NFS bootu, parametr ip= nepodporuje IPv6, samotny NFS mount snad ano. Problem je, jak tedy nakonfigurovat IPv6. :-)

Sam jsem to resil tak, ze mam pro initramfs (v Ubuntu) hook a skript pro konfiguraci IPv6. Nepodporuje tedy DHCPv6...
https://github.com/sixploy/netboot/tree/main/live-system/files/includes.chroot/etc/initramfs-tools

Taky jsem nechtěl řešit problémy s dalším operačním systémem, zbavil se Grub2 a EFI stub leta spokojeně používám.

Orientoval jsem se podle Gentoo Wiki, kterou ostatně řadím mezi nejlepší dokumentační počiny Linuxu vůbec.

btw: Měl jsem za to, že je EFI stub podporován jen na x86, ale vidím, že na aarch64 už taky.

Ten článek psala umělá inteligence nebo je to strojový překlad z nějakého infantilního webu?

To je bohužel správce z univerzity.

Správce z univerzity neznamená vysokoškolský profesor. A už vůbec to neznamená nadání pro psaní textu.

Na druhou stranu, ačkoliv je článek svým stylem pro začátečníky, sám jsem si v něm našel svoje a jsem rád za vhled do efistub.

Takže děkuji autorovi. A Jane, nenechej se zviklat a máš-li o čem psát, rád si přečtu i další článek.

A mohu se zeptat, v čem přesně máte s tím článkem problém?

Obsahově odpovídá mini-howto (byť trochu upovídaný), kdybych ho četl před několika lety, tak by mi ušetřil spoustu času hledání informací než jsem se svym kompem na EFIstub přešel, navíc je to věc, která odpovídá zaměření rootu ve zlaté éře...

M-n-ě článek přijde čtivý, plynulý. akorát nevysvětleno zůstalo add_efi_memap a ncp

MDRAID 1 s verzi metadat 1.0 by mel byt read-only citelny i pro software, ktery RAIDu vubec nerozumi, protoze ma hlavicku az na konci. Tudiz EFI ho precte a nabootuje jakoby tam RAID nebyl. Ale linux uz si s tim poradi. Jen je potreba to specifikovat pri vytvareni raidu. Defaultne je verze metadat 1.2.

Potvrzuji takto to použiváme u nás v práci na serverech.

Iba tak na okraj - GRUB je v konecnom dosledku tiez ovladany jednym suborom, nie nepodobne ako LILO. grub.cfg je v pohode editovatelny clovekom.

Sada skriptov, ktora ho zostavuje je len vecou automatizacie.

Ona ta modularita GRUB2 v podstate duplikuje featury ktere nabizi samotne UEFI prostredi.

Moc děkuji za článek, fakt parádní návod, určitě to vyzkouším i s tím provozem bez disku...

Hezké, leč osobně preferuji Unified kernel image:

ukify build -o linux.efi --linux=boot/vmlinuz-6.12.17-amd64 --initrd=boot/initrd.img-6.12.17-amd64 --cmdline='console=ttyS0,115200n8r console=tty1 root=/dev/nfs nfsroot=192.168.100.114:/srv/debian,rw ip=dhcp ---'

Výhodou je, že vytvoří jednu binárku, ve které je všechno. Není potřeba nijak konfigurovat EFI = stačí dát třeba na flashku do EFI/BOOT/BOOT­X64.EFI, nebo natáhnout po síti TFTP/HTTP bootem, nebo spustit v Qemu, a ono to Prostě Najede. Osobně takto mám záchranné OpenWRT", které si v EFI binárce nese initramdisk se shellem a nainstalovanými záchrannými programy (lvm, fsck…).

Nevýhodou samozřejmě je, že to je jedna binárka - obsah je v ní zapečený a nelze (snadno) měnit.

Zaprvé díky za článek, je to dobrý souhrn možností, jak s kernelem v EFI. Chyběla tam ještě tahle možnost jedné binárky s initrd, takže díky i za doplnění.

Pozn.: okolnosti u každého budou různě měnit, co je výhod a nevýhoda, takže je dobré znát co nejširší paletu možností, a proto je skvělé to mít tady na jednom místě.
(Např. my používáme neměnnost té binárky jako výhodu...)

Nebylo by místo toho NFS praktičtější, zapéct ten systém do té image a potom ji jen rozkopírovat tam, kde předpokládám, že to použiju? To by se mohlo tak do 1GB asi vejít.

a to jsem měl před 15lety (bez úkáčify) .... vím že jsem měl akademický cíl obejít se bez initrd a i bez bootmanageru. tehdy byly začátky uefi a to jsem si řekl že uefi se hodí k eliminaci bootmanageru.
tedy je tohle cesta jak mít root na ext4fs, obejít se bez manageru i bez initrd?(a UK-if:y je jen nástroj/konkr­.implemenace ) i když initrd je věc komplikovanosti stroje/setupu: jedno ovlivnuje druhé : proto žádný lvm ani řadiče

jednoduchost plodí jednoduchost.

> Jádro je totiž stále větší a větší.

Ve skutečnosti není problém s jádrem*, které má kolem 10 MB, ale s velikostí initramdisku. Ten má na posledních Debianech klidně 120 MB a je to úplně absurdní. Nežere to jenom místo, ale na některých EFI to strašně pomalu bootuje - jako kdyby měly ne úplně rychlé čtení. Identifikoval jsem, že k tomu přispívají dvě věci:

1) v /etc/initramfs-tools/initram­fs.conf je defaultně nastaveno MODULES=most. To způsobí, že se do initramdisku přibalí například všechny ovladače všech síťových karet a firmware pro nich, kdybyste náhodou bootovali po síti - což téměř jistě nebude váš případ. Řeší se změnou na MODULES=dep. Pozor, že u jednoho podivného setupu nám tohle nepřibalilo modul pro nvme; nikdy jindy s tím ale problém nebyl.

2) Do initramdisku se z mně nepochopitelného důvodu balí např. AMD GPU a nVidia ovladače a firmware. A to i na počítačích, co tento hardware nemají. Kde se vůbec vezmou? Typicky tak, že někdo nainstaloval metabalíček firmware-linux-nonfree, který je přitáhl (typicky kvůli wifi, ale to stačí nainstalovat např. balíček firmware-iwlwifi nebo firmware-atheros dle výrobce wifi karty).

Tyhle problémy profiluji tak, že initramdisk rozbalím

unmkinitramfs /boot/initrd.img-6.1.0-18-amd64 /tmp/někam

a následně na pustím ncdu a velikosti souborů si projdu (není to úplně přesné, protože obsah initramdisku je komprimovaný, a toto nebere v potaz kompresní poměr, ale v praxi to je dostačující).

* velikosti jader posledních verzí Debianu:

Debian 10:
5.3M vmlinuz-4.19.0-17-amd64

Debian 11:
7.0M vmlinuz-5.10.0-19-amd64

Debian 12:
8.3M vmlinuz-6.1.0-40-amd64

Debian 13:
13M vmlinuz-6.12.63+deb13-amd64

V pripade ze initrd ma 100+ MB tak bych zvazoval nejaky mensi RO ext4 jako /preboot partisnu, ale porad nam chybi moznost primeho chroot= abychom se initrd mohli zbavit nadobro

(to resi problem rychlosti - co se tyce mrtveho kodu pro loading a dekompresi)

17. 6. 2026, 15:27 editováno autorem komentáře

Ale to má jednoduché řešení - mít kernel se zakompilovanou podporou řadiče, disku a FS. Pak přeci initrd nepotřebuješ.

Pro většinu použití ano, ale třeba encrypted root je dost častý protipříklad, kterej pokud se něco nezměnilo bez ramdisku nejde řešit.

Tak treba v Gentoo, je ten initrd udelanej pres genkernel tool malej OS, kterym si opravite prave to, kdyz vam selze vas predpoklad "se zakompilovanou podporou řadiče, disku a FS".

V 99% pripadech to nepotrebujete, ale to 1% je porad pohodlnejsi resit skrze vestaveny shell, nez nekde stahovat, hledat medium a delat Live USB klic.

sice na to upozornujete ale nemáte tam i tak chybu? Mimojiné jsou míchané dva typy uvozovek
" co vytvořil GRUB – /boot/efi/EFI/de­bian, bude náš příkaz vypada takto:"
efibootmgr -c -g -L "nas EFIStub" --disk /dev/nvme0n1p1 -l '/EFI\debian\vmli­nuz' -u "root=UUID=7a62971d-be7a-4e64-847f-875cba948e47 rw quiet add_efi_memmap initrd=\\EFI\\de­bian\\initrd.im­g"
To escapování je trochu zvláštní, je na to třeba pamatovat. Sám jsem na to přišel metodou pokus-omyl.
Myslím parametr -l a subparametr initrd=.

článek je skvělý , čte se hezky!