VPS start niet op na kernel-update: zo herstelt u dit

Wat te doen als een VPS niet opstart na een kernel-update

Een VPS die niet opstart na een kernel-update is meestal binnen enkele minuten te herstellen, omdat de update de voorheen werkende kernel niet heeft verwijderd. Ubuntu installeert een nieuwe kernel naast de oude en wijzigt alleen welk item GRUB standaard opstart. De eerste stap is daarom geen reparatie. Selecteer de vorige kernel in het opstartmenu, verkrijg weer een inlogprompt en voer daarna een diagnose uit vanaf een draaiend systeem.

Het herstellen van een server verschilt van dat van een laptop, omdat er geen toetsenbord is aangesloten en er geen monitor is die de kernel panic toont. SSH zal ook niet reageren, aangezien de machine nooit het punt bereikt waarop sshd start. Alles hieronder gebeurt via de console van uw provider.

Lees uw eigen console voordat u iets wijzigt. De tekst op dat scherm bepaalt in welke foutcategorie u zich bevindt; twee servers die beide "niet opstarten" kunnen tegenovergestelde oplossingen vereisen.

Hoe bereik ik de console als SSH niet meer reageert?

Open het configuratiescherm van uw provider en zoek naar een console. Veelgebruikte namen zijn VNC console, web console, noVNC en serial console. Geef de voorkeur aan de serial console als beide beschikbaar zijn, omdat u hiermee echte tekst krijgt die u kunt scrollen en kopiëren, terwijl een VNC-weergave slechts een afbeelding van een scherm is. Zoek deze functie nu op, terwijl de machine nog gezond is, en controleer of deze opent. Zoeken naar deze optie tijdens een storing kost u de rust die u nodig heeft. Deze controle hoort bij de eerste tien minuten op een nieuwe VPS, naast de firewallregels en de SSH-keys.

De meeste configuratieschermen bieden ook een rescue mode of recovery image aan. Hiermee wordt een klein systeem opgestart vanaf het netwerk van de provider en wordt uw schijf als extra apparaat aangekoppeld, zodat er niets vanaf uw eigen schijf wordt uitgevoerd. Rescue mode is de terugvaloptie voor wanneer GRUB zelf defect is, en het is ook de manier om data te kopiëren van een server die u niet meer wilt behouden.

U heeft meestal een hard reset vanuit het configuratiescherm nodig om het bootmenu te bereiken, aangezien u sudo reboot niet kunt uitvoeren op een machine waar u niet op kunt inloggen. Een hard reset staat gelijk aan het onderbreken van de stroomtoevoer. Bestandssystemen worden hierdoor niet correct afgesloten, dus houd rekening met een bestandssysteemcontrole bij de volgende keer opstarten.

Hoe kies ik een oudere kernel in het GRUB-menu?

Houd de console in de gaten vanaf het moment dat u de server opnieuw opstart. Druk herhaaldelijk op Esc tijdens de eerste seconden, of houd Shift ingedrukt op een machine die in legacy BIOS-modus opstart. Dit tijdsvenster is kort en de console-viewer heeft vaak een seconde nodig om verbinding te maken; begin dus vroeg en blijf drukken.

Wanneer het menu verschijnt, kiest u "Advanced options for Ubuntu". Dit submenu toont elke geïnstalleerde kernel, met de nieuwste bovenaan, inclusief een recovery mode-optie voor elk exemplaar. Kies de tweede normale vermelding, dit is de kernel direct onder de nieuwste, en druk op Enter. Recovery mode is iets anders: dit start een minimaal single-user-systeem op en is bedoeld voor reparatiewerkzaamheden, niet om uw services weer online te krijgen.

Als de oudere kernel opstart, is uw server weer actief. Controleer op welke versie u draait en noteer de versienummers.

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

De uitvoer van dpkg is uw lijst met geïnstalleerde kernels. Als deze slechts één regel bevat, heeft u geen fallback-optie en dat is het eerste wat u moet herstellen.

Het GRUB-menu verschijnt nooit. Wat nu?

Cloud-images bevatten een configuratie die het menu verbergt. Ubuntu-images stellen de timeout in bestanden onder /etc/default/grub.d/ vaak in op 0, waardoor de nieuwste kernel direct start en er geen mogelijkheid is om een toets in te drukken.

Er is ook het tegenovergestelde scenario, waarbij het menu op het scherm staat te wachten, wat lijkt op een vastloper. GRUB registreert een mislukte boot en kan bij de volgende start het menu openhouden totdat iemand een toets indrukt. Op een systeem zonder toetsenbord eindigt dit wachten nooit. Als uw console een menu toont en er gebeurt niets, dan is dit de oorzaak. Selecteer een item om door te gaan.

