Systemd boot, secure boot, Fedora

Naivan azt gondoltam, hogy szinte rutinból megoldom. Hát nem, ráment néhány órám, ezért itt hagyom az utókornak azt a hevenyészett, még csak nem is teljes jegyzetemet, amit utólag csináltam erről. Aztán majd írom a mesét is. :)

Forrás:

https://en.opensuse.org/Systemd-boot#Secure_Boot

Secure Boot

If secure boot is enabled, shim needs to be installed manually.
As shim only reads grub.efi, systemd-boot needs to be renamed
to pretend it's grub:

   # mokutil --sb-state
   SecureBoot enabled
   # mv /boot/efi/EFI/systemd/systemd-bootx64.efi /boot/efi/EFI/systemd/grubx64.efi
   # cp /boot/efi/EFI/fedora/shimx64.efi /boot/efi/EFI/systemd/systemd-bootx64.efi
   # cp /boot/efi/EFI/fedora/mmx64.efi /boot/efi/EFI/systemd/

The steps have to be repeated after every `bootctl install`

Továbbá:

   # efibootmgr -b 0 -B
   # efibootmgr -b 0 -c -l '\EFI\systemd\systemd-bootx64.efi'

Security violation kék képernyőnél hash visszaállítása az

EFI/systemd/grubx64.efi
EFI/systemd/systemd-bootx64.efi

file-okra.

Eddig a lényeg, akit érdekel a kerettörténet is, az olvasson tovább. :)

Egy Acer Aspire ES1, 11.6"-os notebook-on frissítettem Fedora 38-ról Fedora 39-re. Látszólag hibátlanul megtörtént minden, be is bootolt a frissítés után. Ekkor még szoktam neki mondani egy dnf check, majd egy dnf --refresh upgrade parancsot. Minden a legnagyobb rendben, persze nézzünk rá a kernelre is: 6.6.4-100.fc38. Mivanmivanmivan? :) Boot-olt a régi oprendszer kernelével. Á, mondom biztos csak a boot sorrend a grubban. Jó, reboot, nézzük a boot menüt!

Meglepetés, csak a régi oprendszer kernele van a menüben. Aztán észrevettem, hogy a /boot alatt csak a régi van, de /boot/efi/akárhol azért ott van a vágyott, Fedora 39-hez való kernel image is. És akkor most mi van? Nem ment sehogy sem, pedig új parancsokkal bővültek az ismereteim, mint például a bootctl. :)

Némi doksi olvasás után úgy döntöttem, felteszem a systemd-boot nevű szörnyet, hátha. Hát nem, a helyzet változatlan. Aztán kutatás neten, s akkor találtam erre az OpenSuse doksira. A saját jegyzetemben a file elérési utakat már Fedorához igazítottam, tehát nem elírás, hanem szándékos.

Arról van ugyanis szó, hogy secure boot csak a shimx64.efi által fog menni, gondolom, ez az az efi file, amely a szükséges digitális aláírással rendelkezik. Viszont a shimx64.efi csak a grubx64.efi file-t hajlandó hardcode-oltan behúzni, és ez az oka annak, hogy a systemd-bootx64.efi file-t át kell nevezni grubx64.efi-re, valamint a shimx64.efi-t ugyanabba az alkönyvtárba kell tenni systemd-bootx64.efi néven. Így az aláírással rendelkező shimx64.efi fogja behúzni a systemd-bootx64.efi-t, persze grubx64.efi néven.

Azért ennyire nem egyszerű, mert naná, hogy azt mondta, megsértettem a biztonságot, így a nagy EFI-s kék képernyőn navigálva ki kell törölni az általam jelzett két file hash-ét. Lehet, hogy elég lenne az egyiké, de ha így van, akkor épp a másikkal kezdtem, mert az egyik file hash törlés után még mindig nyafogott.

