Názory k článku Zavaděč už nepotřebujeme, startujte rovnou jádro, říkají vývojáři Red Hatu

Ramdisk totiž není podepsán a není tedy ani kontrolována jeho důvěryhodnost.

s systemd-boot
jadro+initram­fs+cmdline je sloucene do 1 EFI binarky ktera je podepsana
= tedy v podstate UKI, ktere chce vyuzivat NMBL...

btw: userspace pro spravu systemd-boot je bootctl

On EFI snad také neobsahuje diskové ovladače, ovladače sítě nebo filesystému a také s tím spojené chyby? Začal bych už zde...

Vsak to take existuje - viz treba coreboot...

Výše popsané používám (uki) už několik let na notebooku a nikdy za tu dobu mi komplexní zavaděč typu grub nechyběl. Ale jedná se o moji konfiguraci na jednom konkrétním hardware, proto by mě zajímalo, jak moc dobře jim to bude fungovat.

No napriklad moj UEFI nepodporuje PCI NVMe disky. A ked som si ho zaobstaral tak jedina mozna konfiguracia bola nechat tam stary disk, tam dat GRUB a az odtial potom spustat kernel z NVMe disku. Bez toho by to neslo aj ked samozrejme je to dost exoticka konfiguracia.
Pre mna je otazka opacna, preco nie GRUB? Funguje to, zdrzanie pri boote minimalne, moznosti bootovania vylepsene.

Nejde tam předhodit jádru nějaké parametry? Ptám se, v tomhle se vůbec neorientuji.
To vážně nejde bootovat z PCIE paměti?

Viděl jsem nějaké parametry pro NVME disky, které opravovaly režim probuzení.

19. 7. 2024, 14:03 editováno autorem komentáře

Samozrejme ide, ale môj BIOS a UEFI to nevidí. Proste staré železo

V niektorých prípadoch tam ide podpora NVMe diskov backportnúť UEFIToolom a flashnutím modifikovaného obrazu. Pár rokov dozadu som to úspešne zrealizoval na Optiplexe 7010 podľa postupu odtiaľto:

https://www.tachytelic.net/2021/12/dell-optiplex-7010-pcie-nvme/

Chybi mi tu informace, co jeste nefunguje (zajimala me predevsim podpora LUKS), takze pridavam info ze zminovaneho blogu:

- Network booting: http(s), PXE/tftp
- Network storage booting: NVMe over network, iSCSI, etc.
- TPM support
- Encrypted LUKS disk support
- LVM
- Fallback

No jelikoz to budou rvat jako prvni "logicky" na Fedeoru.
Nejak jsem nepochopil jak to bude delat multi boot.. Grub menu je tu zmineno jen kvuli jinym verzim jadra...

Multiboot bude dělat EFI, teoreticky v něm může být nakonfigurováno neomezeně zaváděných systémů a/nebo jader (uki). Ve skutečnosti lze přes EFI zavádět přímo jádro systému i se zapsanou command linou pro jádro a cestou k initramdisku.

Jak už bylo řečeno, multiboot zvládne i samotné UEFI. Spíš mne, coby vývojáře a hračičku, znepokojuje otázka, jak to řeší možnost ručně upravit command line pro konkrétní boot. Podle toho popisu mi to vyznívá, že odpověď je: "To se neřeší, protože to je špatná věc, kterou nemáte chtít. Celý proces bootu má být vytesaný do skály a zasáhnout do něj má být co nejtěžší."

"Ty (housle) už jsou naladěný z továrny, na ty nešahejte." :)

V článku se zmiňuje možnost použití grub-emu, který pak editaci cmdline umožňuje, pak by se mělo přes kexec dát zavést jádro s jinými zadanými parametry.
Ale na projekt jsem se ještě nedíval, tak nevím jak je to přesně technicky řešené. Jestli se pak fakticky část toho GRUBu, kterého se vlastně chtěli zbavit, nemusí pro tuhle možnost nějak zapéct do každého UKI.
Nebo to bude někde vedle a pak to bude krom připojeného EFI oddílu s UKI potřebovat ještě klasicky přístup do /boot oddílu, kde pak bude ještě normální GRUB (moduly, témátka), čímž zas trochu padá ta jedna podepsaná binárka.

Tak na první pohled to vypadá, že půjde o první zmíněnou možnost, dracut ty potřebné části zapeče do initrd a celé to pak skončí v UKI.

Nejen binárka, ale i bezpečnost.

UEFI samo o sobě to zvládne. Ale minimálně uživatelská přívětivost na stávajících strojích je nula. Ale fair enough, na servery asi dobrý. Na desktopu/notebooku, obávám se, zůstanu u grubu nebo nějaké podobně použitelné alternativy z tohohle důvodu ještě hezky dlouho.

Napr. ten mnou vyse zminovany systemd-boot:

- pokud mas zaplej secureboot, logicky upravit nejde (protoze cmdline je soucast te 1 binarky ktera je podepsana a podpisem je tedy chranen i puvodni cmdline)

- pokud mas vyplej secure boot, cmdline upravis pres hotkey podobne jako to ma grub

"GRUB ... Vedle toho potřebuje také podporu více jazyků, fontů nebo rozložení
klávesnic."
Opravdu potřebuje? "Běžný" uživatel do bootu stejně nikdy nezasahuje, jelikož
to neumí (a většinou se toho i bojí). Kdo umí, tak umí i anglicky, přečíst
default-font a použít klávesnici en-US. Z takových zbytečností pak resultují
i hory různých balíčků a jejich součástí ve většině "hlavních" distribucí pro
stovky obskurních jazyků, jejich charsetů a klávesnic instalované defaultně;
mnohdy kvůli závislostem a zakomponovanostem bez možnosti deinstalace,
takže se talový balast i stále aktualizuje a zdržuje. Viz např. kopce hnoje
v /usr/share/locale (RH-like), ale i jinde.
Omluva za off-topic.

Podpora jiného rozložení klávesnice se hodí pro odemykání LUKS - číslice jsou jinde, speciální znaky taky, y/z...

Ano, můžu si vymyslet heslo, které bude na všech klávesnicích stejné, ale pak nebude tak komplexní a dobře použitelné

No, já nevím, ale já naopak před zadáváním jakéhokoli hesla kontroluji, jestli náhodou není zapnutá česká klávesnice, a mám-li nějaký problém, tak právě s tím, že omylem zůstala zapnutá.

To děláte špatně. Jak v heslu není nějaká diakritika, japonský znak a pár smajlíků, tak to není správné heslo.

Když vezmu v potaz azerty a dvorak, tak jediné heslo, které bude na všech klávesnicích stejné, je posloupnost několika mezer.

@s6c [/usr/share/lo­cale]

Chtel sem napsat jen localepurge
Ale zda se ze to jen pro deb-like :⁠-⁠)

Prijde mi to cele jako nesmysl. Nic zasadniho to neprinasi akorat to prinese spoustu problemu. Je to blby, to se bude libit…nekdy si rikam, ze lidi v RH by meli obcas vytahnout hlavu z kancelare, zajet nekam do firem a zjisti co zakaznici chteji misto vymysleni veci ktere nic neprinasi.

Ale RH samozřejmě se svými (!) zákazníky mluví. A v současné době často slyší třeba právě o Secure boot, Secure supply chain, Common criteria a FIPS.

Nedělejte tu chybu, že svoje požadavky začnete považovat za to, co chce celý průmysl a firmy různých velikosti.

Aktivita upstreamu je další faktor (jak článek taky zmiňuje)

Ja pozadavky nemam, mame zakazniky z oblasti enterprise v automotive, defense, retail, online retail, pharma a vicemene vsichni rikaji ze redhat jiz nesplnuje jejich ocekavani, tak uvidime jak to dopadne.

A kdo splňuje jejich očekávání? A co jsou vlastně jejich očekávání?

Oracle linux, který to přebírá ale z RH. To není sranda, ale opravdu tak tihle zákazníci se chovají.

RH očekávání nesplňuje hlavně cenou.