Los beide problemen op terwijl de machine nog functioneert. Bewerk /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

Pas de wijzigingen vervolgens toe en controleer of uw aanpassing behouden is gebleven, aangezien bestanden in /etc/default/grub.d/ na /etc/default/grub worden ingelezen en uw instellingen kunnen overschrijven.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" stuurt het menu naar zowel de grafische console als de seriële poort, zodat het zichtbaar is in de viewer die uw beheerpaneel aanbiedt. De console= kernel-argumenten doen hetzelfde voor de boot-berichten die volgen. Een vertraging van tien seconden per boot is een kleine prijs voor een menu dat u ook om 02:00 uur kunt bereiken.

Met welke storingsklasse heb ik te maken?

Lees de laatste twintig regels voordat de console stopt met scrollen. Vier patronen dekken het merendeel van de problemen die optreden na een kernel-update.

GRUB kan zijn eigen bestanden niet vinden. U krijgt een grub rescue>-prompt, of een foutmelding over een partitie of bestand dat niet bestaat, en er verschijnt geen enkele kernelmelding. De kernel is hier nog niet bij betrokken. Dit volgt doorgaans op een wijziging aan de schijf of partitie, of een bootloader die naar het verkeerde apparaat is geschreven, in plaats van op een kernel-pakket op zichzelf.

De kernel start, maar kan de root-partitie niet mounten. Kernelmeldingen scrollen voorbij, waarna u in een busybox-shell belandt met de prompt (initramfs), of het opstartproces eindigt in een kernel panic omdat het root-bestandssysteem niet gemount kan worden. De kernel is geladen. De initramfs, de kleine tijdelijke root die het echte root-bestandssysteem zoekt en mount, heeft de schijf niet gevonden. Op Ubuntu wordt deze shell meestal voorafgegaan door een melding dat het wachten op het root-apparaat wordt opgegeven, waarbij de gezochte UUID wordt genoemd. Kopieer die UUID en vergelijk deze later met de uitvoer van blkid.

Een logical volume verschijnt niet. Dit is de vorige klasse met één specifieke oorzaak. Voer bij de (initramfs)-prompt ls /dev/mapper uit. Als het enige resultaat control is, dan is er geen LVM (logical volume manager) volume geactiveerd en bestaat het root-apparaat nog niet. Activeer de volume groups handmatig:

lvm vgchange -ay
ls /dev/mapper
exit

exit geeft de controle terug aan het initramfs-script, dat de mount-poging opnieuw uitvoert. Als het systeem daarna opstart, mist de nieuwe initramfs de LVM-onderdelen. De reparatie bestaat dan uit het opnieuw opbouwen van die image in plaats van het aanpassen van de kernel.

Helemaal niets van Linux. De console toont firmware-tekst, een UEFI (unified extensible firmware interface) shell, een leeg scherm zonder kernel-uitvoer, of een reset-loop. De fout treedt op voordat Linux wordt uitgevoerd. Controleer welke modus uw server daadwerkelijk gebruikt zodra u weer toegang heeft, aangezien veel VPS-instanties opstarten in legacy BIOS-modus en het EFI-pad nooit aanraken:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

Een niet-gemounte /boot/efi tijdens de upgrade is een veelvoorkomende oorzaak op UEFI-machines, omdat de pakketten die de EFI-systeempartitie onderhouden dan naar een gewone lege map hebben geschreven. De firmware blijft het oude boot-item starten totdat dat item niet meer overeenkomt met wat er op de schijf staat.

Eén ander patroon is helemaal geen opstartfout. Als u een root-shell bereikt die aangeeft dat het systeem in emergency mode is, dan is de kernel opgestart maar is de userspace gestopt. Dat betekent meestal een foutieve regel in /etc/fstab of een bestandssysteem dat niet door de controle kwam. Voer journalctl -xb uit in die shell en lees de naam van de unit die faalde.

Is het kernelpakket defect, of de initramfs?

Deze twee problemen zien er vanaf de console identiek uit, maar vereisen verschillende reparaties. Start de oude kernel op en vergelijk vervolgens de bestanden.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

U wilt één vmlinuz- en één bijbehorende initrd.img- voor elke geïnstalleerde versie, elk met een aannemelijke bestandsgrootte. Een ontbrekende initrd, of een bestand dat veel kleiner is dan de omliggende bestanden, betekent dat het genereren van de initramfs is mislukt. De gebruikelijke oorzaak is een volle /boot, en het bewijs hiervoor staat in de pakketlogs:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log toont ook precies welke pakketten bij de laatste uitvoeringen zijn geïnstalleerd en wanneer, wat elke discussie over wat er is gewijzigd beëindigt.

