Aber noch was anderes: in der Grub Config werden außer bei den Recovery Optionen kein Initramfs geladen.
Ist das neu unter Ubuntu? Fehlt da das Initramfs? Ist es falsch benannt?
Ist er evtl. während des Updates des Grub-Paketes segeln gegangen und die Skripte wurden in Mitleidenschaft gezogen?
(Evtl. hilft hier im chroot ein apt-get install -f oder eine Neuausführung der apt Transaktion - so als Anregung?)
Was mir zudem aufgefallen ist, dass das sda3/boot Verzeichnis geleert wird
im fstab steht, dass an der Stelle dann sda2 eingebunden wird.
Der Installer würde SCSI Platten nie als /dev/vda anzeigen.
Welches Produkt hast du bei Netcup gebucht und wann hast du das letzte mal ein Update & Neustart gemacht?
Hier habe ich festgestellt. Das die Partitionen (sda1, sda2, sda3) standardmäßig mit dem netCup Ubuntu 2020.04 Image erstellt werden. Außerdem steht in der fstab Datei schon nach einer frischen Neuinstallation ein vda Kommentar beinhalten, obwohl standardmäßig SCSI eingestellt war.
Kann es sein, dass das so von netcup vorkonfiguriert war?
Was mir jetzt aufgefallen ist, dass der Link von initrd.img auf initrd.img-5.4.0-52-generic rot ist (s.u.)
Weiß jemand was das zu bedeuten hat?
Der symbolische Link zeigt auf eine nicht-existente Zieldatei (was das Booten des zugehörigen Kernels erwartungsgemäß verhindert). Kann es ggf. sein, dass die Partition voll ist? Erfahrungsgemäß benötigt man maximal einen zusätzlichen, bekanntermaßen funktionierenden Kernel als "Fallback"; die älteren können gelöscht werden. (Es gibt durchaus Konfigurationen, welche dazu führen, dass neue Kernel immer automatisch installiert werden, wodurch Bootpartitionen gerne einmal "vollaufen".)
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
# mount drives
# in meinem Fall war es genau wie bei OP, also sda3 war mein root drive (falls man das so nennt)
# und sda2 war die partition mit allen kerneln etc
mount /dev/sda3 /mnt/
mount /dev/sda2 /mnt/boot
# inspect my files with
ls /mnt
ls -al /boot
# check my exact OS version with
cat /mnt/etc/issue
# In meinem Fall Ubuntu 20.04.5 LTSDabei habe ich gesehen, dass das /boot Verzeichnis sehr voll ist:
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
3. Jetzt kommt die Operation
# 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/bashDa 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.
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):
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 🍉
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?
Zumindest das apt-get Frontend gibt dir einen Hinweis, welche Pakete überflüssig sind. Der Entfällt natürlich, wenn du ein anderes Frontend nutzt (z.B. apt direkt) oder unattended Upgrades nutzt.
Von einem regelmäßigen apt-get autoremove per z.B. Cronjob würde ich abraten - hier wird gerne mal zu viel entfernt.
Was ich auch oft sehe: die apt Ausgabe wird gar nicht gelesen, lest die apt Ausgabe.
Ansonsten braucht es keine Boot Partition, wenn deine Datenpartition nicht besonders ist - der Kernel kann direkt in der Datenpartition gespeichert werden.
Falls dennoch eine Datenpartition gebraucht wird, schafft ein Monitoring System oder regelmäßiges Prüfen der Dateisystembelegungen abhilfe.
Auf die schnelle reicht es eigentlich auch einen alten Kernel zu booten via grub.
Mit einem update-grup
update-grub mit B am Ende. GRand Unified Bootloader 
