Er kunnen verschillende oorzaken zijn waardoor een Linux-VPS niet langer wil opstarten en een foutmelding geeft. In de meeste gevallen komt dit door een misconfiguratie van je VPS die vaak pas later naar boven komt, bijvoorbeeld na een herstart van een VPS. Dit zijn vaak vrij technische problemen die ingewikkeld kunnen zijn om op te lossen. Een back-up herstellen is niet altijd wenselijk of mogelijk. 

In deze handleiding laten we een scala van dergelijke mogelijke problemen zien en leggen we uit hoe je die oplost.

error: file '/vmlinuz-<versie>-generic' not found. error: you need to load a kernel first

Zoals de foutmelding aangeeft kan de kernel niet gevonden worden. Normaal gesproken is de kernel terug te vinden  in de /boot/ directory.

In CentOS-stream, AlmaLinux en Rocky Linux krijg je nog iets meer tekst te zien dan in het voorbeeld hierboven, maar noteer in ieder geval de kernelversie, bijvoorbeeld: vmlinuz-5.14.0-503.26.1.el9_5.x86_64 (met een kleine L en niet een 1 na de e).

Stap 1

Ga in het TransIP-controlepaneel naar de VPS in kwestie. Klik bij de VPS-console links onderaan op de pop-out-knop:

Klik vervolgens op ‘Rescue Linux’. 

Het duurt een paar minuten voor de Rescue-modus gestart is en ziet er als volgt uit:

Stap 2

Controleer eerst welke block devices beschikbaar zijn:

lsblk

De output ziet er ongeveer als volgt uit (meestal met een vda1 en vda2 bij Red Hat-systemen):

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda     253:0    0  100G  0 disk
├─vda1  253:1    0   99G  0 part /
├─vda14 253:14   0    4M  0 part
├─vda15 253:15   0  106M  0 part /boot/efi
└─vda16 259:0    0  913M  0 part /boot

mount /dev/vda1 /mnt

mount /dev/vda2 /mnt
mkdir /mnt/boot
mount /dev/vda1 /mnt/boot

Stap 3

Mount dev, proc, sys en temp zodat je die vanuit een Chroot-omgeving kunt gebruiken (Chroot staat voor Change root en verandert de root-directory):

mount --rbind /dev /mnt/dev
mount --make-rslave /mnt/dev
mount -t proc /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --make-rslave /mnt/sys
mount --rbind /tmp /mnt/tmp

Stap 4

Chroot nu in het gemounte filesystem:

chroot /mnt /bin/bash

Stap 5

Bij sommige besturingssystemen heb je soms geen werkende internetverbinding. Controleer daarom eerst je netwerkverbinding:

ping google.com

Krijg je een foutmelding? Verwijder en maak /etc/resolv.conf opnieuw aan:

rm /etc/resolv.conf
echo "nameserver 195.8.195.8" > /etc/resolv.conf
echo "nameserver 195.135.195.135" >> /etc/resolv.conf
echo "nameserver 2a01:7c8:7000:195:0:8:195:8" >> /etc/resolv.conf

Stap 6

Herinstalleer nu je kernel package:

apt -y update
apt -y install --reinstall linux-image-<kernelversie>-generic

apt -y update
apt -y install --reinstall linux-image-6.8.0-54-generic

dnf -y reinstall kernel-core-<versie>

dnf -y reinstall kernel-core-5.14.0-503.26.1.el9_5.x86_64

dnf list kernel

Stap 7

Controleer of de Grub-configuratie ontbreekt en update Grub (dit verschilt per besturingssysteem):

ls /boot/grub/grub.cfg

update-grub

ls /boot/grub2/grub.cfg

grub2-mkconfig -o /boot/grub2/grub.cfg

Herinstalleer hierna Grub en update de configuratie:

grub-install /dev/vda
update-grub

UUID=$(blkid /dev/vda2 -o value -s UUID)
KERNELCONF=$(basename "$(ls /boot/loader/entries/*.conf | sort | tail -n 1)" .conf)
grub2-editenv - set "kernelopts=root=UUID=$UUID ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M net.ifnames=0 rhgb quiet"
sed -i "s|^options .*$|options root=UUID=$UUID ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M net.ifnames=0 rhgb quiet|" /boot/loader/entries/$KERNELCONF
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/vda
grub2-mkconfig -o /boot/grub2/grub.cfg

cat /boot/loader/entries/$KERNELCONF | grep options
grub2-editenv list

Stap 8

Sluit nu de chroot-omgeving af:

exit

Stap 9

Unmount alle mounted folders. De '-l'-toevoeging staat voor ‘lazy’ en forceert het unmounten, ook wanneer je anders een ‘busy’-foutmelding zou krijgen:

umount -l /mnt/tmp
umount -l /mnt/sys
umount -l /mnt/proc
umount -l /mnt/dev
umount -l /mnt

umount -l /mnt/tmp
umount -l /mnt/sys
umount -l /mnt/proc
umount -l /mnt/dev
umount -l /mnt/boot
umount -l /mnt

Stap 10

Herstart je VPS via de ‘Restart’-knop in de VPS-console: een reboot-commando werkt niet omdat die je naar de PXE-omgeving brengt.

That's it! Je VPS start nu weer normaal met een werkende kernel.

You are in emergency mode.

De ‘You are in emergency mode’-foutmelding is meestal het gevolg van een block storage die van je VPS ontkoppelt is, zonder de configuratie van /etc/fstab aan te passen, waarna de VPS is herstart. De volledige melding is:

You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance
(or press Control-D to continue)

Stap 1

Weet je je root-wachtwoord nog? Geef die dan nu op, zo niet, reset dan eerst je root-wachtwoord.

Stap 2

Open /etc/fstab:

nano /etc/fstab

Stap 3

De inhoud ziet er ongeveer uit zoals hieronder. Zie je hier een regel terug die verwijst naar een schijf/block storage die niet langer aan je VPS is gekoppeld (de laatste regel in dit voorbeeld)? Verwijder die, sla je wijzigingen op en sluit het bestand (ctrl + x > y > enter).

#
# /etc/fstab
# Created by anaconda on Fri Aug 12 09:46:22 2022
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=f65a405f-f0c1-4e98-b68a-71b7aebe97be /                       ext4    defaults        1 1
UUID=acd9e113-67e4-4fed-ac87-0b8c4e15c79d /boot                   ext2    defaults        1 2
/dev/vdb1 /mnt/bigstorage ext4 defaults 0 0

Herlaad alle systeembestanden en update de systemd-configuratie:

systemctl daemon-reload

Herstart tot slot je VPS:

reboot

Welcome to GRUB!

Een sympatiek bericht, maar niet degene die je verwacht. De volledige melding ziet er ongeveer als volgt uit:

Booting from Hard Hisk...
GRUB loading...
Welcome to GRUB!
error: ../.. <foutmelding>
Entering rescue mode...
grub rescue>

Deze melding geeft simpelweg aan dat er ‘iets’ mis is met Grub, bijvoorbeeld dat de Grub-configuratie verwijderd is, of een fout bevat, en je besturingssysteem niet kan starten. 

Stap 1

Ga in het TransIP-controlepaneel naar de VPS in kwestie. Klik bij de VPS-console links onderaan op de pop-out-knop:

Klik vervolgens op ‘Rescue Linux’. 

Het duurt een paar minuten voor de Rescue-modus gestart is en ziet er als volgt uit:

Stap 2

Controleer eerst welke block devices beschikbaar zijn:

lsblk

De output ziet er ongeveer als volgt uit (meestal met een vda1 en vda2 bij Red Hat-systemen):

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda     253:0    0  100G  0 disk
├─vda1  253:1    0   99G  0 part /
├─vda14 253:14   0    4M  0 part
├─vda15 253:15   0  106M  0 part /boot/efi
└─vda16 259:0    0  913M  0 part /boot

mount /dev/vda1 /mnt

mount /dev/vda2 /mnt
mkdir /mnt/boot
mount /dev/vda1 /mnt/boot

Stap 3

Mount dev, proc, sys en temp zodat je die vanuit een Chroot-omgeving kunt gebruiken (Chroot staat voor Change root en verandert de root-directory):

mount --rbind /dev /mnt/dev
mount --make-rslave /mnt/dev
mount -t proc /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --make-rslave /mnt/sys
mount --rbind /tmp /mnt/tmp

Stap 4

Chroot nu in het gemounte filesystem:

chroot /mnt /bin/bash

Stap 5

Herinstalleer Grub en update de Grub-configuratie:

grub-install /dev/vda
update-grub

UUID=$(blkid /dev/vda2 -o value -s UUID)
KERNELCONF=$(basename "$(ls /boot/loader/entries/*.conf | sort | tail -n 1)" .conf)
grub2-editenv - set "saved_entry=$KERNELCONF"
grub2-editenv - set "boot_succes=0"
grub2-editenv - set "boot_indeterminate=0"
grub2-editenv - set "kernelopts=root=UUID=$UUID ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M net.ifnames=0 rhgb quiet"
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/vda
grub2-mkconfig -o /boot/grub2/grub.cfg

Stap 6

Sluit nu de chroot-omgeving af:

exit

Stap 7

Unmount alle mounted folders. De '-l'-toevoeging staat voor ‘lazy’ en forceert het unmounten, ook wanneer je anders een ‘busy’-foutmelding zou krijgen:

umount -l /mnt/tmp
umount -l /mnt/sys
umount -l /mnt/proc
umount -l /mnt/dev
umount -l /mnt

umount -l /mnt/tmp
umount -l /mnt/sys
umount -l /mnt/proc
umount -l /mnt/dev
umount -l /mnt/boot
umount -l /mnt

Stap 8

Herstart je VPS via de ‘Restart’-knop in de VPS-console: een reboot-commando werkt niet omdat die je naar de PXE-omgeving brengt.

Gefeliciteerd! Je VPS start nu weer normaal op (mogelijk duurt dat wel even en krijg je enkele foutmeldingen die je systeem automatisch verhelpt tijdens het starten).

Probably out of disk space / <service>.service: Failed with the result ‘exit-code’.

Een dergelijke foutmelding zal niet voorkomen dat je VPS start, maar wel voorkomen dat een service zoals MariaDB kan starten. Tijdens het starten van je VPS zie je dan wellicht al in het rood een melding dat de betreffende service niet kan starten. Er kunnen meerdere oorzaken spelen, maar in dit geval gaan we uit van een gebrek aan schijfruimte. De stappen hieronder kun je echter (deels) ook voor andere oorzaken gebruiken.

Stap 1

Wanneer een service niet start, is een goede plek om te beginnen de bijbehorende logbestanden. Deze controleer je met het volgende commando, waarbij je <service> vervangt door de naam van de service, bijvoorbeeld mariadb, apache2, of httpd. 

journalctl -xe -u <service>

Stap 2

Je krijgt waarschijnlijk de nodige tekst te zien, maar het meest relevante zijn de regels waar error staat, bijvoorbeeld in dit voorbeeld van MariaDB:

The job identifier is 735.
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [Note] Starting MariaDB 11.4.5-MariaDB source revision 0771110266ff5c04216af4bf1243c65f8c67ccf4 server_uid CtPOHqBTdn3uD4>
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [Note] InnoDB: Number of transaction pools: 1
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active.
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [ERROR] InnoDB: preallocating 12582912 bytes for file ./ibtmp1 failed with error 28
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [ERROR] InnoDB: Could not set the file size of './ibtmp1'. Probably out of disk space
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [ERROR] InnoDB: Unable to create the shared innodb_temporary
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [Note] InnoDB: FTS optimize thread exiting.
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [Note] InnoDB: Starting shutdown...
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [Note] Plugin 'FEEDBACK' is disabled.
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [Note] Plugin 'wsrep-provider' is disabled.
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [ERROR] Unknown/unsupported storage engine: InnoDB
Mar 06 14:54:34 example.transip.nl mariadbd[1428]: 2025-03-06 14:54:34 0 [ERROR] Aborting
Mar 06 14:54:34 example.transip.nl systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://wiki.almalinux.org/Help-and-Support
░░
░░ An ExecStart= process belonging to unit mariadb.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Mar 06 14:54:34 example.transip.nl systemd[1]: mariadb.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://wiki.almalinux.org/Help-and-Support
░░
░░ The unit mariadb.service has entered the 'failed' state with result 'exit-code'.
Mar 06 14:54:34 example.transip.nl systemd[1]: Failed to start MariaDB 11.4.5 database server.
░░ Subject: A start job for unit mariadb.service has failed
░░ Defined-By: systemd
░░ Support: https://wiki.almalinux.org/Help-and-Support
░░
░░ A start job for unit mariadb.service has finished with a failure.
░░
░░ The job identifier is 735 and the job result is failed.

 Het onderste deel kun je negeren: de relevante meldingen hier staan in de regels waar je [ERROR] ziet. Hier is vooral de volgende melding relevant:

