Vlákno názorů k článku
Debian nabídne v expertním režimu podporu systemd-boot od Libor - hmmm ... a je to dobře nebo špatně?...

hmmm ... a je to dobře nebo špatně? Vzpomínám si jak velký odpor a kontroverze přineslo před lety začlenění systemd do Debianu.....

Je to další možnost volby, což v princip zvyšuje svobodu uživatele.

Dokud si někdo neřekne, že už není třeba podporovat GRUB, protože přece máme systemd-boot.

Byvaly doby, kdy podobne vasne budila zmena z LILO na GRUB :-)

Jenže GRUB tehdy přinesl nebývalé možnosti proti LILO. Kdo z místních si pamatuje chybové kódy LILO?

A teď je otázka, jaké výhody má systemd-boot proti GRUB? Je to (r)evoluční krok jako lilo->grub? Nebo jen možnost volby? (Ptám se, systemd-boot neznám a proto nehodnotím.)

Vyhodou je zde jednoduchost. Na vetsine stroju v praxi nepotrebujete vsechny ty moznosti, co grub nabizi - jeho komplexita je zbytecna. A soucasne vam nic nebrani na UEFI systemech pouzit paralelne oboji (tedy jak grub, tak i systemd-boot), takze jako bonus muzete zvysit robusnost celeho boot subsystemu...

Grub se hlavně nejčastěji používá jako věc, kde se dá vybrat co se má spustit. Linux, Windows, staré jádro, nové jádro. UEFI tuhle funkci umí zcela nahradit. Už to není jen o tom, že se umí spustit zavaděč z prvního nebo druhého disku, ale i o tom, že se umí zavést konkrétní binárka na filesystému. Kdo nepotřebuje to, co nabízí Grub navíc, tak se pro něj stal zbytečným.

Tak pokud nepotřebuju všechny možnosti Grubu a ocením jednoduchost, tak můžu použít (a reálně spokojeně používám) CONFIG_EFI_STUB

presne to je ten problem. proprietarni uefi kam si vendor strka klice, navic je zhusta derave a na starsim hw bez moznosti opravy v poho nahradi grub, stejne jako nahradi rescue utility. Systemd-boot je cesta zpatky do toho proprietarniho pekla.

Moment, jaké mělo chybové kódy Li

L-I-L-O :-)

vyhody jsou primarne ne tim co systemd-boot umi, ale principem ze nahazuje jadro...

Grub 2 jeste nedavno neumel LUKS2, uz nejakou dobu ho sice umi, ale
neumi bootovat z (pro LUKS2) vychoziho argon2id ale musi byt pouzit pbkdf2,
z toho duvodu distribuce (nebo alespon co vim *buntu), pri instalaci
"celo"sifrovaneho disku, udelaji oddeleny=nesi­frovany boot oddil...

Grub sice podporuje LUKS(s omezenim vyse), MDADM, ruzne Filesystemy, ale
systemd-boot z principu kde jadro+initramfs je na EFI oddilu,
to vse podporovat vubec nemusi/nepotrebuje, protoze ten nahodi jadro
a to(pripadne s dopomoci initramfs) uz to vsechno nativne umi...

u Grub a nesifrovaneho /boot, i systemd-boot s nesifrovanym EFI,
jes ale moznost napadnuti utocnikem s fyzickym pristupem,
coz prave se s sicherboot/sbctl resi ve spojeni s tim ze v EFI nejsou MS
klice, ale uzivatele vlastni, tedy utocnik nema co podstrcit...
(kdyz neuvazujeme, rozebrani stroje a smazani CMOS ci preflashovani chipu,
aby se zrusilo zaheslovani BIOSu a vypnul SecureBoot, coz by slo asi
snadno resit, ze rootfs "si" to pohlida)

i s vlastnima klicema ma ale Grub minimalne 1 nevyhodu, ze nepodporuje AES
a pri zadani LUKS hesla mu to trva + je potreba samodomo poresit aby se nasledne
initramdisk uz neptal na LUKS heslo podruje, se systemd-boot tim ze se na LUKS
az prave initramfs, je AES podporovane nabehlym jadrem a pta se jen 1x...

dalsi nevyhoda Grub s LUKS, pri z bezpecnosti rucne poresenym sifrovanym boot
(at uz soucast rootfs s downgradovanym LUKS2 k pbkdf2, nebo oddelenym sifrovanym boot
kterej jen sam ma pbkdf2, ale rootfs uz argon2id), nelze pouzit remote LUKS odemceni
pres SSH, coz s systemd-boot staci mit v initramfs pripraven dropbear a authorized_keys,
idealne oklestene moznosti jen na pusteni unlock scriptu...

se systemd-boot si navic muzu k dropbear pridat nejaky dalsi script, co mi posle info,
kdyz by se stroj restartoval aby me upozornil ze nebezi a musim zadat vzdalene LUKS heslo...

navic se systemd-boot se da snadno (pres nastroj bootctl) urcit jaka polozka se ma pustit pri pristup startu, coz s Grub pamatuju ze ne vzdy dobre chodilo (mohla byt chyba na me strane, ale s bootctl mi to chodi vzdy...

Jo boot ze sifrovaneho disku pres GRUB je brutalne pomaly, chybejici HW podpora AES je hodne poznat. Stvalo me to az tak moc, ze jsem presel zpet na mene bezpecny nesifrovany boot, ktery az pres initrd namountuje sifrovany root.