Linux server start niet op? Zo stel je de diagnose en herstel je het

Linux start niet op: wat moet je als eerste doen?

Als je Linux server niet meer opstart, is de eerste reflex vaak om de machine opnieuw te starten of een willekeurig commando uit een forum te proberen. Doe dat niet. Elke ondoordachte actie kan het probleem verergeren of sporen wissen die je nodig hebt voor de diagnose.

Begin in plaats daarvan met deze vijf checks:

1. Noteer de exacte foutmelding. Maak een foto van het scherm of lees de console uit via IPMI, iDRAC of de console van je hoster. "GRUB rescue>", "Kernel panic - not syncing" en "Dropping to emergency shell" wijzen alle drie op heel andere problemen.
2. Bepaal wat er recent veranderd is. Een kernel-update, schijfuitbreiding, wijziging in /etc/fstab of een stroomonderbreking zijn de klassieke boosdoeners.
3. Controleer de basis. Zit er een USB-stick of schijf in die de bootvolgorde verstoort? Is een schijf losgekomen of uit een RAID-set gevallen?
4. Check of het een virtuele machine is. Dan kun je vaak een snapshot terugzetten of de schijf aan een andere VM koppelen.
5. Controleer je back-ups. Weet je zeker dat er een recente, werkende back-up is? Zo niet, dan is dataveiligheid prioriteit één.

Linux boot probleem: de meest voorkomende oorzaken

Een Linux boot probleem laat zich grofweg indelen op de fase waarin het opstarten vastloopt. Als je weet in welke fase het misgaat, weet je ook waar je moet zoeken.

In de praktijk komt een groot deel van de opstartproblemen op servers neer op drie dingen: een onderbroken of mislukte pakketupdate, een volle of beschadigde schijf, en een aanpassing in /etc/fstab die niet klopt. Hardwarefouten komen minder vaak voor, maar zijn wel de lastigste om te herkennen.

Stappenplan: Linux server herstellen met een live USB

Wanneer de server niet zelf meer opstart, is een live-omgeving je beste vriend. Je start dan een tijdelijk besturingssysteem vanaf USB (of via een virtuele ISO-mount op een remote console) en benadert vanaf daar je eigen schijven.

Stap 1: Boot van een live USB of rescue-image

Gebruik een live-image van dezelfde distributie en bij voorkeur dezelfde versie als je server. Dat voorkomt problemen met verschillende kernelversies of bestandssysteemfuncties. Bij veel hosters vind je een rescue-modus in het controlepaneel, waarmee je zonder fysieke toegang kunt booten.

Stap 2: Bekijk je schijven en partities

lsblk -f
sudo fdisk -l
sudo blkid

Zoek je root-partitie, de bootpartitie en bij UEFI-systemen de EFI-partitie (meestal vfat, rond de 512 MB). Mist een schijf in de uitvoer? Dan zit je waarschijnlijk met een hardware- of kabelprobleem.

Stap 3: Controleer de schijfgezondheid

sudo smartctl -a /dev/sda
cat /proc/mdstat   # bij software-RAID

Zie je herallocated sectors, pending sectors of leesfouten? Stop dan met experimenteren. Maak eerst een image van de schijf met ddrescue en werk op de kopie. Een falende schijf die je blijft belasten, kan ineens helemaal uitvallen.

Stap 4: Mount het systeem en lees de logs

sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi
sudo mount --bind /dev  /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys  /mnt/sys
sudo chroot /mnt

Pas de apparaatnamen aan op jouw situatie. Bekijk daarna wat er tijdens de vorige boot misging. Als journald persistent opslaat, werkt dit vanaf de live-omgeving:

journalctl -xb -1 --directory=/mnt/var/log/journal
# of, binnen de chroot:
journalctl -xb -1 -p err

Met -b -1 kijk je naar de vorige boot, met -p err filter je op fouten. Kijk ook naar /var/log/apt/history.log of /var/log/dnf.log om te zien welke update het laatst is uitgevoerd.

Stap 5: Controleer schijfruimte en fstab

df -h
df -i          # inodes, ook die kunnen vol zijn
cat /etc/fstab

Een volle root-partitie of een vergeten mount-regel naar een NFS-share of externe schijf die niet meer bestaat is een verrassend vaak voorkomende oorzaak. Voeg nofail toe aan niet-essentiële mounts, zodat de server voortaan wél opstart als zo'n schijf ontbreekt.

GRUB rescue herstellen na een mislukte update

Beland je op een grub rescue>-prompt, dan kan GRUB zijn configuratie of modules niet meer vinden. Dat gebeurt na een onderbroken update, een gewijzigde partitie-indeling of wanneer een schijf een andere volgorde krijgt.

Optie 1: Tijdelijk booten vanaf de rescue-prompt

Zoek eerst welke partitie je Linux-installatie bevat:

ls
ls (hd0,gpt2)/
set root=(hd0,gpt2)
set prefix=(hd0,gpt2)/boot/grub
insmod normal
normal

Zodra het systeem opstart, herstel je GRUB definitief, anders sta je bij de volgende reboot weer op dezelfde plek.

Optie 2: GRUB opnieuw installeren via chroot

Vanuit de chroot-omgeving uit het stappenplan hierboven:

