Beiträge von DesperateCookie

    Ich bin genau auf dasselbe Problem wie OP gestoßen und habe es heute geschafft das Problem zu lösen. Da ich viel von diesem (und anderen Forenbeiträgen) profitiert habe in dieser Sache, wollte ich etwas von dem zurückgeben und poste hier meine (etwas ausführlichere und zusammenhängende) Anleitung, wie ich das Problem gelöst habe. Da ich in diesem Thema auch eher noch ein Anfänger bin, schreibe ich es etwas ausfürhlicher.


    1. Zuerst habe ich das RecoveryOS im Server Control Panel (SCP) angestellt, den Server neugestartet und mich dort mal ein bisschen umgeschaut

    Dabei habe ich gesehen, dass das /boot Verzeichnis sehr voll ist:

    Untitled2.png



    2. Da ich mir nicht sicher war, ob es schlau ist, den update-initramfs befehl in dem RecoveryOS (das heißt übrigens grml und basiert auf debian) auszuführen, habe ich mich entschieden wie OP das passende Linux Desktop image runterzuladen und als DVD einzubinden. Ich habe es auch mit den vorinstallierten Images versucht, die im SCP zu finden sind, aber die schienen keine "Try Ubuntu" Funktion zu besitzen und wollten sich voll installieren. Daher habe ich folgendes gemacht

    • Herunterladen vom passenden Image (in meinem Fall ubuntu-20.04.5-desktop-amd64.iso)
    • Hochladen ins SCP (hier muss man den FTP Zugang benutzen, der unter SCP -> Medien -> DVD-Laufwerk -> FTP Zugang zu finden ist. Hier hochladen in das /cdrom Verzeichnis
    • Dann das Image auswählen und reinbooten, Try Ubuntu wählen und Terminal öffnen

    3. Jetzt kommt die Operation

    Code
    # Jetzt wieder die partitionen mounten wie oben
    mount /dev/sda3 /mnt/
    mount /dev/sda2 /mnt/boot
    
    # Dann weiter mit den anderen commands von diesem Thread
    sudo mount -t proc /proc /mnt/proc
    sudo mount --rbind /sys /mnt/sys
    sudo mount --rbind /dev /mnt/dev
    sudo chroot /mnt/ /bin/bash


    Da ich vorher schon beim inspizieren meines /boot-Verzeichnisses herausgefunden habe, dass mein Problem bei dem 5.4.0-139-generic Kernel liegt, habe ich es an dieser Stelle habe ich es mit update-initramfs -u -k 5.4.0-139-generic Befehl versucht. Dabei bekam ich folgende Fehlermeldung: Untitled3.png

    Durch ein wenig Recherche habe ich herausgefunden wo das Problem liegt.


    4. Das Problem

    Der essentielle Teil der Fehlermeldung ist cannot write compressed block. Vielleicht ist die Partition voll und es gibt keinen Speicherplatz, um die Datei zu erzeugen? Das habe ich kurz per df bestätigt und einen use von 100% festgestellt.

    Untitled4.png


    Damit hat sich auch die Lösung des Problems offenbart: Ein paar Kernels löschen und dann sollte alles wieder laufen. Aber wie macht man das möglichst sicher? Da ich aufgrund von mangelnder Erfahrung Sorge hatte etwas kaputt zu machen, habe ich mich gegen die Verwendung von rm oder sudo apt autoremove --purge entschieden und mit folgendem Befehl ein paar alte Kernel gelöscht (welche ich per ls -al /boot gefunden habe):

    Code
    sudo apt purge linux-image-5.4.0-110-generic linux-image-5.4.0-120-generic linux-image-5.4.0-122-generic 

    Nach drei vier Kerneln war dann genug Platz und der sudo apt purge Befehl hat dann auch selbstständig ein update-initramfs von meinem neusten Kernel nachgeholt. Das verlief auch erfolgreich.


    Mit einem update-grup, dem Entfernen der DVD und einem Neustart war dann alles wieder repariert! 🎉🎉


    5. Was lernen wir hieraus?

    Das Boot Verzeichnis kann voll-laufen und zu genau diesem Problem führen. Daher ist es sinnvoll, alte Kernel regelmäßig zu löschen. Dafür gibt es einen Command: sudo apt autoremove --purge, den man immer mal wieder ausführen sollte. Diesen habe ich bei mir ausgeführt und konnte dadurch den Großteil meinem Boot-Verzeichnisses leeren.


    Meine Frage an die Profis: Gibt es eine automatische Art und Weise, diesen Befehl immer mal wieder durchlaufen zu lassen? Was ist hier das Best-Practise?


    Ich hoffe diese Anleitung hilft irgendjemandem in der Zukunft mal weiter, so wie dieser Forum Thread mir weitergeholfen hat.

    Viele Grüße 🍉