• När Linux och Secure Boot måste byta nyckel

    När Microsofts äldre Secure Boot-certifikat från 2011 löper ut behöver Linuxvärlden ta nästa steg i övergången till en nyare signeringskedja. För de flesta användare sker förändringen i bakgrunden, men för Linuxdistributioner, installationsmedia och äldre datorer kan den bli avgörande. I grunden handlar det om något så enkelt – och viktigt – som att datorn måste lita på rätt nyckel för att Linux ska kunna starta säkert.

    En gammal digital nyckel från Microsoft är på väg att gå ut. Det låter kanske som en teknisk detalj för firmware-utvecklare, men förändringen berör stora delar av Linux-världen. Orsaken är Secure Boot – den säkerhetsfunktion i moderna datorer som kontrollerar att rätt programvara startar när datorn slås på.

    I juni löper Microsofts äldre UEFI CA-certifikat från 2011 ut. Det certifikatet har under många år varit en viktig del av kedjan som gör att Linuxdistributioner kan starta på datorer där Secure Boot är aktiverat. Nu behöver Linuxdistributionerna stegvis flytta över till den nyare Microsoft UEFI CA från 2023.

    För vanliga användare innebär detta oftast ingen dramatik. En dator som startar Linux med Secure Boot i dag bör normalt fortsätta att starta även efter att det gamla certifikatet gått ut. Men övergången är ändå viktig, särskilt för nya installationsmedier, räddningsskivor, dual boot-system och äldre datorer.

    Vad är Secure Boot?

    Secure Boot är en säkerhetsfunktion i UEFI, den moderna ersättaren till det gamla BIOS-systemet. När datorn startar kontrollerar firmware att den första delen av startkedjan är signerad med en betrodd digital nyckel.

    Man kan jämföra det med en dörrvakt vid datorns entré. Dörrvakten släpper bara in program som kan visa upp rätt legitimation. Om startprogrammet är signerat med en nyckel som datorn litar på får det fortsätta. Om inte, stoppas uppstarten.

    Syftet är att hindra skadlig kod från att lägga sig tidigt i startprocessen, innan operativsystemet ens har hunnit laddas. Sådan kod kan annars vara mycket svår att upptäcka.

    Varför fungerar Windows enklare?

    På de flesta vanliga PC-datorer finns Microsofts Secure Boot-nycklar redan inlagda från fabrik. Det gör att Windows kan starta utan extra krångel, eftersom datorns firmware redan litar på Microsofts signering.

    Linux har däremot ett annat problem. De flesta Linuxdistributioner är inte direkt betrodda av datorns firmware. Tillverkaren av datorn har normalt inte lagt in nycklar för Ubuntu, Fedora, Debian, Linux Mint eller andra distributioner.

    För att lösa detta använder många Linuxdistributioner ett litet program som heter shim.

    Shim – den lilla länken mellan Microsoft och Linux

    Shim är en liten första startladdare som fungerar som en bro mellan datorns Secure Boot-system och Linuxdistributionens egna nycklar.

    Så här fungerar det förenklat:

    Datorns firmware litar på Microsofts nyckel.

    Microsoft har signerat Linuxdistributionens shim.

    Firmware startar shim eftersom signaturen är betrodd.

    Shim kontrollerar sedan nästa steg, till exempel GRUB och Linuxkärnan.

    GRUB och kärnan kan därefter starta Linux på ett säkert sätt.

    På detta sätt kan Linux starta på datorer där Secure Boot är aktiverat, utan att varje enskild datortillverkare behöver lägga in nycklar för varje Linuxdistribution.

    Vad händer när 2011-certifikatet går ut?

    Det viktiga att förstå är att ett utgånget certifikat inte automatiskt betyder att allt slutar fungera. Certifikatet tas inte magiskt bort ur datorns firmware bara för att datumet passerar. Redan signerade och betrodda startladdare bör därför i många fall fortsätta fungera.

    Det betyder att en befintlig Linuxinstallation, som redan fungerar med Secure Boot, normalt inte bör sluta starta enbart på grund av certifikatets utgångsdatum.

    Problemen kan i stället uppstå i samband med övergången till den nya signeringskedjan. Nya installationsavbilder, nya versioner av shim, återställningsmedia och vissa äldre datorer kan behöva uppdaterade Secure Boot-databaser för att känna igen den nya Microsoft UEFI CA från 2023.

    Varför kan det ändå bli problem?

    Secure Boot bygger på en kedja av förtroende. Varje länk måste lita på nästa länk. Om datorns firmware inte känner igen den nyckel som har använts för att signera shim, stoppas processen redan i början.

    Då spelar det ingen roll att Linuxkärnan eller GRUB är korrekt installerade. Om första länken i kedjan inte godkänns kommer datorn inte vidare.

    Särskilt känsliga situationer kan vara:

    Äldre datorer med föråldrade Secure Boot-databaser.

    Nya Linuxinstallationsmedier som använder den nya 2023-signeringen.

    Dual boot-system med både Windows och Linux.

    Räddnings-USB och installationsstickor som inte har uppdaterats.

    System där användaren manuellt har ändrat Secure Boot-nycklar.

    Datorer där den gamla 2011-nyckeln tas bort för tidigt.

    Det sista är särskilt viktigt. Att manuellt ta bort gamla nycklar ur Secure Boot-systemet kan göra att tidigare fungerande Linuxinstallationer inte längre startar.

    Vad behöver Linuxdistributionerna göra?

    Linuxdistributionerna behöver se till att deras shim-versioner signeras på rätt sätt för framtiden. Det innebär att de måste anpassa sig till Microsofts nyare UEFI CA från 2023 och se till att installationsmedia, uppdateringspaket och dokumentation följer med i övergången.

    För stora distributioner som Ubuntu, Fedora, Debian, SUSE och andra är detta en viktig infrastrukturell förändring. Det handlar inte om en ny funktion som användaren direkt ser, utan om att själva startkedjan ska fortsätta fungera på moderna datorer.

    Det är lite som att byta låssystem i ett stort hus. De flesta märker ingenting om bytet görs rätt, men om nycklarna inte passar kan någon plötsligt stå utanför dörren.

    Vad bör vanliga användare göra?

    För de flesta användare är rådet enkelt: håll systemet uppdaterat.

    Installera uppdateringar från din Linuxdistribution.

    Uppdatera shim-paket när distributionen erbjuder det.

    Installera firmware- och UEFI-uppdateringar från datortillverkaren när sådana finns.

    Använd nya installationsavbilder från distributionens officiella webbplats.

    Undvik att manuellt ändra Secure Boot-nycklar om du inte vet exakt vad du gör.

    Det är också klokt att inte använda gamla installationsstickor i flera år. Om du ska installera Linux på en ny dator med Secure Boot aktiverat bör du ladda ner en aktuell ISO-fil från distributionens officiella webbplats.

    Secure Boot är inte bara ett Windows-problem

    Det här visar också hur beroende Linuxvärlden fortfarande är av Microsofts roll i PC-ekosystemet. Även om Linux är ett fristående och öppet operativsystem måste det ofta passera genom en Microsoft-signerad startkedja för att fungera smidigt på vanliga konsumentdatorer med Secure Boot.

    Det betyder inte att Linux är osäkert eller underordnat Windows. Det betyder snarare att PC-plattformen historiskt har standardiserats kring Microsofts nycklar, eftersom Windows dominerar marknaden.

    Linuxdistributionerna har därför byggt praktiska lösningar för att fungera inom detta system. Shim är en sådan lösning.

    Ingen panik – men en viktig övergång

    Att Microsofts UEFI CA från 2011 löper ut är inte en katastrof. Det betyder inte att Linuxdatorer plötsligt slutar starta över en natt. Men det är en viktig övergång som Linuxdistributioner, hårdvarutillverkare och systemadministratörer behöver hantera på rätt sätt.

    För användaren är det viktigaste att inte göra förhastade ändringar i Secure Boot-inställningarna. Låt distributionens uppdateringar sköta övergången, använd aktuella installationsmedier och se till att firmware hålls uppdaterad.

    Secure Boot handlar i grunden om förtroende. När en gammal nyckel går ut måste en ny ta vid. Om kedjan hålls obruten kommer Linux fortsätta starta precis som tidigare – bara med en modernare grund för framtidens säkra uppstarter.

    https://github.com/rhboot/shim

    Faktaruta: Secure Boot och Linux

    Secure Boot är en säkerhetsfunktion i moderna datorer som kontrollerar att startprogrammen är betrodda innan operativsystemet får starta.

    Många Linuxdistributioner använder ett litet program som heter shim. Det fungerar som en bro mellan datorns firmware, Microsofts Secure Boot-nycklar och Linuxdistributionens egna nycklar.

    Microsofts äldre UEFI CA-certifikat från 2011 löper ut, vilket gör att Linuxdistributioner behöver gå över till den nyare signeringskedjan från 2023 för framtida stöd.

    • Påverkar: Linuxinstallationer med Secure Boot aktiverat.
    • Viktig del: shim, GRUB och Linuxkärnan.
    • Risk: äldre installationsmedia och datorer med föråldrade Secure Boot-nycklar.
    • Råd: håll Linux, firmware och installationsmedia uppdaterade.
    • Undvik: att manuellt ändra Secure Boot-nycklar om du inte vet exakt vad du gör.
  • KaOS Linux 2026.03 – ett steg mot ett systemd-fritt Linux

    KaOS Linux fortsätter att utmana etablerade normer i Linuxvärlden. I marsutgåvan 2026.03 tar distributionen ytterligare steg bort från systemd genom att ersätta centrala komponenter och införa nya tekniska lösningar. Resultatet är ett djärvt experiment i hur ett modernt operativsystem kan byggas utan en av dess mest dominerande byggstenar.

    Den senaste versionen av KaOS Linux (2026.03) visar tydligt att projektet fortsätter sin resa bort från systemd. För många användare är detta en ganska osynlig förändring – men i Linuxvärlden är det en stor och principiell fråga om hur operativsystem ska byggas upp.

    KaOS är en självständig distribution som använder pakethanteraren pacman från Arch Linux, men den följer sin egen tekniska och ideologiska väg.

    Vad innebär förändringarna?

    Utvecklarna har fortsatt att plocka bort komponenter kopplade till systemd. Målet är att skapa ett system där varje del är mer fristående och enklare att kontrollera.

    I denna version har flera viktiga förändringar genomförts:

    • Bootloadern systemd-boot har tagits bort helt
    • Ny standard-bootloader är Limine
    • Installationsprogrammet Calamares erbjuder inte längre systemd-boot som alternativ

    Bootloadern är det första som körs när datorn startar. Genom att ersätta den tar KaOS ytterligare ett steg bort från systemd-ekosystemet.

    Ny hantering av uppstarten

    En annan viktig förändring är bytet av verktyg för att skapa initramfs – den miljö som laddas allra först vid uppstart.

    • mkinitcpio har tagits bort
    • Dracut används istället

    Detta är inte bara ett tekniskt byte, utan resultatet av flera års arbete. Utvecklarna har även behövt anpassa systemet för att fungera i live-läge, vilket gör förändringen extra komplex.

    Ny skrivbordsmiljö och modern teknik

    Redan i tidigare versioner valde KaOS att lämna KDE Plasma efter mer än ett decennium.

    I stället används nu:

    • Niri – en modern tiling-fönsterhanterare
    • Noctalia – ett nytt skrivbordsskal byggt på Qt

    Detta innebär en tydlig förändring i hur användaren arbetar, med större fokus på effektivitet och tangentbordsstyrning.

    Målet: ersätta systemd

    Alla dessa förändringar pekar mot ett större mål – att ersätta systemd med Dinit.

    Init-systemet är centralt i Linux. Det ansvarar för att starta tjänster och hantera systemets grundfunktioner. Medan systemd är standard i de flesta distributioner, vill KaOS visa att det går att bygga ett fungerande system utan det.

    Uppdaterade komponenter

    KaOS Linux 2026.03 bygger på moderna versioner av centrala delar:

    • Linux kernel 6.19
    • Mesa 26
    • Wayland 1.25

    Dessutom ingår uppdaterade applikationer som:

    • Mozilla Firefox
    • Google Chrome
    • LibreOffice
    • GIMP

    Varför är detta viktigt?

    För slutanvändaren kanske skillnaden inte märks direkt. Men bakom kulisserna handlar det om något större:

    • Hur komplext ett operativsystem ska vara
    • Hur mycket kontroll utvecklare och användare har
    • Om alternativa lösningar kan konkurrera med etablerade standarder

    KaOS fungerar här som ett experiment – en testbädd för idéer om hur Linux kan byggas på andra sätt.

    Slutsats

    KaOS Linux 2026.03 är inte bara en vanlig uppdatering. Det är ett tydligt steg i en långsiktig strategi att skapa en systemd-fri Linuxdistribution.

    Om projektet lyckas fullt ut är fortfarande en öppen fråga. Men det visar att Linuxvärlden fortfarande är dynamisk – och att även grundläggande delar av systemet kan omprövas och byggas om.

    https://kaosx.us/download

    Faktaruta: KaOS Linux 2026.03

    Typ: Självständig Linuxdistribution

    Pakethanterare: pacman

    Kärna: Linux 6.19.10

    Grafikstack: Mesa 26.0.3

    Displayprotokoll: Wayland 1.25

    Standard-bootloader: Limine

    Borttaget: systemd-boot i Calamares, mkinitcpio

    Ersättare: Dracut för initramfs

    Skrivbordsmiljö: Niri 25.11 + Noctalia 4.7

    Mål: Att på sikt bli en systemd-fri distribution med Dinit

  • Mindre GRUB – säkrare start? Canonical vill strama åt Secure Boot i Ubuntu 26.10

    Canonical planerar en omfattande förändring av hur Ubuntu startar i framtiden. Genom att kraftigt begränsa funktionerna i GRUB vid Secure Boot vill företaget minska säkerhetsrisker – men förslaget kan samtidigt tvinga många användare att ändra hur deras system är uppbyggda.

    Vad handlar det om?

    Företaget Canonical, som utvecklar Ubuntu, planerar förändringar i hur system startar med Secure Boot i version 26.10.

    Kärnan i förslaget är att skapa en nedbantad version av GRUB för system som använder Secure Boot.

    Denna variant skulle ta bort stöd för flera avancerade funktioner, bland annat LUKS, LVM, ZFS och Btrfs, samt delar av RAID och vissa filformat.

    I stället ska system starta från en enklare lösning, oftast en vanlig ext4-partition för /boot.

    Varför vill man göra detta?

    Bakgrunden är säkerhet. GRUB körs innan operativsystemet startar och har därför mycket hög behörighet.

    För att kunna starta systemet måste GRUB kunna läsa olika filsystem, tolka diskformat och hantera konfigurationer. Varje sådan funktion innebär mer kod, och mer kod innebär fler potentiella sårbarheter.

    Genom att minska mängden funktioner vill Canonical:

    minska attackytan
    göra säkerhetsgranskning enklare
    förbättra tillförlitligheten i Secure Boot-kedjan

    Det är ett exempel på principen att enklare system ofta är lättare att säkra.

    Vad är Secure Boot?

    Secure Boot är en funktion i modern firmware som ser till att endast signerad kod får köras vid uppstart.

    Processen fungerar ungefär så här:

    först verifierar firmware bootloadern
    sedan verifierar bootloadern operativsystemets kärna
    därefter startar systemet

    Om något i kedjan inte är betrott stoppas uppstarten.

    Problemet är att GRUB i dag är ganska komplext, vilket gör det till en möjlig angreppspunkt.

    Vad blir konsekvenserna?

    För många användare kan förändringen få stora praktiska effekter.

    System som använder kryptering med LUKS eller volymhantering med LVM kommer inte längre fungera tillsammans med Secure Boot i standardutförande.

    Även användare av ZFS och Btrfs påverkas, eftersom dessa filsystem tas bort ur den signerade GRUB-versionen.

    Uppgraderingar kan stoppas

    Canonical har också meddelat att system som använder dessa funktioner inte kommer kunna uppgraderas till Ubuntu 26.10 via vanliga verktyg.

    Istället måste användaren:

    ändra sin partitionering
    installera om systemet
    eller stänga av Secure Boot

    Det innebär ett tydligt brott mot dagens förväntningar om smidiga uppgraderingar.

    Servermiljöer påverkas mest

    I många serverinstallationer är det vanligt att kombinera kryptering, LVM och RAID.

    Det betyder att förändringen inte bara är en teknisk detalj, utan kan kräva omdesign av hela system.

    För organisationer med etablerade infrastrukturer kan detta bli både tidskrävande och kostsamt.

    En konflikt mellan säkerhet och flexibilitet

    Det här illustrerar en klassisk avvägning inom IT.

    Ett enklare system är lättare att säkra, men också mindre flexibelt.

    Canonical prioriterar tydligt säkerheten i bootkedjan, medan många användare värderar möjligheten att bygga avancerade lagringslösningar.

    Även utseendet förenklas

    Förslaget innebär också att stöd för bildformat som PNG och JPEG tas bort i den signerade GRUB-versionen.

    Det gör att teman med bakgrundsbilder och ikoner inte längre fungerar i Secure Boot-läge.

    Det är en liten förändring i praktiken, men visar tydligt ambitionen att ta bort allt som inte är absolut nödvändigt.

    Vad händer nu?

    Förslaget gäller Ubuntu 26.10 och är ännu inte slutgiltigt beslutat.

    Diskussionen i communityn är intensiv, och det är möjligt att Canonical justerar planen innan den genomförs.

    Slutsats

    Canonical försöker minska komplexiteten i en av de mest kritiska delarna av systemstarten.

    Det kan leda till bättre säkerhet, men också till att vissa funktioner och arbetssätt försvinner.

    Frågan som återstår är hur mycket flexibilitet användarna är beredda att offra för en säkrare uppstart.

    https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069

    Faktaruta: GRUB och Secure Boot i Ubuntu 26.10

    Vad föreslås?
    Canonical vill minska funktionerna i den signerade GRUB-versionen som används med Secure Boot.

    Vad kan tas bort?
    Stöd för LUKS, LVM, ZFS, Btrfs, delar av md-raid samt PNG- och JPEG-bilder i GRUB-teman.

    Varför?
    Syftet är att minska attackytan i den känsliga uppstartsprocessen före att operativsystemet har laddats.

    Vilka påverkas?
    Användare och administratörer som har system med kryptering, avancerad lagring eller särskilda boot-konfigurationer.

    Praktisk följd
    Vissa system kan behöva en separat ext4-partition för /boot för att fortsatt fungera med Secure Boot.

    Risk för användare
    Berörda installationer kan få svårt att uppgradera till Ubuntu 26.10 utan omkonfigurering.

    Status
    Förslaget är ännu inte slutgiltigt beslutat och diskussionen pågår.

  • openSUSE Tumbleweed byter standardbootloader – GRUB2-BLS tar över för UEFI-installationer

    openSUSE Tumbleweed tar ännu ett steg mot framtidens Linux genom att byta standardbootloader för nya UEFI-installationer: från klassiska GRUB2 till GRUB2-BLS. För användaren innebär det enklare hantering av uppstartsmenyn, bättre stöd för full diskkryptering och smidigare integration med moderna säkerhetslösningar som TPM2 och FIDO2. BIOS-användare märker ingen skillnad – där fortsätter den traditionella GRUB2-uppsättningen som vanligt.

    openSUSE Tumbleweed fortsätter att ligga i framkant bland Linuxdistributioner. Nu meddelar projektet att man byter ut den klassiska GRUB2-bootloadern mot GRUB2-BLS som standard vid nya installationer med UEFI. Använder du fortfarande BIOS? Då påverkas du inte – där är det fortfarande vanliga GRUB2 som gäller.

    Varför byter openSUSE?

    Om du installerar Tumbleweed igen på en modern dator med UEFI kommer YaST-installationsprogrammet numera att välja GRUB2-BLS automatiskt. Det här är samma linje som openSUSE MicroOS redan slagit in på, där man använder systemd-boot – ett modernt och snabbt alternativ.

    Den största anledningen är bättre stöd för full diskkryptering (FDE) i kombination med systemd-baserade verktyg, inklusive stöd för TPM2 och FIDO2-nycklar för säker uppstart.

    Vad är GRUB2-BLS egentligen?

    GRUB2-BLS är fortfarande GRUB2, men med extra patchar tagna från Fedora-projektet. Dessa patchar gör bootloadern kompatibel med Boot Loader Specification (BLS) – ett modernt sätt att beskriva uppstartsmenyer med små textfiler i katalogen:

    /boot/efi/loader/entries/
    

    Varje fil motsvarar ett startalternativ och innehåller:

    • vilken kärna som ska laddas
    • initrd-filen
    • kärnans kommandorad

    I kommande versionen GRUB 2.14 blir dessa patchar en integrerad del av projektet, så GRUB2-BLS blir på sikt den normala GRUB2-upplevelsen.

    Inga fler grub2-mkconfig

    En av de praktiska skillnaderna är att systemet inte längre bygger statiska konfigurationsfiler vid varje uppdatering. GRUB2-BLS läser helt enkelt av katalogen med startposter vid uppstart och bygger menyn dynamiskt.

    Det gör att gamla verktyg som grub2-mkconfig och grub2-install inte längre behövs.

    Ny struktur: allt i en enda EFI-fil

    I klassisk GRUB2 låg moduler, teman, fonter och konfiguration spridda i /boot/grub2/.
    Med GRUB2-BLS packas allt ihop i en enda EFI-binär i:

    /boot/efi/EFI/opensuse
    

    Detta är möjligt eftersom UEFI-partitionen (ESP) nu är betydligt större – installeraren föreslår omkring 1 GB.

    Anledningen?
    Kärnor och initrds kommer också att ligga i ESP, vilket krävs för att FDE med systemd ska fungera smidigt.

    Så påverkar det installationen

    För nya installationer gör YaST allt automatiskt:

    1. ESP skapas i rätt storlek
    2. GRUB2-BLS väljs som bootloader
    3. Startposter skapas enligt BLS-standard

    Vill du istället köra klassisk GRUB2 eller systemd-boot?
    Det går fortfarande, men du måste ändra det manuellt på skärmen Installation Settings → Booting.

    Full diskkryptering med TPM2 eller FIDO2

    När BLS används kan Tumbleweed installeras med systemd-baserad full diskkryptering direkt från:

    Suggested Partitioning → Guided Setup → Enable Disk Encryption

    Där kan du:

    • ange LUKS2-lösenord
    • lägga till TPM2 eller FIDO2 som extra säkerhetsnycklar

    För bärbara datorer rekommenderas TPM2 + PIN, där TPM kontrollerar att maskinen inte har manipulerats innan lösenordet accepteras.

    Uppdateringar och kernelparametrar

    Eftersom bootmenyn genereras dynamiskt sker uppdateringar av startposterna automatiskt via verktyget:

    sdbootutil update
    

    Snapper och SUSE-moduler använder detta bakom kulisserna.

    Vill du ändra boot-parametrar?

    1. Redigera /etc/kernel/cmdline
    2. Kör:
    sdbootutil update-all-entries
    

    Så sprids ändringen till alla snapshot-poster.

    Kan man uppgradera ett befintligt system?

    Tekniskt: Ja.
    Praktiskt: openSUSE rekommenderar det inte, främst eftersom de flesta system har för liten ESP-partition. Den behöver utökas för att hålla kärnor och initrd-filer.

    Det finns dock officiella instruktioner för den som vill försöka.

    Sammanfattning

    openSUSE Tumbleweed tar ett modernt steg framåt genom att:

    • använda GRUB2-BLS som standard vid UEFI-installationer
    • följa Boot Loader Specification
    • förenkla hantering av bootmenyer
    • förbättra stödet för säker full diskkryptering

    Det här är ett stort men positivt förändringssteg för användare som vill ha maximal flexibilitet och framtidssäker teknik i sin Linuxinstallation.

    openSUSE Tumbleweed – Teknisk faktaruta (GRUB2-BLS)

    Distribution:
    • openSUSE Tumbleweed (rolling release)
    Ny standardbootloader:
    • GRUB2-BLS (vid nya UEFI-installationer)
    Tidigare standard:
    • GRUB2 (fortsätter som standard för BIOS-användare)
    BLS-format:
    • Boot Loader Specification, Type #1
    • Bootentries lagras som textfiler i:
      /boot/efi/loader/entries/
    Installationsförändringar:
    • ESP-partitionen ökas till ~1 GB
    • Alla kernels + initrds läggs direkt i ESP
    • GRUB2-BLS paketeras som en EFI-binär i:
      /boot/efi/EFI/opensuse
    Verktyg som ersätts / inte längre behövs:
    • grub2-mkconfig
    • grub2-install
    • Menyn genereras dynamiskt vid uppstart (inga statiska konfigfiler)
    Uppdateringar:
    • Hanteras via systemd-verktyg:
      sdbootutil update
      sdbootutil update-all-entries
    Kernelparametrar:
    • Editera /etc/kernel/cmdline och kör:
      sdbootutil update-all-entries
    Säkerhet & full diskkryptering (FDE):
    • Full diskkryptering via systemd-stacken
    • Stöd för TPM2- och FIDO2-baserad upplåsning
    • Rekommenderat för laptops: TPM2 + PIN
    Kompatibilitet:
    • Uppgradering från klassisk GRUB2 möjlig
    • Rekommenderas inte p.g.a. oftast för liten ESP
    Trend:
    • Följer samma moderna boot-strategi som MicroOS (systemd-boot)