Pohled konzervativního staromilce usera:
Lilo - ok, má to své mouchy ale funguje to.
Lilo - RIP - Long live the GRUB!
zatr. Grub to je zase problémů, to zase měl někdo VIZI
ok, dva za ty dva roky už Grub funguje obdobně jako lilo
GRUB - RIP. Long live nmbl! (To zase někdo má VIZI)
co bude následovat?

Ještě bych to rozdělil na grub1 a grub2, a mezi grub2 a nmbl přidal systemd-boot. A pak pár lidí používalo i syslinux nezávisle během celé životnosti lila a grubu.

Ta hruza, ze si nekdo firewallovy subsystem v Linuxu dovolil z ipfirewallu posunout k ipchains, nasledne k iptables... abysme dnes meli nftables :D V realu dnes casto, i kdyz si myslite, ze pouzivate iptables, realne bezite nad nftables. Jen se o nektere veci ochuzujete, protoze ten tooling proste resi jen zpetnou kompabilitu - a nikoliv nove funkce (treba fastpath).

Ono by bylo docela smutné, kdybychom to po více než dvaceti letech vývoje, kdy máme spoustu nových možností, neuměli udělat lépe.

LILO a Grub jsou z doby, kdy UEFI v PC nebylo. Vznikly za jiným účelem a dneska už jsme prostě dál a tak to chce udělat trochu krok stranou.

Ono je to vsetko krasne ked to funguje. Ale ked sa nieco pokazi, este za Grub 2 bude vela ludi plakat.

Pokazit se umi i Grub2 :-) Kdyz uz teda chcete nutne mluvit o nejakem placi.

Tj, ta legrace kdyz mkconfig generuje vadnej konfigurak, coz se projevi az pri rebootu, kdy to nenastartuje. Pripadne kdyz grub ignoruje nazev/id partysny, a leze na ni pres hinty, ktere nelze nikde vypnout (leda expost vzdy odmazat). To je taky uzasna zabava.

Prakticky to UEFI umi, ale spise pak lidi daji maly image s GRUBem do UEFI - nebot tomu rozumi vzdy, linuxovemu kernelu a predavanim parametru uz rozumet nemusi.

Osobne jsme radeji, kdyz mam kernel a initramdisk nekde v linuxu nez v nejakem BIOSU s UEFI, ke kteremu ma pristup CIA/NSA a kdo vi kdo jeste, ona ma treda pristup i k CPU v bezicim linuxu, ale tam neco dojebat neni tak easy, jako v UEFI, kde mi klidne podstrci jiny kernel ani nemrknou.

To mate jak s Unixy a jejih obdobou bootvani z nejakeho FW, ktery byl i na siti, zaroven je to vzdalena sprava a z poctaky tam dost sr* na nejake zabezpeceni a sifrovani a kdo to nemel oddelene na siti pres VLANy nebo specialni switche se vystavoval slusne sanci na hack + tomu v te dobe nikdo nerozumnel, tak nechali defualt hesla a tak ... casto telnet, takze kdo sniffoval sit mel vse potrebne ... tak nejak bios neupdatujeme tak casto, tak bych mu moc neveril, krom toho je closed source, tak nikdo nevi, co vse tam je.

Pak jsou lidi jako ja, kterym fedora nicila boot a nesel dat zpet, presneji sel, ale musel jsme dat nejaky legacy mod a to rucne , nebot pry na 64bit nepodporuje stary legacy boot ... ano to presne mam, neni easy zmena legacy bootu na UEFI, chce to predelat part, vytvorit nove specialnim zpusobem a pak to predelat rucne ... slo by to, ale proc to delat, mam UEFI bios a tam mam povolit legacy boot - mam SSD disk a tam je OS jeste z dob neexistnece UEFI - ano 2x vymeneny HW a porad stejny linux ;-) - jen prehodim disky, grafiku, 10Gb LAN a jedu dal ... tedy GRUB nitne potrebuji.

YEP pokud bych dal neco do UEFI a startoval to cele z tama, tak asi OK, jen jak rikam, neverim UEFI a asi by se tam tolik kernelu neveslo, takze spise zase image s GRUB co saha na disky