Maak eerst schijfruimte vrij als /boot vol is, bouw daarna de image opnieuw op voor de versie die u nodig heeft en ververs het menu. Gebruik de versie-string uit uw eigen ls-uitvoer, aangezien de onderstaande placeholder geen echte release is:

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

Die laatste ls is de controle. Een bestand van normale grootte betekent dat de image nu aanwezig is. Als daarentegen de kernel-image zelf beschadigd is, of als dpkg -l het pakket in een andere status dan ii toont, installeer het pakket dan opnieuw:

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

Herstellen vanuit de rescue-modus wanneer de kernel niet opstart

Als elk item in het opstartmenu faalt, start dan de rescue-image van de provider en herstel de schijf van buitenaf. Uw schijf verschijnt als een niet-aangekoppeld apparaat, waardoor er niets op draait en er geen conflicten kunnen optreden.

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

Een nieuwe kernel testen zonder het volgende opstartproces in gevaar te brengen

GRUB kan een item eenmalig opstarten en daarna terugvallen op de standaardinstelling. Wijs de standaardinstelling toe aan een kernel die u vertrouwt en start vervolgens de nieuwe kernel voor slechts één sessie. Mocht dit mislukken, dan keert u na een harde reset via het paneel terug naar de werkende kernel, zonder dat u de timing van de console hoeft te timen.

Stel GRUB_DEFAULT=saved in /etc/default/grub in, voer sudo update-grub uit en lijst vervolgens de titels van de items op zodat u er exact één kunt benoemen:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list hoort uw gekozen titel als saved_entry weer te geven. Deze uitvoer is het bewijs dat het mechanisme werkt, aangezien voor het opslaan een beschrijfbaar /boot/grub/grubenv-bestand vereist is, wat bij sommige indelingen stilletjes niet het geval is. Item 0 is het bovenste item in het menu, wat de nieuwste kernel is. Titels zijn hier veiliger dan nummers, aangezien nummers verschuiven telkens wanneer een kernel wordt geïnstalleerd of verwijderd.

Waarom autoremove riskant is op een headless server

APT houdt een lijst bij van kernelpakketten die het niet uit zichzelf mag verwijderen. Bekijk uw lijst:

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

Dit bestand wordt opnieuw gegenereerd zodra kernelpakketten wijzigen en beschermt de actieve kernel en de meest recente versies. Het risico zit in de timing. Voer sudo apt autoremove --purge uit direct na het herstarten naar een nieuwe kernel, en de beschermde lijst is al opgeschoven. De oudere kernel waar u op rekende, is dan niet langer beschermd. Op een machine met een toetsenbord is dat onhandig. Op een headless server is het het verschil tussen het kiezen van een menu-item en het mounten van uw schijf vanaf een rescue-image.

Hanteer twee kernels als minimum, en drie wanneer /boot daar de ruimte voor heeft. Verwijder oude kernels bij naam nadat u uname -r heeft gecontroleerd, zodat u nooit de kernel verwijdert die u op dat moment gebruikt:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

Voer dat laatste commando daarna nogmaals uit. Als het aantal van drie naar twee gaat, is dit een opschoonactie. Als het aantal naar één gaat, is dit een storing die wacht op de volgende herstart.

Maak een snapshot vóór de upgrade

Een snapshot die vóór apt upgrade wordt gemaakt, is het enige herstelpad dat niet afhankelijk is van het opstarten van externe media. Het terugzetten hiervan brengt de schijf terug naar de status waarin de oude kernel de standaard was, en u kunt de upgrade opnieuw proberen terwijl de console al geopend is. Snapshots van een draaiende machine zijn 'crash consistent'; dit betekent dat ze de schijf vastleggen alsof de stroom is uitgevallen. Schakel de server daarom eerst uit als uw provider een offline snapshot ondersteunt. Een snapshot is bovendien geen back-up, omdat deze meestal op dezelfde infrastructuur staat als het volume waarvan een kopie wordt gemaakt. Het begrijpen van het verschil tussen VPS-snapshots en echte back-ups bepaalt welke methode u redt wanneer het defect groter is dan alleen een kernelprobleem.

Dit is vooral van belang bij een release-upgrade, waarbij de kernel, de initramfs-tools, de bootloader en de GRUB-configuratie allemaal in één keer wijzigen. Maak de snapshot direct voordat u begint met een Ubuntu 24.04 naar 26.04 upgrade, en niet de avond ervoor, zodat het herstelpunt exact overeenkomt met de machine die u op het punt staat te wijzigen.

Hoe unattended-upgrades omgaat met kernelpakketten

