Kernel updaten op een productieserver: volgorde, rollback-plan en wanneer livepatch de moeite is

Alle andere updates kun je terugdraaien met apt install pkg=oude-versie. Een kernel-update draai je terug door in GRUB de oude kernel te kiezen — en dat vereist dat je bij GRUB kunt, dat de oude kernel er nog is, en dat je dat allemaal onder tijdsdruk doet terwijl de server down is. Daarom is de voorbereiding 80 % van het werk. Dit artikel is de checklist, in de volgorde waarin we hem zelf afwerken.

Stap 0: weet waarom je reboot

uname -r                                          # wat draait
dpkg -l 'linux-image-[0-9]*' | awk '/^ii/{print $2}' | sort -V   # wat er staat
cat /var/run/reboot-required.pkgs 2>/dev/null     # waarom het systeem een reboot wil

Is de nieuwe kernel er al (geïnstalleerd door unattended-upgrades, nog niet geboot), dan sla je stap 3 over. Zit er een CVE in het spel: controleer eerst in kernel-CVE's en backports of die jouw kernel raakt — de helft van de "dringende" kernel-reboots is dat niet.

Stap 1: pre-checks (vijf minuten die je een nacht besparen)

# 1. Ruimte op /boot — elke kernel is 100–150 MB; te weinig = halve installatie
df -h /boot
sudo apt autoremove --purge -y            # oude kernels weg, houd er minstens twee

# 2. Out-of-tree modules (DKMS): die moeten voor de nieuwe kernel opnieuw gebouwd worden
dkms status 2>/dev/null                    # nvidia, zfs, wireguard (oud), virtualbox, ...
# Leeg = geen zorgen. Anders: zorg dat linux-headers-<nieuwe versie> mee wordt geïnstalleerd.

# 3. Secure Boot + DKMS = modules moeten ondertekend zijn met een MOK-sleutel
mokutil --sb-state 2>/dev/null             # "SecureBoot enabled" + DKMS → mokutil --list-enrolled

# 4. Welke kernel start GRUB standaard, en is er een menu om terug te vallen?
grep -E '^GRUB_(DEFAULT|TIMEOUT|TIMEOUT_STYLE)' /etc/default/grub
# GRUB_DEFAULT=0 en GRUB_TIMEOUT=0 betekent: geen kans om te kiezen bij een hangende boot.

# 5. Is er een console als SSH niet terugkomt? (cloud: VNC/serial in het paneel; bare metal: IPMI/iDRAC)
#    Dit is geen commando, dit is: weet je waar de knop zit VOOR je op reboot drukt?

# 6. Draaien er dingen die een nette stop nodig hebben?
systemctl list-units --type=service --state=running --no-legend | grep -Ei 'postgres|mysql|mariadb|redis|rabbit|docker'

Punt 5 is de belangrijkste. Een kernel die hangt op een host waar je geen console van hebt, is een ticket bij de hoster en een uur downtime.

Stap 2: snapshot of back-up

Op een VPS: snapshot via het paneel of de API van de hoster (Hetzner, OVH, Scaleway hebben allemaal een snapshot create). Op LVM:

sudo lvcreate -s -L 5G -n root-prekernel /dev/vg0/root
# Rollback later: sudo lvconvert --merge /dev/vg0/root-prekernel  (wordt actief na reboot)

Geen LVM en geen snapshot-API? Dan minstens een restic backup /etc /boot en de zekerheid dat je laatste volledige back-up van vandaag is. Zie back-ups controleren.

Stap 3: installeren, maar nog niet rebooten

sudo apt update
sudo apt install -y linux-image-generic linux-headers-generic     # Ubuntu
# sudo apt install -y linux-image-amd64 linux-headers-amd64        # Debian
# Of, als unattended-upgrades hem al binnenhaalde: niets te doen.

# Controle: staat de nieuwe kernel in /boot én in GRUB?
ls -1 /boot/vmlinuz-*
grep -oE "menuentry '[^']+'" /boot/grub/grub.cfg | head -5
# Zijn DKMS-modules voor de nieuwe kernel gebouwd?
dkms status 2>/dev/null | grep -v "$(uname -r)"    # moet "installed" zeggen voor de nieuwe versie

Ziet dkms status een added of built zonder installed voor de nieuwe kernel, reboot dan niet. sudo dkms autoinstall -k <nieuwe-versie> en kijk naar de fout.