# Debian / Ubuntu, UEFI
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
update-grub

# Debian / Ubuntu, BIOS
grub-install /dev/sda
update-grub

# RHEL / AlmaLinux / Rocky
grub2-install /dev/sda        # alleen BIOS
grub2-mkconfig -o /boot/grub2/grub.cfg

Let op: op UEFI-systemen met RHEL-familie installeer je GRUB niet opnieuw met grub2-install. Herinstalleer in plaats daarvan de pakketten grub2-efi-x64 en shim-x64 en genereer de config opnieuw.

Kernel panic oplossen: wat is het en wat doe je eraan?

Een kernel panic is de manier waarop de Linux-kernel aangeeft dat er een fout is opgetreden waar hij niet van kan herstellen. Het systeem stopt dan bewust om schade te voorkomen. Op een server zie je het meestal vlak na het opstarten, met een bericht als "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)".

Veelvoorkomende oorzaken van een kernel panic

• Defecte of ontbrekende initramfs, bijvoorbeeld na een afgebroken kernel-update.
• Ontbrekende storage-driver in de initramfs voor je RAID-controller, NVMe-schijf of virtio-disk.
• Verkeerde root-parameter in de kernel-opdrachtregel, vaak na het klonen van een VM of schijfwijziging.
• Hardwarefouten zoals defect RAM of een falende schijf.
• Incompatibele kernelmodule, zoals een third-party driver die niet meer past bij de nieuwe kernel.

Zo los je een kernel panic op

1. Kies een eerdere kernel. Ga in het GRUB-menu naar "Advanced options" en start een oudere kernelversie. Werkt die wel, dan ligt het probleem bij de nieuwe kernel of de bijbehorende initramfs.
2. Bouw de initramfs opnieuw op. Gebruik update-initramfs -u -k all (Debian/Ubuntu) of dracut -f --regenerate-all (RHEL-familie).
3. Controleer de root-parameter. Druk in GRUB op e en kijk of root=UUID=... overeenkomt met de uitvoer van blkid.
4. Test het geheugen. Start Memtest86+ en laat minimaal één volledige pass lopen. Fouten betekenen: modules vervangen.
5. Verwijder de problematische kernel. Als alles verder werkt, installeer de kernel opnieuw of blijf tijdelijk op de laatste goede versie.

Initramfs en bestandssysteem repareren

Beland je in een (initramfs)-prompt of in de "emergency shell" van systemd, dan heeft de kernel wel gedraaid maar kon hij je root-bestandssysteem niet (goed) koppelen.

Bestandssysteem controleren

Voer fsck alleen uit op een niet-gemounte partitie:

fsck -f /dev/sda2          # ext4
xfs_repair /dev/sda2       # XFS
btrfs check /dev/sda2      # Btrfs (eerst alleen lezen!)

Wees voorzichtig: een automatische reparatie op een schijf met hardwareproblemen kan data juist kosten. Is de SMART-status twijfelachtig, maak dan eerst een image.

LVM en RAID niet gevonden

Wordt je volume group niet geactiveerd? Probeer dit vanuit de live-omgeving:

vgscan
vgchange -ay
mdadm --assemble --scan

Opstartproblemen voorkomen

Je kunt niet elk probleem voorkomen, maar je kunt wel zorgen dat een storing minder pijn doet. Deze maatregelen maken het verschil tussen "binnen een uur weer online" en "een dag downtime".

• Test updates eerst op een staging-server, zeker bij kernel-, GRUB- en initramfs-updates.
• Houd minstens twee kernels geïnstalleerd, zodat je altijd kunt terugvallen.
• Gebruik nofail in /etc/fstab voor niet-kritieke mounts.
• Monitor schijfruimte, inodes en SMART-waarden en alarmeer ruim voordat een schijf vol raakt.
• Maak en test back-ups. Een back-up die je nooit hebt teruggezet, is een aanname.
• Regel remote console-toegang (IPMI, iDRAC, hoster-console) vóórdat je het nodig hebt.
• Documenteer je partitie-indeling en bootconfiguratie, zodat je bij een crash niet hoeft te raden.

Wil je dit niet zelf bijhouden? Met een SLA op maat laten wij je Linux-omgeving periodiek controleren en actief beheren, inclusief updates en monitoring.

Wanneer schakel je spoedhulp in?

Zelf proberen is prima, tot een bepaald punt. Hoe langer een productieserver stilstaat, hoe duurder het wordt, en hoe groter de kans dat een goedbedoelde poging de situatie verergert. Schakel een expert in als:

• de server bedrijfskritieke data bevat en er geen recente, geteste back-up is;
• de schijf SMART-fouten of I/O-errors toont;
• je RAID, LVM of versleutelde volumes gebruikt en de structuur niet meer herkend wordt;
• je na een uur zoeken nog steeds geen duidelijke oorzaak hebt;
• het een klantgerichte omgeving is waar elke minuut downtime geld kost;
• je vermoedt dat de storing het gevolg is van een hack of ransomware.

Bij LinuxHulp.nl verbinden onze experts op afstand met je server, stellen de diagnose en herstellen het systeem. Je krijgt daarna een rapport over wat er misging en hoe je herhaling voorkomt. Meer weten over onze tarieven voor spoedhulp? Dat staat transparant op onze site.