Ha! Ihr dachtet, der Tag würde nie kommen, aber hier ist eine Lösung für ein Ubuntu Problem 😀
Ich hatte meine Ubuntu LAD TestVM von 22 auf 24 aktualisiert und bin dabei in einen Bootloop gelaufen. Nach 3h30m lief die VM wieder. Keine Panik, der Fix selbst dauert nur 20-30 Minuten.
Ubuntu 24: Nach Upgrade den Bootloop fixen
Das alles spielte sich an einem Linux am Dienstag Abend am 1.April 2025 ab. Weil ein Laptop keine Updates mehr wollte, wir aber nichts davon sehen konnten in der Videokonferenz, dachte ich mir: fahr doch Deine Ubuntu VM hoch, dann kann man sehen, was bei den Befehlen, die genannt wurden, rauskommen sollte. Als das soweit gelöst war, sind wir hier gelandet:
Ausgangslage: Eine Ubuntu 22 LTS Installation wird mit do-release-upgrade auf Ubuntu 24 aktualisiert. Nach ca. 500 von 2.000 Updateschritten rebootet sich die VM einfach, wobei anzumerken ist: Das war kein Reset, sondern ein echter Reboot, weil die VM runtergefahren ist. Das konnte man sehen. Danach kam es zu einem Endlos-Boot-Loop.
Whom to blame: Wer auch immer das do-release-upgrade Script geschrieben hat!
Wie fixt man das jetzt?
Jetzt gibt es mehrere Weg das zu beheben und auch mehrere Szenarien zu durchdenken.
a) Wir haben ein leeres Ubuntu System vor uns, da lohnt sich eine Reparatur gar nicht, weil eine Neuinstallation einfacher und schneller geht.
b) Wir haben ein Backup unseres Systems und der Homepartition, da würde würde ich einem unerfahrenen Admin auch raten: Neuinstallation und Restore des Backups.
c) Wir haben eine VM vor uns, aber kein Backup und jede Menge Änderungen am System vorgenommen, an die sich keiner mehr erinnern kann, die aber alle wichtig sind, und können eine Live-Disk von unserer Lieblingsdistro einlegen und booten.
d) wir hängen nur mit einer wackeligen SSH Verbindung auf einem Rescuesystem eines Bare-Metall Servers in Tokio, sprechen kein Wort Japanisch, haben auch kein Backup oder die Möglichkeit ein Live-Image von Ubuntu einzulegen, geschweige denn den Monitor davon zu sehen.
Wir gehen jetzt mal von Szenario D aus, sonst macht das eh keinen Spaß und den hatten wir, weil unsere Aktion bis 1:30 lief 😀
Das wichtigste dabei ist aber: Man lernt nichts, wenn man den schmerzlosen Weg geht.
Und hier ging es um nichts. Ob die VM lebt oder neuinstalliert wird, völlig egal. Ingenieuren auf der ganzen Welt ist gemein, daß die alle wissen wollen, wie was funktioniert und Spaß daran haben neues auszuknobeln oder Probleme zu lösen. Wenn das nicht so wäre, wäre das Leben total langweilig.
Und so haben wir das gemacht
Ich schreibe extra „wir“, weil das ja ein Linux am Dienstag Abend war und Orloff und Anturix bis 1h30 mitgefiebert haben, weil die auch für das Problem leben 😉
Das erste was man macht, ist ein Rescue System booten. Das kann ein Live Image sein, oder echt nur so eine Remote-Shell Umgebung wie Busybox. In unserem Fall war es eine Fedora Live-Disk. Mit deren Hilfe bauen wir uns eine Chroot Umgebung zusammen.
Rausfinden was was ist
$ cat /proc/partitions
major minor #blocks name
11 0 2400574 sr0
252 0 26214400 vda
252 1 1024 vda1
252 2 525312 vda2
252 3 25686016 vda3
7 0 2206704 loop0
251 0 3997696 zram0
VDA ist hier die Platte der VM, vda1 ist die EFI Partition, vda2 ist Boot und vda3 ist das Rootfilesystem.
Das alte System erreichen
Das letztere brauchen wir definitiv. Wenn aber noch Updates aussehen sollten, die z.b. eine neue Bootkonfiguration erzeugen, dann brauchen wir ein komplettes System und das geht so:
su
cd /mnt/
mkdir root
mount /dev/vda3 root
mount /dev/vda2 root/boot
mount /dev/vda3 root/boot/efi
mount -o bind /proc root/proc
mount -o bind /sys root/sys
mount -o bind /dev root/dev
chroot root
Jetzt sind wir root auf der Ubuntu Seite, so als wenn das System gebootet wäre.
Jetzt checken wir ob apt noch geht:
apt list –upgradeable
kommt dabei noch etwas sinnvolles raus, dann führen wir das aus:
apt list –upgradeable | sed -e „s/\/.*$//g“ | awk ‚{print „apt download „$1;}‘ | bash
Das lädt uns alle noch ausstehenden Updatepakete herunter. Es bietet sich an, das in einem eigenen Verzeichnis zu machen, z.b. /root/down ( vorher anlegen ).
Hinweis: Falls ihr hier an dieser Stelle apt install -f oder apt dist-upgrade o.s.ä. erwartet.. DEPENDENCY MISMATCH Fehler so weit der Bildschirm reicht. Kein Trick, wie man ein System sonst so wieder behebt, funktioniert hier, oder was glaubt Ihr, was wir in 3h so alles ausprobiert haben? 😀
Jetzt installieren wir auf Teufel komm raus, alle Pakete, die sich ohne Abhängigkeitsprobleme installieren lassen:
dpkg -i *deb
Das dauert ein Weilchen, genau wie der Download per apt.
Jetzt gibt es zwei Möglichkeiten: apt geht, oder es geht nicht. In unserem Fall ging apt nicht. d.h. wenn Euer apt noch geht, könnt Ihr direkt zum Ende, dem Final Fix springen. Also einfach mal apt aufrufen: apt list
Die Launchpad Webseite
Unser apt meckert, daß eine Library fehlt, die war aber in dem neuen apt Paket drin, das nicht komplett eingespielt wurde. Da kommt Lauchpad ins Spiel. Dort liegen, wenn auch etwas umständlich organisiert, alle Pakete der Distro rum. Alles was uns fehlt, kann einfach runtergeladen werden:
ACHTUNG: Das sind die Versionen und Links mit Stand 1.4.2025.. am 2.4.2025 hatte sich das schon alles geändert haben können. Copy & Paste wird nicht funktionieren!
wget http://launchpadlibrarian.net/680067795/apt_2.7.3_amd64.deb
wget http://launchpadlibrarian.net/722297727/libapt-pkg6.0t64_2.7.14build2_amd64.deb
dpkg -i libapt-pkg6.0t64_2.7.14build2_amd64.deb
dpkg –ignore-depends=all -i apt_2.7.14build2_amd64.deb
hier zerbricht dann apt völlig, weil die jetzt neue Version andere Dinge nicht findet, aber das ist nicht tragisch, weil wir haben ja alle Pakete auf Platte liegen 😉
dpkg -i libdebconfclient0_0.271ubuntu3_amd64.deb
dpkg -i base-passwd_3.6.3build1_amd64.deb
dpkg –configure -a
dpkg -i apt_2.7.14build2_amd64.deb
wget http://launchpadlibrarian.net/722115887/libnpth0t64_1.6-3.1build1_amd64.deb
dpkg –auto-deconfigure -i gpgv_2.4.4-2ubuntu17_amd64.deb libassuan0_2.5.6-1build1_amd64.deb libbz2-1.0_1.0.8-5.1build0.1_amd64.deb libnpth0t64_1.6-3.1build1_amd64.deb
dpkg -i apt_2.7.14build2_amd64.deb
dpkg –auto-deconfigure -i libapt-pkg6.0t64_2.7.14build2_amd64.deb
dpkg -i libapt-pkg6.0t64_2.7.14build2_amd64.deb liblz4-1_1.9.4-1build1.1_amd64.deb libsystemd0_255.4-1ubuntu8.6_amd64.deb libudev1_255.4-1ubuntu8.6_amd64.deb libxxhash0_0.8.2-2build1_amd64.deb libcap2-bin_1%3a2.66-5ubuntu2.2_amd64.deb
wget http://launchpadlibrarian.net/668387730/libcap2_2.66-4ubuntu1_amd64.deb
dpkg -i libapt-pkg6.0t64_2.7.14build2_amd64.deb liblz4-1_1.9.4-1build1.1_amd64.deb libsystemd0_255.4-1ubuntu8.6_amd64.deb libudev1_255.4-1ubuntu8.6_amd64.deb libxxhash0_0.8.2-2build1_amd64.deb libcap2_2.66-4ubuntu1_amd64.deb
Jetzt läuft apt wieder \o/
The Final Fix
Es ist soweit, apt kann seine Angelegenheiten selbst fixen:
apt install -f
apt upgrade
apt autoremove
exit
reboot
Kleine Anekdote für Ubuntu Forums User
Ihr hattet in Eurem Support Forum diese Anleitung am 2.4.2025 um Punkt 2 Uhr MESZ .
Zwischen 2 Uhr und 8 Uhr morgens hat ein kleingeistiger Moderator oder ein Script, den Beitrag und meinen extra dafür angelegten Account pseudo gebannt. D.h. die betreffende Person, die um Hilfe gerufen hat, weil Ihr das gleiche passiert sein dürfte beim Upgrade, die mußte Ihr System neu installieren, weil 8 andere Typen in dem Forum alle im Chor gesungen haben: Installiere das Neu, das kann man nicht beheben. Da mußten erst Fedora Fanboys kommen und Ihren Ubuntu Brüdern helfen 😉
An den Kleingeist: Das Fedora Linux am Dienstag Team ist stink sauer, der User ist stinksauer wenn er davon erfährt und Du solltest Deinen Job an den Nagel hängen Mod! Wer eine funktionierende Lösung für ein existierendes schweres Problem bannt, weil x Links zu Launchpad da drin sind, es aber kein Spam ist und der Ton des Posters ein bisschen überschwänglich ist, es war 2 Uhr und eine echte Herausforderung für DNF Verwöhnte, der ist ungeeignet für den Moderator Job.
Merke: Kommt lieber zu uns ins Matrix, da wird Euch geholfen!
Hier wurde die Lösung gepostet, falls ein anderer Mod mal nachsehen will: https://discourse.ubuntu.com/t/stuck-at-boot-after-upgrade-to-24-04/58107
Da ich mit dem Account nicht mehr am Forum teilnehmen durfte, denn ein Forum-Login war damit nicht mehr möglich, habe ich den Ubuntu Account wieder gelöscht. Erwartet also in Zukunft keine Hilfe mehr von mir.