Stap 4: de fallback — één mislukte boot en GRUB kiest zelf de oude kernel

Dit is de stap die het verschil maakt tussen "even spannend" en "middenin de nacht naar het datacenter". GRUB kan onthouden of een boot is geslaagd, en anders terugvallen.

# 1. Laat GRUB de laatst-gekozen entry onthouden en toon een kort menu op de console
sudo tee /etc/default/grub.d/90-fallback.cfg >/dev/null <<'EOF'
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=false
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=menu
GRUB_RECORDFAIL_TIMEOUT=30
EOF
sudo update-grub

# 2. Zet de OUDE kernel als standaard, en boot ÉÉNMALIG de nieuwe
OLD=$(uname -r)
NEW=$(ls -1 /boot/vmlinuz-* | sed 's|/boot/vmlinuz-||' | sort -V | tail -1)
echo "old=$OLD new=$NEW"
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux $OLD"
sudo grub-reboot      "Advanced options for Ubuntu>Ubuntu, with Linux $NEW"
# Debian: vervang "Ubuntu" door "Debian GNU/Linux"

Wat er nu gebeurt: de volgende boot gebruikt de nieuwe kernel (grub-reboot is eenmalig). Boot de nieuwe kernel niet (kernel panic, hangende driver), dan is bij de daaropvolgende power-cycle de oude kernel weer de standaard — zonder dat jij iets hoeft te doen. Boot hij wel, dan maak je hem in stap 6 definitief.

De exacte menu-namen haal je uit grep -oE "menuentry '[^']+'" /boot/grub/grub.cfg; ze verschillen per distributie en per kernel-flavour (-generic, -cloud-amd64).

Stap 5: rebooten, in het venster

# Nette stop van databases eerst — niet vertrouwen op de shutdown-timeout
sudo systemctl stop postgresql mariadb 2>/dev/null
sudo needrestart -b | grep KSTA          # 3 = reboot nodig, dus we doen het goed
sudo reboot

Start op een tweede scherm een ping en een ssh-poging in een loop. Meestal is een VPS binnen 30–90 seconden terug; een bare-metal server met veel RAM en een POST kan vijf minuten doen. Pas na tien minuten zonder SSH ga je naar de console.

Stap 6: verifiëren, dan pas definitief maken

uname -r                                          # de NIEUWE versie?
systemctl --failed                                 # niets
journalctl -b -p err --no-pager | head -30         # geen driver-fouten
ip -br a; ip route | head -3                       # netwerk zoals verwacht
lsmod | wc -l; dkms status 2>/dev/null             # modules geladen
df -h | grep -vE 'tmpfs|udev'                      # alle mounts terug (NFS! iSCSI!)
systemctl is-active postgresql mariadb docker 2>/dev/null
curl -fsS -o /dev/null -w '%{http_code}\n' http://localhost/healthz   # de applicatie zelf

# Alles goed? Maak de nieuwe kernel de standaard.
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux $(uname -r)"
# Of terug naar de gewone eerste entry:
# sudo sed -i 's/^GRUB_DEFAULT=saved/GRUB_DEFAULT=0/' /etc/default/grub.d/90-fallback.cfg && sudo update-grub

Log het resultaat met datum — dat is het bewijs voor de patch-doorlooptijd waar een auditor naar vraagt:

echo "$(date -Is) $(hostname -s) kernel $OLD -> $(uname -r) OK, downtime $(( $(date +%s) - $(stat -c %Y /var/log/kernel-update.start) ))s" | sudo tee -a /var/log/kernel-updates.log

(Zet sudo touch /var/log/kernel-update.start vlak vóór de reboot in stap 5.)

Rollback: als stap 6 níet goed is

De server is wel opgekomen, maar iets werkt niet (een netwerkkaart, een storage-driver, een applicatie die op een kernel-feature leunde):

# 1. Boot terug naar de oude kernel
sudo grub-reboot "Advanced options for Ubuntu>Ubuntu, with Linux $OLD" && sudo reboot
# 2. Na de reboot: bevries de kernel tot je weet wat er mis was
sudo apt-mark hold linux-image-generic linux-headers-generic
# 3. Verwijder de kapotte kernel pas als de oorzaak bekend is
# sudo apt remove linux-image-$NEW linux-modules-$NEW

En de LVM-snapshot uit stap 2 merge je alleen als er bestanden kapot zijn (een halve dpkg-run), niet voor een kernel die gewoon niet bevalt.

