staging.inyokaproject.org

Ubuntu Update von 18.04 auf 20.04

Status: Gelöst | Ubuntu-Version: Ubuntu 20.04 (Focal Fossa)
Antworten |

sharbich

Anmeldungsdatum:
25. September 2012

Beiträge: Zähle...

Hallo Ihr Lieben,

es ist schon wieder passiert. Immer wenn ich auf eine neue TLS Version Update habe ich kein gutes Gefühl im Magen. Als ich über die Aktuallisierungsverwaltung das Update angestoßen habe und die Pakete aktualisiert wurden kam nach dem Neustart das System nicht mehr hoch.

Ich kann nur noch im recovery mode booten.

Folgende Auswahl bekomme ich in den erweiterten Boot Otionen:

Ubuntu, mit Linux 5.4.0-60-generic
Ubuntu, mit Linux 5.4.0-60-generic (recovery mode)
Ubuntu, mit Linux 4.15.0-130-generic
Ubuntu, mit Linux 4.15.0-130-generic (recovery mode)
Ubuntu, mit Linux 4.15.0-129-generic
Ubuntu, mit Linux 4.15.0-29-generic (recovery mode)

Starte ich über den Eintrag "Ubuntu, mit Linux 5.4.0-60-generic (recovery mode)" erhalte ich die Meldung: "Kernel Offset: 0Xffff........ from 0Xfff..... .... end Kernel panic - not syncing: VFS. Unable to mount root fs on unknown-block(0,0) ..."

Starte ich über den Eintrag "Ubuntu, mit Linux 4.15.0-130-generic" läuft der boot Prozess an und bei "Network Time Synchronization", bzw wait for Network to be configured (.... / no limit) dauert es sehr lange bis es weiter geht. Schließlich endet der boot Prozess in einem schwarzen Bildschirm.

Einzig über den Start Eintrag "Ubuntu, mit Linux 4.15.0-130 (recovery mode) kann ich den Rechner noch im Wiederherstellungsmenü starten.

Ich brauche Unterstützung von Euch.

Lieben Gruß von Stefan Harbich

von.wert

Anmeldungsdatum:
23. Dezember 2020

Beiträge: 7756

sharbich schrieb:

Immer wenn ich auf eine neue TLS Version Update habe ich kein gutes Gefühl im Magen.

Und warum machst Du's dann so? 😉

wait for Network to be configured (.... / no limit) dauert es sehr lange bis es weiter geht.

Da offensichtlich Netzwerk nicht mehr funktionierend.

Schließlich endet der boot Prozess in einem schwarzen Bildschirm.

Aber das ist ja nun eine Sache, die temporär behebbar wäre. Starte mit den Bootoptionen "nomodeset xforcevesa". Sieht dann natürlich auch so aus, macht aber erstmal nichts.

von.wert

Anmeldungsdatum:
23. Dezember 2020

Beiträge: 7756

Behebbar wird die Geschichte schon sein, schließlich sind wir hier bei Linux, die Frage ist nur, mit welchem zeitlichen Aufwand. Ein Distupgrade von einer Version mit versprochenem längeren Support für main und restricted auf die nächste dieser Art ist keine gute Idee. Zuviel ist da teilweise grundlegend geändert worden, daß es ohne Haken abläuft. Ist dann noch anderes 'reingebracht worden, kommt das hinzu.

Will sagen, selbst wenn Du dieses erste Problem löst, können durchaus noch weitere auf Dich warten.

Da Du als gebranntes Kind ja sicherlich eine separate Partition für /home hast, wäre eine saubere Neuinstallation unter Erhalt und mit Einbinden des jetzigen /home ratsam.

Hast Du doch - oder? 😎

sharbich

(Themenstarter)

Anmeldungsdatum:
25. September 2012

Beiträge: 63

Hallo Ihr Leben, hier die Lösung:

* Halten Sie während des Startvorgangs die UMSCHALTTASTE gedrückt, um das GRUB-Menü aufzurufen
   (es wird jedoch nach dem ersten fehlgeschlagenen Start automatisch angezeigt).
 * Wählen Sie "Erweiterte Optionen für Ubuntu"
 * Wählen Sie den älteren Kernel im Wiederherstellungsmodus (Linux 5.3.0-51-generic 
  (Wiederherstellungsmodus)).
 * Wählen Sie im Wiederherstellungsmenü "dpkg - Defekte Pakete reparieren".
 * Starten Sie nach der Reparatur neu. Halten Sie die UMSCHALTTASTE erneut gedrückt
 * Wählen Sie nun erneut "Erweiterte Optionen für Ubuntu" / älteren Kernel, diesmal OHNE 
   Wiederherstellungsmodus
 * Das System sollte jetzt ordnungsgemäß mit der GUI starten. uname -a zeigt den alten Kernel an
 * Danach Eeinfach neu starten
 * Das System sollte jetzt auf magische Weise mit der GUI und dem neuen 5.4.0-Kernel booten

Danach lief wieder alles wie gewohnt. Super.

Gruß von Stefan

Antworten |