Etikett: bootloader

  • När Linux och Secure Boot måste byta nyckel

    När Microsofts äldre Secure Boot-certifikat från 2011 löper ut behöver Linuxvärlden ta nästa steg i övergången till en nyare signeringskedja. För de flesta användare sker förändringen i bakgrunden, men för Linuxdistributioner, installationsmedia och äldre datorer kan den bli avgörande. I grunden handlar det om något så enkelt – och viktigt – som att datorn måste…

  • KaOS Linux 2026.03 – ett steg mot ett systemd-fritt Linux

    KaOS Linux fortsätter att utmana etablerade normer i Linuxvärlden. I marsutgåvan 2026.03 tar distributionen ytterligare steg bort från systemd genom att ersätta centrala komponenter och införa nya tekniska lösningar. Resultatet är ett djärvt experiment i hur ett modernt operativsystem kan byggas utan en av dess mest dominerande byggstenar. Den senaste versionen av KaOS Linux (2026.03)…

  • Mindre GRUB – säkrare start? Canonical vill strama åt Secure Boot i Ubuntu 26.10

    Canonical planerar en omfattande förändring av hur Ubuntu startar i framtiden. Genom att kraftigt begränsa funktionerna i GRUB vid Secure Boot vill företaget minska säkerhetsrisker – men förslaget kan samtidigt tvinga många användare att ändra hur deras system är uppbyggda. Vad handlar det om? Företaget Canonical, som utvecklar Ubuntu, planerar förändringar i hur system startar…

  • openSUSE Tumbleweed byter standardbootloader – GRUB2-BLS tar över för UEFI-installationer

    openSUSE Tumbleweed tar ännu ett steg mot framtidens Linux genom att byta standardbootloader för nya UEFI-installationer: från klassiska GRUB2 till GRUB2-BLS. För användaren innebär det enklare hantering av uppstartsmenyn, bättre stöd för full diskkryptering och smidigare integration med moderna säkerhetslösningar som TPM2 och FIDO2. BIOS-användare märker ingen skillnad – där fortsätter den traditionella GRUB2-uppsättningen som…