Wanneer livepatch de moeite is

Livepatch (Ubuntu Pro, gratis tot vijf machines; kpatch op RHEL) patcht een subset van kritieke kernel-CVE's in het geheugen, zonder reboot. Het is geen vervanging van deze procedure — needrestart blijft "reboot nodig" zeggen — maar het koopt tijd: de CVE van maandag is dinsdag gedicht, en de reboot plan je in het venster van volgende week.

De afweging: heb je een maandelijks onderhoudsvenster waarin een reboot toch al past, dan voegt livepatch weinig toe. Heb je een database of een klant-SLA die maar twee reboots per jaar toelaat, dan is het de moeite. Debian heeft geen officieel equivalent; daar is een gepland venster de praktijk.

Valkuilen

• GRUB_TIMEOUT=0 en geen console. Dan is er bij een hangende kernel geen enkele manier om in te grijpen. De fallback uit stap 4 lost dat op, maar alleen als je hem vóór de update instelt.
• NFS en iSCSI-mounts die niet terugkomen. Na een reboot met een nieuwe kernel kan een storage-module ontbreken of een mount time-outen. df -h in stap 6 is er precies daarvoor; een applicatie die start met een lege datadir is erger dan een applicatie die niet start.
• Cloud-kernels en de metapackage. Op AWS/Azure/GCP-images heet de metapackage linux-image-aws (enz.). linux-image-generic installeren op zo'n image geeft je een kernel zonder de cloud-drivers.
• apt autoremove die de draaiende kernel weghaalt. Kan niet — apt beschermt de draaiende kernel. Maar hij kan wél de oude kernel weghalen die je als fallback wilde. Draai autoremove na stap 6, niet ervoor.
• Twee updates tegelijk. Kernel + glibc + systemd in dezelfde reboot: als iets kapot is, weet je niet wat. Bij twijfel eerst de rest, dan de kernel.
• Reboots buiten de monitoring om. Een reboot om 03:00 die twee minuten duurt, genereert "host down"-alerts. Zet een maintenance window in je monitoring, of accepteer de alert en documenteer hem.

Wat je hiermee nog niet hebt

• Volgorde over de fleet. Veertien servers rebooten in de juiste volgorde (replica's vóór primaries, load balancers als laatste, nooit twee nodes van hetzelfde paar tegelijk) is een runbook dat iemand met de hand uitvoert.
• Goedkeuring en scheiding van rollen. Wie besloot dat deze kernel vandaag in productie ging, en wie voerde het uit? Voor een NIS2- of ISO-audit moeten dat aantoonbaar twee stappen zijn, met datum.
• Correlatie met wat er daarna gebeurt. De reboot van 03:00 en de trage database van 08:00 hangen samen, maar dat verband ligt in twee logs.

Zo doet monsys het

In monsys plan je kernel-updates als een batch over een groep hosts: de hub kent per host de draaiende en geïnstalleerde kernel, reboot_required, de failover-relaties (nooit beide nodes van een paar tegelijk) en het onderhoudsvenster van de groep. Een batch die door de AI-assistent of een MCP-client wordt voorgesteld, moet door een andere persoon worden goedgekeurd (segregation of duty, afgedwongen in de database), en elke stap — voorstel, goedkeuring, uitvoering per host, resultaat — is een ondertekende regel in het transparency log. De uitvoering zelf gaat via Emergency Action Tokens met UpdateKernel en Reboot als acties; een host die na de reboot niet terugkomt, pauzeert de batch.

FAQ

Hoe lang duurt een kernel-reboot?

Op een VPS 30–90 seconden tussen reboot en werkende SSH. Op bare metal met veel geheugen en een BIOS-POST tot vijf minuten. Reken in je venster op vijftien minuten inclusief verificatie; dat je er meestal maar drie nodig hebt, is winst.

Kan ik een kernel-update terugdraaien?

Ja, zolang de oude kernel nog in /boot staat: kies hem in het GRUB-menu of met grub-reboot, en zet hem met grub-set-default weer als standaard. Daarom houd je altijd minstens twee kernels en draai je apt autoremove pas ná een geslaagde verificatie.

Moet ik rebooten voor elke kernel-update?

Om de nieuwe kernel te draaien: ja. Of het dringend is, hangt af van de CVE's die de update fixt en of die op jouw configuratie van toepassing zijn. Controleer dat eerst; plan de rest in je gewone onderhoudsvenster.