Ennek a kis gépnek szerintem nem egészen szabványos az EFI implementációja, például boot order változtatás után minden marad a régiben, s mindig a 0-ás bejegyzéssel boot-ol. Egyedül az ideiglenes next boot működik, tehát próbálgatni, tesztelni lehet, de a végén át kell írni a nullás bejegyzést arra, amit szeretnénk. Ezért van még a végén az a két efibootmgr parancs.

Most már működik, és végre a Fedora 39 6.6.8-200.fc39 kernelét húzza be. :)
 

( transitive | 2023. 12. 31., v – 12:48 )

Ezer éve Fedorás vagyok, de nem hoztad meg a kedvem a 39-esre való áttérésre. Undorító a szarakodás az aláírásokkal, és ami legjobban fáj, hogy már az embedded világba is kezd behatolni ez az egész... értem én az okokat (többnyire), de azért hányok tőle.

Nem tudom, mi az oka, de ez csak egyetlen gépnél jött elő, pedig másik kettőn is használok secure boot-ot. Ott belekerült a grub configjába a kernel, illetve a file-ok is a /boot alá kerültek közvetlenül. Szóval nem tudom, mi az oka, s ezért döntöttem úgy, hogy erre a rakoncátlan gépre felteszem a systemd-boot szörnyet, csak ahogy írtam, ez sem ment teljesen simán. Mindegy, most működik a gép, ahogy kell neki. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Bdede | 2023. 12. 31., v – 17:39 )

Szerkesztve: 2023. 12. 31., v – 17:43

A többi de jobb. A napokban felmerült egy distrokeresős topikban: a neve Devuan. Pár hónap használat után eszembe jutott, frissítek testingre.Tudom hülye vagyok, de én így szeretem. Már a frissítésnél sikoltozott hogy nem találja a nc.traditionalt. Aztán a rebootkor eltünt a grub menüből a Windoz, majd nem volt se wifi se bluetooth. A grubot sejtettem, kikommenteltem az osprobert. Nosza egy update-grub. Nem találja.

Egy ötlettől vezérelve elkezdtem keresni,  s láss csodát amiket nem talált (wifi firmware -t is) mind az /usr alatt van, persze a kis buta nem ott keresi. Átmásolom őket a volt helyükre. Van wifi, de su-ból az update-grub nem működik. A bekonfigolt sudo-ból igen.

Dev lista olvasgatás. Mivel a debián -mindent amiről úgy gondolják- áttesz a testingben a /bin, /sbin, /lib -ből a /usr/lib stb.alá, a devuan követi. Csak a konfig fájlok ezt nem tudják. Állítólag van egy usrmerge progi ami megoldja ezt. Ok . A distupgradenak nem kéne ezt felrakni, ha nem, akkor a változásokban nem kéne leírni. Elméletileg ez átfutott egy unstable részen. Ott senki?

Régen is szórakoztam a testinggel. Akkor az egy működő rendszer volt.

A régi jó dolgokból nem maradt semmi.

Persze. Nem is az a bajom, hogy volt egy verzió lépéssel, egy /usr -be migrálás. De valaki elfelejtette ezt betenni a dist-upgrade-ba, elfelejtette leírni a változásokban (pedig volt egyéb témákból vagy 6-8 ilyen irat). A dev lista alig mozog, pörgésnek nem merem írni. Az egyik panaszkodónak volt egy"hát tedd fel a... csomagot" válasz.

Régen azért ennél összeszedettebbek voltak.

Nem világos nekem ez a secure boot, olyan érzésem van, hogy nem valós problémát old meg, hanem ez annak lehetősége, hogy engem, vagy az általam használni kívánt operációs rendszert kizárja a gépemről.

Ha jobban belegondolok, a shim-x64 alá van írva a Microsoft kulcsával. Jut eszembe, a hardware-ek miért épp az MS kulcsát fogadják el? Aztán ez a shim-x64 berántja vagy a grub-ot, vagy a systemd-boot-ot, vagy lényegében bármit, ami már tudtommal nincs aláírva. Akkor meg hol van itt a biztonsági rés?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE