Τι να κάνω αν το VPS μου δεν εκκινεί (kernel, filesystem & mount errors);

Υπάρχουν διάφοροι λόγοι για τους οποίους ένα Linux VPS ενδέχεται να μην εκκινεί πλέον και να εμφανίζει μήνυμα σφάλματος. Στις περισσότερες περιπτώσεις, αυτό οφείλεται σε εσφαλμένη ρύθμιση (misconfiguration) του VPS, η οποία συνήθως γίνεται αντιληπτή αργότερα — για παράδειγμα, μετά από μια επανεκκίνηση. Αυτά τα προβλήματα είναι συχνά τεχνικά και μπορεί να είναι περίπλοκα στην επίλυσή τους. Η επαναφορά ενός backup δεν είναι πάντα επιθυμητή ή εφικτή.

Σε αυτόν τον οδηγό παρουσιάζουμε μια σειρά από πιθανά προβλήματα και εξηγούμε πώς να τα επιλύσεις.

Σημαντικό: Δημιούργησε ένα snapshot του VPS σου πριν ξεκινήσεις τα βήματα του οδηγού, ώστε να έχεις ένα αντίγραφο ασφαλείας σε περίπτωση που κάτι πάει στραβά.

CentOS Stream / AlmaLinux / Rocky Linux: Σε ορισμένες περιπτώσεις, το SELinux απαιτεί μια διαδικασία “relabel” μετά τις αλλαγές. Αφού ολοκληρώσεις τα βήματα του άρθρου, χρησιμοποίησε την εντολή journalctl για να ελέγξεις αν υπάρχει σχετικό μήνυμα. Αν ναι, εκτέλεσε την εντολή που προτείνεται (συνήθως sudo touch /.autorelabel; reboot).

---

Εκκίνηση σε λειτουργία Linux Rescue Mode

Πολλά από τα σφάλματα που περιγράφονται σε αυτό το άρθρο απαιτούν την είσοδο σε λειτουργία Rescue Mode για να επιλυθούν. Μπορείς να εκκινήσεις το VPS σου σε Linux Rescue Mode ακολουθώντας τα παρακάτω βήματα:

Βήμα 1

Συνδέσου στο control panel, κάνε κλικ στο “VPS” και στη συνέχεια αναζήτησε ή επίλεξε το όνομα του επιθυμητού server.

Βήμα 2

Στο VPS console, κάνε κλικ στο “Boot in rescue”.

Θα εμφανιστεί ένα παράθυρο. Βεβαιώσου ότι έχει επιλεγεί το “RescueLinux” και στη συνέχεια κάνε κλικ στο “Boot image”.

Βήμα 3

Κάνε κλικ στο κουμπί “pop-out” κάτω δεξιά για να ανοίξει η κονσόλα σε νέο παράθυρο. Έτσι θα είναι πιο εύκολο να κάνεις αντιγραφή-επικόλληση εντολών χρησιμοποιώντας την επιλογή “Paste in console”.

Η λειτουργία Rescue θα χρειαστεί λίγα λεπτά για να ξεκινήσει. Μπορεί να δεις ένα μήνυμα όπως το παρακάτω:

error: file '/vmlinuz-&lt;version&gt;-generic' not found.<br>error: you need to load a kernel first

Όπως υποδεικνύει το μήνυμα, ο kernel δεν μπορεί να εντοπιστεί. Συνήθως βρίσκεται στον φάκελο /boot/.

Πριν συνεχίσεις, σημείωσε την έκδοση του kernel που εμφανίζεται στο μήνυμα — π.χ. 6.8.0-54 στο μήνυμα error: file '/vmlinuz-6.8.0-54-generic' not found.

Σε CentOS Stream, AlmaLinux και Rocky Linux ενδέχεται να εμφανίζεται περισσότερη πληροφορία, αλλά σε κάθε περίπτωση σημείωσε την έκδοση kernel — π.χ. vmlinuz-5.14.0-503.26.1.el9_5.x86_64.

---

Διαδικασία Επαναφοράς Βήμα-Βήμα

Βήμα 1

Εκκίνησε το VPS σε Linux Rescue Mode, όπως περιγράφηκε παραπάνω.

Βήμα 2

Έλεγξε ποια block devices είναι διαθέσιμα:

lsblk

Η έξοδος της εντολής θα μοιάζει κάπως έτσι:

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

Ubuntu / Debian:

mount /dev/vda1 /mnt

CentOS Stream / AlmaLinux / Rocky Linux:

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

Βήμα 3

Κάνε mount τους φακέλους dev, proc, sys και tmp ώστε να μπορούν να χρησιμοποιηθούν από το περιβάλλον chroot:

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

Βήμα 4

Εισήλθε στο chroot περιβάλλον:

chroot /mnt /bin/bash

Βήμα 5

Επανεγκατέστησε το GRUB και ενημέρωσε τη ρύθμιση εκκίνησης.

Ubuntu / Debian:

grub-install /degrub-install /dev/vda
update-grub

CentOS Stream / AlmaLinux / Rocky Linux:

UUID=$(blkid /dev/vda2 -o value -s UUID) KERNELCONF=$(basename "$(ls 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

Για να ελέγξεις ότι οι μεταβλητές έχουν οριστεί σωστά:

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

Η μεταβλητή kernelopts πρέπει να υπάρχει, καθώς είναι απαραίτητη για επιτυχή εκκίνηση.

Βήμα 6

Έξοδος από το chroot:

exit

Βήμα 7

Κάνε unmount όλους τους φακέλους. Η επιλογή -l (“lazy”) εξαναγκάζει την αποσύνδεση ακόμη και αν προκύψει σφάλμα “busy”.

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

Βήμα 8

Επανεκκίνησε το VPS μέσω του κουμπιού “Restart” στο control panel. Η εντολή reboot δεν λειτουργεί σε rescue mode.

Αποτέλεσμα: Το VPS σου θα πρέπει τώρα να εκκινεί κανονικά (ενδέχεται να χρειαστούν μερικά λεπτά).

---

Πιθανή έλλειψη χώρου στο δίσκο / <service>.service: Failed with the result ‘exit-code’.

Ένα τέτοιο μήνυμα σφάλματος συνήθως δεν εμποδίζει την εκκίνηση του VPS, αλλά μπορεί να αποτρέψει την εκκίνηση μιας υπηρεσίας (όπως η MariaDB). Κατά τη διάρκεια της εκκίνησης, μπορεί να εμφανιστεί ένα κόκκινο μήνυμα που αναφέρει ότι η συγκεκριμένη υπηρεσία απέτυχε να ξεκινήσει. Μια πιθανή αιτία είναι η έλλειψη διαθέσιμου χώρου στο δίσκο. Τα παρακάτω βήματα μπορούν να σε βοηθήσουν να εντοπίσεις και να επιλύσεις το πρόβλημα.

Βήμα 1

Όταν μια υπηρεσία δεν ξεκινά, ένα καλό πρώτο βήμα είναι να ελέγξεις τα σχετικά αρχεία καταγραφής (logs). Μπορείς να το κάνεις με την παρακάτω εντολή, αντικαθιστώντας το <service> με το όνομα της υπηρεσίας (π.χ. mariadb, apache2 ή httpd):

journalctl -xe -u <service>

Βήμα 2

Η εντολή θα εμφανίσει πολλές πληροφορίες, αλλά οι πιο σημαντικές είναι οι γραμμές που περιέχουν τη λέξη [ERROR]. Για παράδειγμα, σε ένα σφάλμα MariaDB, μπορεί να εμφανιστεί μήνυμα όπως:

[ERROR] InnoDB: preallocating 12582912 bytes for file ./ibtmp1 failed with error 28 [ERROR] InnoDB: Could not set the file size of './ibtmp1'. Probably out of disk space 
[ERROR] InnoDB: Plugin initialization aborted with error Generic error 
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 
[ERROR] Unknown/unsupported storage engine: InnoDB 
[ERROR] Aborting

Η πιο κρίσιμη γραμμή είναι η εξής:

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

Αυτό υποδεικνύει ότι ο δίσκος είναι γεμάτος και δεν υπάρχει διαθέσιμος χώρος για να λειτουργήσει σωστά η υπηρεσία.

Βήμα 3

Για να ελέγξεις τον διαθέσιμο χώρο στο δίσκο, εκτέλεσε:

df -h

Η έξοδος θα μοιάζει κάπως έτσι:

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

Όπως φαίνεται, τόσο το κύριο filesystem (/) όσο και το /boot partition δεν έχουν καθόλου διαθέσιμο χώρο. Το επόμενο βήμα είναι να εντοπίσεις ποια αρχεία ή φάκελοι καταλαμβάνουν τον περισσότερο χώρο.

Βήμα 4

Για το /boot partition, είναι πιθανό να υπάρχουν αποθηκευμένοι παλαιοί kernels που δεν χρειάζονται πια. Μπορείς να τους αφαιρέσεις ως εξής:

Ubuntu / Debian:

sudo apt -y autoremove --purge

CentOS / AlmaLinux / Rocky Linux:

package-cleanup --oldkernels --count=2

Η παραπάνω εντολή διαγράφει τους παλιούς kernels και διατηρεί τους δύο πιο πρόσφατους. Αν λάβεις μήνυμα ότι το απαιτούμενο πακέτο δεν είναι εγκατεστημένο και δεν έχεις καθόλου χώρο για να το εγκαταστήσεις, μπορείς να χρησιμοποιήσεις την εναλλακτική εντολή:

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

Για να εντοπίσεις τι καταλαμβάνει περισσότερο χώρο στο σύστημα αρχείων, χρησιμοποίησε:

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

Η εντολή αυτή εμφανίζει τους 20 μεγαλύτερους φακέλους ή αρχεία. Για παράδειγμα:

127G / 
118G /tmp 
118G /tmp/fullfile 
3.2G /usr 
3.1G /data/registry/docker/registry/v2/blobs/sha256 
...

Εδώ βλέπουμε ότι ο φάκελος /tmp περιέχει ένα αρχείο fullfile μεγέθους 118GB, το οποίο μπορεί να διαγραφεί με ασφάλεια:

sudo rm /tmp/fullfile

Αν θέλεις να διαγράψεις έναν ολόκληρο φάκελο, χρησιμοποίησε:

sudo rm -rf <folder>

Προσοχή: Μην διαγράφεις φακέλους συστήματος όπως /boot/ ή /etc/. Χρησιμοποίησε την εντολή μόνο για προσωρινούς ή προσωπικούς φακέλους, π.χ. /home/username/example/.

Βήμα 5

Αφού ελευθερώσεις χώρο, επανεκκίνησε την υπηρεσία που είχε σταματήσει ή, ακόμα καλύτερα, επανεκκίνησε ολόκληρο το VPS για να επανέλθουν όλες οι υπηρεσίες.

sudo systemctl restart <service>
sudo reboot

Μετά την επανεκκίνηση, η υπηρεσία θα πρέπει να ξεκινήσει κανονικά και το VPS να λειτουργεί χωρίς προβλήματα.