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 na een kernel-update niet opstart, 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 het punt waarop sshd start nooit bereikt. Alles hieronder vindt plaats via de console van uw provider.

Lees uw eigen console voordat u wijzigingen aanbrengt. 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 schijf wordt uitgevoerd. Rescue mode is de fallback voor situaties waarin 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 verbreken 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 herstart. Druk herhaaldelijk op Esc tijdens de eerste seconden, of houd Shift ingedrukt op een machine die in legacy BIOS-modus opstart. Dit venster is kort en de console-viewer heeft vaak een seconde nodig om verbinding te maken; begin dus vroeg met drukken en blijf dit doen.

Wanneer het menu verschijnt, kiest u "Advanced options for Ubuntu". Dat 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 helemaal 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 time-out 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 en wacht, wat lijkt op een vastloper. GRUB registreert een mislukte boot en houdt bij de volgende start het menu open totdat iemand een toets indrukt. Op een machine zonder toetsenbord eindigt dat wachten nooit. Als uw console een menu toont en er gebeurt niets, dan is dit de oorzaak. Selecteer een item en ga verder.

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 paneel 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 's nachts kunt bereiken.

Met welke foutklasse heb ik te maken?

Lees de laatste twintig regels voordat de console stopt met scrollen. Vier patronen dekken het merendeel van de situaties 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 nog niet betrokken. Dit volgt meestal op een wijziging aan de schijf of partitie, of een bootloader die naar het verkeerde apparaat is geschreven, in plaats van op een kernelpakket op zichzelf.

De kernel start, maar kan de root-partitie niet koppelen. Kernelmeldingen scrollen voorbij, waarna u in een busybox-shell belandt waarvan de prompt (initramfs) leest, of het opstartproces eindigt in een panic omdat het root-bestandssysteem niet gekoppeld kan worden. De kernel is geladen. De initramfs, de kleine tijdelijke root die uw werkelijke root-bestandssysteem vindt en koppelt, heeft de schijf niet gevonden. Op Ubuntu wordt deze shell normaal gesproken 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 logisch volume verschijnt niet. Dit is de vorige klasse met één specifieke oorzaak. Voer bij de (initramfs)-prompt ls /dev/mapper uit. Als de enige vermelding control is, dan is er geen LVM (logical volume manager) volume geactiveerd, waardoor het root-apparaat nog niet bestaat. Activeer de volumegroepen handmatig:

lvm vgchange -ay
ls /dev/mapper
exit

exit geeft de controle terug aan het initramfs-script, dat de koppeling opnieuw probeert. Als het systeem daarna opstart, mist de nieuwe initramfs de LVM-onderdelen; de reparatie bestaat dan uit het herbouwen 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-gekoppelde /boot/efi tijdens de upgrade is een veelvoorkomende oorzaak op UEFI-machines, omdat de pakketten die de EFI-systeempartitie onderhouden in dat geval naar een gewone lege map hebben geschreven. De firmware blijft de oude boot-vermelding starten totdat die vermelding 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 staat, 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 is gekomen. Voer journalctl -xb uit in die shell en lees de naam van de unit die is mislukt.

Is het kernelpakket beschadigd, of de initramfs?

Deze twee lijken vanaf de console identiek, 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 hiervan 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 geeft ook exact weer welke pakketten bij de laatste runs 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 benodigde versie en ververs het menu. Gebruik de versiestring uit uw eigen ls-output, 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

Dat laatste ls is de controle. Een bestand met een 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 geen kernel opstart

Als elk item in het menu faalt, start dan de rescue-image van de provider op en repareer de schijf van buitenaf. Uw schijf verschijnt als een niet-aangekoppeld apparaat, waardoor er niets op draait en niets u kan tegenwerken.

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 standaardkeuze. Stel de standaard in op een kernel die u vertrouwt en start daarna de nieuwe kernel voor slechts één keer op. Als dit mislukt, zorgt een harde reset via het configuratiescherm ervoor dat u terugkeert naar de werkende kernel, zonder dat u de console-timing hoeft te timen.

Stel GRUB_DEFAULT=saved in /etc/default/grub in, voer sudo update-grub uit en som daarna de titels van de items op zodat u er exact een 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 weer te geven als saved_entry. Die uitvoer is het bewijs dat het mechanisme werkt, omdat voor het opslaan een beschrijfbare /boot/grub/grubenv vereist is, wat op sommige indelingen stilletjes niet het geval is. Item 0 is de bovenste regel van 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 gevaar schuilt in de timing. Voer sudo apt autoremove --purge uit direct na het herstarten naar een nieuwe kernel; de beschermde lijst is dan al opgeschoven, waardoor de oudere kernel waarop u vertrouwde niet langer beschermd is. Op een machine met een toetsenbord is dit een ongemak. Op een headless server is dit het verschil tussen het kiezen van een menu-item en het mounten van uw schijf vanaf een rescue-image.

Hanteer twee kernels als ondergrens, en drie wanneer /boot daar de ruimte voor biedt. 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 staat waarin de oude kernel de standaard was, waardoor u de upgrade opnieuw kunt 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 overeenkomt met de machine die u op dat moment gaat wijzigen. Als die upgrade nog niet wordt aangeboden op uw server, is de oorzaak de planning en niet een defecte configuratie; een overstap van LTS naar LTS wordt namelijk pas opengesteld bij de eerste point release, 26.04.1.

Hoe unattended-upgrades omgaat met kernel-pakketten

De tool unattended-upgrades van Ubuntu installeert beveiligingsupdates zonder tussenkomst van de gebruiker, en kernel-pakketten worden via de security-pocket geleverd, net als alle andere updates. Dit heeft twee gevolgen.

Ten eerste wordt de nieuwe kernel wel geïnstalleerd, maar niet direct 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 maskeert dit tijdsverschil de oorzaak van problemen. 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 al drie maanden oud, waardoor de gebeurtenissen van die dag geen verklaring bieden. In /var/log/apt/history.log vindt u de logbestanden van de run waarin de kernel werd geïnstalleerd die nu voor problemen zorgt.

Start bewust opnieuw op, op een dag die u zelf kiest, terwijl u de console open heeft staan. Deze eenvoudige gewoonte verandert een mysterieuze uitval in een handeling van twee minuten. Als u de automatisering wilt zonder verrassingen, laat dan automatische installaties aanstaan maar schakel automatische herstarts uit. Zie hoe u unattended-upgrades op Ubuntu configureert voor de exacte instellingen. Het tegenhouden van kernel-pakketten met sudo apt-mark hold linux-image-generic stopt deze updates volledig, maar daarmee blokkeert u ook beveiligingsfixes 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. Druk tijdens het opstarten herhaaldelijk op Esc, of houd 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. Start de diagnose 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 minimaal 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 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 wordt niet herstart tenzij Unattended-Upgrade::Automatic-Reboot op true staat 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 terwijl de console al open staat en lees /var/log/apt/history.log om te achterhalen welke run de kernel heeft geïnstalleerd waarmee u opstart.