Could not set the file size of './ibtmp1'. Probably out of disk space

Druk nu eerst op ‘q’ om journalctl te sluiten.

Stap 3

Het is vrij eenvoudig om te controleren of er inderdaad te weinig schijfruimte is. Gebruik hiervoor het commando:

df -h

De output ziet er ongeveer als volgt uit:

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           1.8G     0  1.8G   0% /dev/shm
tmpfs           732M  8.6M  724M   2% /run
/dev/vda2       147G  139G   12M 100% /
/dev/vda1       504M  480M     0 100% /boot
tmpfs           366M     0  366M   0% /run/user/1000

Zoals je ziet is er geen ruimte in de boot-partitie en bijna geen ruimte in het filesystem (/dev/vda2). Het is nu vooral zaak om te achterhalen wat er precies veel ruimte in beslag neemt in beide, zie de volgende stap.

Stap 4

In het geval van de boot-partitie, is er een goede kans dat je nog de nodige oude kernels hebt opgeslagen. Deze zijn gelukkig eenvoudig te verwijderen als volgt:

sudo apt -y autoremove --purge

package-cleanup --oldkernels --count=2

dnf remove $(dnf repoquery --installonly --latest-limit=-2 -q)

Voor je filesystem is er eveneens een eenvoudige optie om te achterhalen wat de meeste schijfruimte in beslag neemt. Gebruik hiervoor het commando:

du -ah / 2>/dev/null | sort -rh | head -n 20

De output ziet er ongeveer als volgt uit:

127G    /
118G    /tmp
118G    /tmp/fullfile
3.2G    /usr
3.1G    /data/registry/docker/registry/v2/blobs/sha256
3.1G    /data/registry/docker/registry/v2/blobs
3.1G    /data/registry/docker/registry/v2
3.1G    /data/registry/docker/registry
3.1G    /data/registry/docker
3.1G    /data/registry
3.1G    /data
1.5G    /home/transip
1.5G    /home
1.5G    /data/registry/docker/registry/v2/blobs/sha256/68/685403537ceac572aee2828c05945053e897cce03362f0b89d2a00931f18c141/data
1.5G    /data/registry/docker/registry/v2/blobs/sha256/68/685403537ceac572aee2828c05945053e897cce03362f0b89d2a00931f18c141
1.5G    /data/registry/docker/registry/v2/blobs/sha256/68
1.5G    /data/registry/docker/registry/v2/blobs/sha256/5c/5c42024024cb80a8c37e678ad3f533112343e91ebd87e59d1796476b71435474/data
1.5G    /data/registry/docker/registry/v2/blobs/sha256/5c/5c42024024cb80a8c37e678ad3f533112343e91ebd87e59d1796476b71435474
1.5G    /data/registry/docker/registry/v2/blobs/sha256/5c

Zoals je ziet bevat  de /tmp folder 118G aan data en is er een bestand genaamd fullfile in de /tmp folder die maar liefst 118G is. Hier gaat het om een testbestand dat eenvoudig op te ruimen is:

sudo rm /tmp/fullfile

Mocht je hele directories willen verwijderen gebruik dan het commando:

sudo rm -rf <folder>

Kijk uit en verwijder op deze manier alleen custom folders die je zelf hebt aangemaakt en nooit systeemfolders zoals /boot/ of /etc/. Vervang  <folder> door het pad van de directory die je wilt verwijderen, bijvoorbeeld:

sudo rm -rf /home/transip/downloads/<folder>

Stap 5

Herstart de service die vast is gelopen door het gebrek aan schijfruimte, of beter nog je gehele VPS zodat je zeker weet dat alle services weer beschikbaar zijn:

sudo systemctl restart <service>
sudo reboot