Ubuntu's unattended-upgrades installeert beveiligingsupdates zonder tussenkomst, en kernelpakketten komen via de security-pocket binnen, net als alle andere updates. Dit heeft twee gevolgen.

Ten eerste wordt de nieuwe kernel wel geïnstalleerd, maar niet uitgevoerd. Een kernel wordt pas actief na een herstart. Het bestand /var/run/reboot-required verschijnt en /var/run/reboot-required.pkgs vermeldt wat de herstart heeft aangevraagd, maar er wordt niets opnieuw opgestart tenzij u Unattended-Upgrade::Automatic-Reboot heeft ingeschakeld in /etc/apt/apt.conf.d/50unattended-upgrades.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

Ten tweede verbergt dit tijdsverschil de oorzaak. Een server kan in maart een kernel installeren en in juni om een totaal andere reden herstarten, waarna deze niet meer opstart. De wijziging die het opstartproces verstoorde is dan drie maanden oud, waardoor de gebeurtenissen van die dag geen verklaring bieden. In /var/log/apt/history.log vindt u de run terug die de kernel heeft geïnstalleerd waar u nu problemen mee ondervindt.

Herstart bewust, op een dag die u zelf kiest, terwijl het consolevenster al openstaat. Deze ene gewoonte verandert een mysterieuze uitval in een handeling van twee minuten. Als u de automatisering wilt zonder verrassingen, laat dan automatische installaties aanstaan en automatische herstarts uit, en raadpleeg hoe u unattended-upgrades op Ubuntu configureert voor de exacte instellingen. Het tegenhouden van kernelpakketten met sudo apt-mark hold linux-image-generic stopt deze volledig, maar hiermee stopt u tegelijkertijd ook de beveiligingsupdates voor de kernel. Beschouw dit daarom als een bewuste afweging en niet als een veiligheidsmaatregel.

FAQ

Hoe start ik een oudere kernel op een VPS zonder toetsenbord?

Open de console van de provider (VNC of serieel) en voer een harde reset uit via het configuratiescherm, omdat u niet kunt inloggen voor een schone herstart. Terwijl de machine opstart, drukt u herhaaldelijk op Esc, of houdt u Shift ingedrukt bij een legacy BIOS-boot, om het GRUB-menu vast te houden. Kies "Advanced options for Ubuntu" en selecteer het item onder de nieuwste kernel. Zodra u een inlogprompt heeft, voert u uname -r uit om te bevestigen op welke kernel u draait en dpkg -l 'linux-image-*' om te zien wat er nog meer is geïnstalleerd. Diagnoseer pas nadat het systeem weer draait.

Waarom toont mijn VPS helemaal geen GRUB-menu?

Cloud-images zetten de GRUB-timeout vaak op 0 in een bestand onder /etc/default/grub.d/, waardoor de nieuwste kernel direct start zonder dat u iets kunt indrukken. Stel GRUB_TIMEOUT=10 en GRUB_TIMEOUT_STYLE=menu in binnen /etc/default/grub, voeg GRUB_TERMINAL="console serial" toe zodat het menu ook de seriële console bereikt, en voer daarna sudo update-grub uit. Controleer dit met grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, omdat bestanden in die map na het hoofdbestand worden gelezen en uw wijziging kunnen overschrijven.

Moet ik oude kernels verwijderen om ruimte vrij te maken in /boot?

Verwijder de oudste en behoud er ten minste twee. Een volle /boot is een storingsbron op zich, omdat het genereren van initramfs dan mislukt en u achterblijft met een kernel zonder werkende image. Verwijder pakketten op de exacte naam nadat u uname -r heeft gecontroleerd, zodat de actieve kernel nooit een kandidaat is. Vermijd een algemene sudo apt autoremove --purge op een headless machine, aangezien de lijst met beschermde kernels bij elke kernelwijziging opnieuw wordt gegenereerd en een slecht getimede actie u kan achterlaten met één kernel zonder fallback-optie in het menu.

Kan unattended-upgrades mijn bootproces verstoren?

Het kan een kernel installeren die later niet opstart, maar het systeem herstart niet tenzij Unattended-Upgrade::Automatic-Reboot op true is ingesteld in /etc/apt/apt.conf.d/50unattended-upgrades. Het gebruikelijke patroon is een vertraagde fout: de kernel wordt tijdens een automatische run geïnstalleerd, /var/run/reboot-required verschijnt, en het probleem komt pas aan het licht bij uw volgende herstart weken later. Herstart bewust met de console al geopend en lees /var/log/apt/history.log om te achterhalen welke run de kernel heeft geïnstalleerd waarmee u opstart.