Názory k článku
Debian nabídne v expertním režimu podporu systemd-boot
-
L.Stříbrný podporovatelDokud si někdo neřekne, že už není třeba podporovat GRUB, protože přece máme systemd-boot.
-
-
DannyStříbrný podporovatelVyhodou 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...
-
VantomasStříbrný podporovatel
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.
-
EFI má shell, kde sa dá nájsť a vybrať súbor, s ktorým bude pokračovať bootovanie. Rovnako aj preskúmanie a nastavenie EFI premenných pred samotným bootovaním. Toto fakt nie je problém.q
Jediná výhoda GRUB, ktorá mi napadá je, že plus/mínus pozná rozličné súborové systémy, resp. iné blokové zariadenia ako čistú partition (napr. dmraid alebo btrfs/zfs pool a ich subvolumes). Cena za to je desná konfigurácia, nad ktorou si jednotlivé distribúcie stavajú svoj vlastný chlievik (a potom si Ubuntu dá natvrdo 30 sekundový timeout, ignoruje GRUB_TIMEOUT v /etc/default/grub a ani pánboh sa nevie dopátrať, prečo to robí).
-
Když koukám na https://wiki.archlinux.org/title/systemd-boot , tak mi formát konfigu systemd-boot a grubu nepřijde výrazně odlišný. A pro EFI ještě musím míchat dopředná a zpětná lomítka - ideální v tom udělat chybu, ani nevím, jak bych to napsal na anglické klávesnici v nějakém EFI shellu.
Ukládání kernelu a initramfs na EFI partišnu - to tedy vyžaduje, aby byla dostatečně velká. Při hraní s jádrem mám /boot aspoň půl giga a i tak se občas stane, že se zaplní.
-
k3dARStříbrný podporovatelvyhody 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=nesifrovany 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...
-
Proč by ne, je to skvělá věc. Každá změna se projeví okamžitě bez nutnosti generování čehosi v podobě update-grub etc.. Je to krok, který je správný. Používám to ve Fedoře, byť teda s nefunkčním secure boot. Tak snad brzy se i tohle povede dotáhnou do zdárné funkcionality, leč není tato funkce nijak kritická.
-
k3dARStříbrný podporovatel
pouzivam uz par let v Xubuntu, drive pres sicherboot, pak/ted pres sbctl + vlastni hook (vychazejici z toho co mel sicherboot) pri generovani initramfs a odebirani jadra
v sicherboot/sbctl se pripravuje do EFI oddilu 1 efi soubor/binarka co obsahuje kernel+initramfs+cmdline, pro kazde nainstalovane jadro, plus to podepisuje vlastnim klicem, nevim jak by to tedy bylo (spis s sbctl nez sicherboot kterej uz neni ve vyvoji) s jadrem co uz je podepsane MS klicema a ma tak zustal...
systemd balicek sice v 24.04 obsahuje hook systemd-boot kterej pouziva pro pripravu kernel-install, to ale hodi do EFI oddilu oddelene jadro a initramfs, navic sem si nebyl jistej (a nezkousel tim ze stejne pouzivam vlastni EFI klice :) zda pripravi vice nez jedno jadro, nebo jen vzdy to posledni...
-
Jan HrachStříbrný podporovatelTo je jako ptát se "co to GNU jeste bude vsechno delat?"
Tohle je úplně nezávislý kus softwaru na systemd jako správci služeb (podobně jako mnohé ostatní - systemd-timesyncd, systemd-resolved… - tady dokonce ani nemůže systemd nijak používat, protože se spouští ještě před tím, než vůbec nějaké systemd nastane - před bootem jádra).
4. 6. 2024, 23:02 editováno autorem komentáře
ČLÁNKY DO MAILU