Ubuntu: PC bleibt beim Booten hängen nach /dev/sda: [zahlen]

[MagicEye04]

Erstmal die Vorgeschichte:

Alter PC mit Ryzen1700 und Asus Prime B350M-A, als Vorbereitung des Hardware-upgrades habe ich apt-get update und apt-get upgrade durchgeführt, Ziel war, von Ubuntu18LTS auf 20LTS zu kommen. Bereits nach dem update/upgrade kam der Fehler, noch mit Ubuntu18.04.4(oder5)

Hm, irgendwie bin ich jetzt schwer enttäuscht von Ubuntu.
Das update, was ich gerade durchgeführt habe, hat noch den Kernel 4.15.0~117 installiert.
Aber beim Neustart lande ich in einer Endlos-Schleife, aus der es nicht mehr raus geht.
Auch die vorherigen Kernel 109 oder 108 führen zu dem gleichen Ergebnis.
Ich kann gerade noch was von clean auf einer Partition lesen, dann start user manager, stop user manager, restart (also kein Reboot, aber irgendeine Art von Restart).
Bei einem upgrade von 18 auf 20 hätte ich sowas vielleicht noch erwartet. Aber doch nicht beim normalen update als Vorbereitung darauf.
Keine Ahnung, ob vielleicht der AMDGPUpro-Treiber mit 18.04.5 nicht klarkommt, der mag ja immer nur bestimmte Versionen...
Dann halt gleich neu installieren und hoffen, dass ich aus dem Backup möglichst viele Einstellungen heraus retten kann.

Also habe ich die Hardware gewechselt auf Ryzen 3950X und Asus Prime B550-Plus

Hm... bei mir hat Xubuntu irgendwann auf den 5er Kernel gewechselt, vom 4.15er weg.

Du könntest versuchen dich in das alte System von einem Stick oder einer CD aus zu analysieren, Logfiles, dmesg ect. und dann versuchen das Problem abzustellen. Aber wenn du ohnehin neu installieren willst um Altlasten loszuwerden, lohnt sich der Aufwand vielleicht garnicht.

Da ist er plötzlich wieder - der gleiche Fehler, der schon meine alte Installation abgeschossen hat.
Heute mittag hab ich den Rechner heruntergefahren, jetzt fahre ich hoch und er bleibt wieder hängen bei:
"/dev/sda7: clean x/y files, x/y blocks".
Zwar nicht in einer Endlosschleife, ich konnte also die Fehlermeldung endlich mal aufschreiben. Aber genau da hat sich auch der alte Rechner verabschiedet.
Wenn ich dann ON/OFF drücke, wechselt der Bildschirm kurioserweise in den grafischen Modus und zeigt das Ubunutu-Logo, bevor es den Rechner abschaltet.
Ich hab ja nun Mainboard, CPU und Netzteil gewechselt.
Was geblieben ist, ist die MX500. Auf die alte Partition habe ich einfach das vorherige Ubuntu18 formatiert und die 20 draufgespielt.
Auch jetzt startet er mit dem vorherigen Kernel nicht.
Ich fürchte, ich muss doch mal irgendwie Fehlersuche betreiben, wenn selbst eine Neuinstallation nicht geholfen hat.
Es liegt ja hoffentlich nicht daran, dass ich gnome-keyring deinstalliert hatte - der hat ständig nach einem Passwort gefragt und damit das automatische Runterfahren blockiert. Da ich keinen Passwortspeicher brauche auf dem Rechner, flog es kurzerhand weg.

Ich könnte jetzt sagen, ich wollte sowieso alles noch mal neu installieren - es sind einfach zu viele Partitionen auf der SSD, die Aufteilung ist im Laufe der Jahre chaotisch gewachsen. Aber ich fürchte, der Fehler wird auch dann zurückkommen...

Erstmal schauen, ob Crystal was zu der SSD sagt - nix, 96% Lebensdauer, alles bestens.

Als Hilfestellung erhielt ich ja schon:

@MagicEye04 Du kannst mal folgendes Probieren:
Wenn dein Computer diese clean/blocks/files Message Anzeigt (was an sich kein Fehler ist, im gegenteil, es besagt, dass eben kein Dateisystemfehler vorliegt) versuche mal, ob du mittels Ctrl+Alt+F1-F7 einen login auf die Konsole bekommst. Dort kannst du dich dann einloggen und in den Logfiles wühlen.
Recovery mode sollte auch funktionieren, um zumindest einw funktionierende Shell zu bekommen.

Da es bei aber offenbar am Grafischen Modus hapert, würde ich dort versuchen mit "sudo apt-get purge (paketname Grafiktreibers) (z.B. "sudo apt-get purge nvidia* " oder wie das auch immer bei dir heißt) den Grafiktreiber zu killen.

Was du noch probieren könntest wäre beim Bootvorgang in grub eine Änderung an den Parametern vorzunehmen von "quiet" auf "nomodeset" oder, ist ja wohl eine AMD, mit "radeon.modeset=0", wie hier beschrieben: https://askubuntu.com/questions/162...black-screen-what-options-do-i-have-to-fix-it
Das hat bei mir die Tage geholfen um einen alten iMac mit Ubuntu zum Starten zu bewegen.

Wir können das auch gern in einen extra Thread auslagern.

[automerge]1600458026[/automerge]
@Riddler82 : Ich lagere dann mal aus.

So, weiter gehts.
Heute habe ich mal gebootet und über das Bootmenu recovery ausgewählt, um auf die Kommandozeile zu gelangen.
Dort habe ich den Grafiktreiber deinstalliert. Es war der amdgpu-pro 20.30 drauf. Installiert wurde er jeweils mit dem mitgelieferten Script. Hat ja auch etliche Bootvorgänge lang problemlos funktioniert. Deinstalliert wurde er ebenfalls per mitgeliefertem Script.
Die Deinstallation brachte allerdings keine Besserung, der PC bleibt nach wie vor der clean-Ausgabe von sda7 (was die Ubuntu-Partition ist) hängen.

Ich würde ja jetzt gerne in Logfiles wühlen, nur bin ich in dieser Hinsicht komplett ohne Wissen.
Wo liegen die relevanten Logfiles?
Welche sollte ich angucken ?
Wonach soll ich suchen?
[automerge]1600460009[/automerge]
Der Vollständigkeit halber noch die Partitionsanordnung.

[automerge]1600460330[/automerge]
Ich hab mir gerade die var/log/boot.log angeschaut.
Das sind die letzten Zeilen:

[[0;32m OK [0m] Started [0;1;39mLSB: Record successful boot for GRUB[0m.
[[0;32m OK [0m] Started [0;1;39mLSB: automatic crash report generation[0m.
[[0;32m OK [0m] Finished [0;1;39mDetect the available GPUs and deal with any system changes[0m.
Starting [0;1;39mLSB: GNOME Display Manager[0m...
[[0;32m OK [0m] Started [0;1;39mLSB: GNOME Display Manager[0m.

Könnte das also ein Problem mit Gnome sein?
[automerge]1600460704[/automerge]
var/log/syslog sieht zum fraglichen Zeitpunkt so aus:
...
Sep 18 21:25:29 3950X systemd-resolved[989]: Using degraded feature set (UDP) for DNS server 192.168.178.1.
Sep 18 21:25:31 3950X systemd[1]: NetworkManager-dispatcher.service: Succeeded.
Sep 18 21:25:44 3950X systemd[1]: systemd-fsckd.service: Succeeded.
Sep 18 21:25:46 3950X systemd[1]: systemd-hostnamed.service: Succeeded.
Sep 18 21:25:46 3950X canonical-livepatch[1115]: Client.Check
Sep 18 21:25:46 3950X canonical-livepatch[1115]: error in livepatch check state: check-failed
Sep 18 21:25:46 3950X canonical-livepatch[1115]: No payload available.
Sep 18 21:25:46 3950X canonical-livepatch[1115]: during refresh: cannot check: No machine-token. Please run 'canonical-livepatch enable'!
Sep 18 21:25:56 3950X systemd-timesyncd[990]: Timed out waiting for reply from [2001:67c:1560:8003::c7]:123 (ntp.ubuntu.com).
Sep 18 21:25:56 3950X systemd-timesyncd[990]: Initial synchronization to time server [2001:67c:1560:8003::c8]:123 (ntp.ubuntu.com).

Hier habe ich vermutlich den Ausschalter betätigt.

Sep 18 21:27:04 3950X systemd[1]: unattended-upgrades.service: Succeeded.
Sep 18 21:27:04 3950X systemd[1]: Removed slice system-modprobe.slice.
Sep 18 21:27:04 3950X systemd[1]: Stopped target Graphical Interface.
Sep 18 21:27:04 3950X systemd[1]: Stopped target Multi-User System.
Sep 18 21:27:04 3950X systemd[1]: Stopped target Login Prompts.
Sep 18 21:27:04 3950X systemd[1]: Stopped target Sound Card.
Sep 18 21:27:04 3950X systemd[1]: Stopped target Timers.
...

Der Zeitserver sollte ja hoffentlich das Starten nicht verhinden?
[automerge]1600460922[/automerge]
var/log/kern.log endet mit:

...
Sep 18 21:25:46 3950X canonical-livepatch[1115]: Client.Check
Sep 18 21:25:46 3950X canonical-livepatch[1115]: error in livepatch check state: check-failed
Sep 18 21:25:46 3950X canonical-livepatch[1115]: No payload available.
Sep 18 21:25:46 3950X canonical-livepatch[1115]: during refresh: cannot check: No machine-token. Please run 'canonical-livepatch enable'!

Livepatch hatte ich erst aktiviert, aber später wieder deaktiviert.
[automerge]1600461161[/automerge]
Funfact am Rande: Boinc läuft trotzdem, ich kann mich von einem anderen Rechner aus verbinden.

 

[Riddler82]

Hm.
Normal ist die Lösung ja für das "Black Screen" Probblem, aber hast du schon versucht beim Booten die Kernelparameter ("nomodeset" bzw. "radeon.modeset=0", wie oben erwähnt )anzupassen? Das ist aber nur temporär und müsste für den dauerhaften Effekt in /etc/default/grub editiert werden.
Ich hab leider kein Gnome am start, sondern den Xfce.

Xfce und Gnome bringt mich auf noch was anderes: Du nimmst das default Ubuntu, oder?
Schau doch mal mit folgendem Befehl nach, welcher Display Manager installiert ist:
cat /etc/X11/default-display-manager

Hier sollte bei dir GDM(3) auftauchen, wenn du das default Ubuntu nimmst.

Sollte LightDM auftauchen, mach folgendes:
sudo dpkg-reconfigure gdm3

danach reboot.

Falls du den Fehler bekommst, dass das Paket nicht installiert ist:
sudo apt-get install gdm3
dann
sudo dpkg-reconfigure gdm3
dann reboot und hoffentlich freuen.

Bei Zweifeln bitte vorher nochmal fragen.

 

[Riddler82]

Was gibt dir eigentlich "sudo apt update" aus? Bekommst du da Pakete vorgeschlagen?

 

[MagicEye04]

radeon.modeset=0 statt quiet ergibt ein paar weiße Pixel statt Text, aber keine Besserung.
nomodeset ergibt einen komplett leeren/schwarzen Bildschirm.

Das ist ein klassisches Ubuntu mit Gnome.

Displaymanager ist gdm3

Auf dem alten System hatte ich auf der kommandozeile sogar mal Mate als zusätzlichen Desktop installiert. Aber auch damit startete es nicht.
[automerge]1600463793[/automerge]

Was gibt dir eigentlich "sudo apt update" aus? Bekommst du da Pakete vorgeschlagen?

Ja, 4 Stück. Sieht nach security updates aus.

 

[Riddler82]

Hm. Kernel ist nach wie vor aus der 4.xx reihe? was sagt "uname -a" bzw. "cat /etc/issue" ?

Was sagt "sudo systemctl status display-manager.service" ?

Hier sollte dann sowas rauskommen:

lightdm.service - Light Display Manager
   Loaded: loaded (/lib/systemd/system/lightdm.service; indirect; vendor preset: enabled)
   Active: active (running) since Fri 2020-09-18 17:07:30 CEST; 6h ago
     Docs: man:lightdm(1)
Main PID: 887 (lightdm)
    Tasks: 13 (limit: 4915)
   CGroup: /system.slice/lightdm.service
           ├─887 /usr/sbin/lightdm
           └─928 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

Unter /var/log/gdm(3)/ sollten noch logs vom GDM liegen, wenn ichd en Pfad richtig im Kopf habe.

mit "(sudo) journalctl -xe" bekommst du auch oft hilfreiche Informationen.

 

[MagicEye04]

Nein, ich hab ja 20.04.1LTS komplett neu installiert. Da ist jetzt 5.4~47 drauf.

Es kommt raus:
..gdm3...
...loaded...
...active (exited)...
Und jede Menge Zahlen

Den Rest muss ich später nachliefern.

 

[Riddler82]

Ah, ok, das hab ich dann überlesen, mit 20.04
btw, "sudo ubuntu-drivers autoinstall" soll bei einigen auch schon geholfen haben. Vorher natürlich den installierten Treiber entfernen.
Wenn bei den Updates ein Kernelupdate dabei ist würde ich das installieren, da kann sowas auch als Fix mit drin sein.

 

[MagicEye04]

Ich frag mich echt, was Ubuntu bzw. Gnome für ein beknacktes Problem haben im Moment.
Heute einen anderen Rechner quasi nach Monaten gebootet (Ubuntu18LTS), natürlich kam die Aktualisierungsverwaltung und meinte, es wären viele updates da. Also gut, dann update mal. Neustart erforderlich - *Trommelwirbel* - danach startet auch hier der Fenstermanager nicht mehr. Immerhin steht es noch als letzte Zuckung da: start display manager, dann wirds duster, dann wieder start display manager endlos im Kreis.
Da war nicht mal apt update oder gar upgrade im Spiel, einfach nur das normale Aktualisieren.
Vorher war Kernel 4.15~100 drauf, nun ~118, aber auch bei diesem Rechner klappt es nicht, mit den alten Kerneln zu starten.

Gibt es so eine Art Befehl "repariere den Fenster-Manager" ?
Ich fürchte, hier wird es ebenfalls nicht viel bringen, in Log-Dateien zu wühlen, mach ich morgen trotzdem mal.

PS: bin gerade an einem anderen Standort, daher kann ich mit dem 3950X nicht weitermachen.

 

[Riddler82]

Du könntest im recovery modus versuchen "broken packages" zu reparieren.
Das ganze scheint aber tatsächlich ein spezifisches Problem mit dem 4.15er Kernel bzw. dem GNOME zu sein, meine Xfce-Systeme laufen alle.

Für fortgeschrittene könnte man das probieren: https://www.cyberciti.biz/howto/debian-linux/ubuntu-linux-rollback-an-apt-get-upgrade/

 

[Woodstock]

Ich glaub nicht das es mit am Gnome liegt.

Ich habe seit heute das selbe Problem auf meinem Celsius H920 mit Kubuntu 20.04 LTS und KDE.
Kubuntu frisch installiert.
Nach einem sudo apt-get update und anschließenden sudo apt-get upgrade das ich wegen einem Treiber machen mußte bleibt der Bildschirm schwarz.

Gebootet scheint der Laptop aber zu haben da ich mich direkt auf der Konsole anmelden kann.

Ich werds noch mal neu installieren und den Treiber ohne vorheriges sudo apt-get update und sudo apt-get upgrade probieren

 

[MagicEye04]

Auf dem 3. Rechner habe ich inzwischen einfach neu installiert. Win10 und Ubuntu20 jeweils auf getrennten SSDs. Hat in Summe 2 Stunden gekostet.
Ich muss wohl einfach öfter backups machen. Insbesondere vor größeren udpates.

Wahrscheinlich werde ich das auch auf dem 3950X machen. Zeit und Ergebnis sind klar definiert. Beim Wühlen in Logfiles bin ich hinterher vermutlich genau so schlau wie vorher. Ich werde zumindest eine frische SSD nehmen, damit kann ich ja bei Langeweile immer noch in dem alten System herumwühlen.

 

[Woodstock]

Ok. Ich konnte es bei mir auf 3 Puinkte eingerenzen

• Der installer ist bei 90% gecrasht. Das System ist aber nach einem Reboot trotzdem gelaufen
• apt-get install dkms
• apt-get install libdrm-dev

Momentan tendiere ich zu Punkt 1.
Hardwaredefekt möchte ich eigentlich ausschließen. Windows 10 2004 läuft ohne Auffälligkeiten. Und Deepin 20 läßt sich auch installieren und läuft auch. Sagt mir aber nicht so ganz zu.

Ich mach mal einen anderen USB Stick flott und schau was da der installer auch wieder crasht.
[automerge]1601081439[/automerge]
Von meiner Seite kann ich entwarnung geben. Es liegt bei mir an der Kubuntu Iso. Da ist nicht in Ordnung.
Ich habe jetzt mal Minti 20 instaliert, ein apt-get update, ein apt-get upgrade, dann weil nötig noch einapt-get install libc6-dev und zum Abschluß ein sudo ./displaylink-driver-5.3.1.34.run

Mint ist nach jedem Update und nach der Treiberinstallation hochgekommen und ich kann jetzt auch unter Linux die beiden 27er am Lenovo USB-C Hybrid Dock nutzen.

Ich werd Die Tage noch mal die Kubuntu herunterladen und Kubuntu probieren. Mal sehen was dann wird.

 

[Riddler82]

Komischer Zeug.

Bei mir läuft immer noch alles wie geschmiert.

Bitte gib hierzu weiter Rückmeldung, @Woodstock , der Fall ist interessant.

 

[ghostadmin]

apt-get dist-upgrade (oder full-upgrade) ist besser da das auch neue zusätzliche Pakete installiert sofern erforderlich.
Kann sein das wichtige Pakete fehlen.

 

[Woodstock]

Also bei mir grenze ich es auf die fehlerhafte Installation von Kubuntu ein. Ich habs 2 x installiert gehabt und jedesmal ist der Installer bei 90% gecrasht.
Da es ja lief habe ich mir erst nichts dabei gedacht und beim ersten mal gleich ein apt-get update gefolgt von einem apt-get update gemacht und gleich den Treiber installiert.
Danach wurde der X-Server nicht mehr gestartet. Es kam kein Anmelde Screen. Über Konsole konnte ich mich anmelden.

Beim 2. mal habe ich erst einen Neustart gemacht der funktioniert hat. Anschließend erst die updates, upgrades und den Treiber installiert. Selbes Ergebnis wie beim ersten mal.

Beim 3. Versuch habe ich Mint 20 genommen und da hat alles funktioniert.
Mit dem selben USB Stick mit dem es bei Kubuntu nicht geklappt hat

Es liegt also an meiner Kubuntu 20.04 ISO. Ich werde die ISO die Tage noch mal runterladen und das installieren noch mal testen.

 

[ghostadmin]

Mit apt-get upgrade kann man sich auch wunderbar die Installation abschießen

 

[Riddler82]

ich werd das heute nacht mal mit meinem testrechner prüfen, ob der dann auch spinnt.

 

[Riddler82]

Testsystem:
i7 3770, Asus H77 Board, Crucial M500 SSD, 16G RAM, keine extra GPU, nur die APU.

Kubuntu 20.04 Torrent heute geladen und installiert, mehrfach rebooted, keine Probleme.
Mittels apt-get update/upgrade aktualisiert, immer noch keine Probleme.
Mangels einer geeigneten externen GPU werde ich das ganze jetzt noch in einem AM1 System testen, mal schauen was da passiert.

edit:
Das AM1 System mit der Kabini APU tut auch, jetzt Kernel 5.4.0-48 mit Kubuntu 20.04. auch der mitgelieferte -42 funktioniert.

 

[Woodstock]

Mit apt-get upgrade kann man sich auch wunderbar die Installation abschießen

Weis ich. Ist mir ja auch schon mal passiert.
Aber in meinem Fall liegts wohl dran das der Installer bei 90% gecrasht ist. Ich muß mal schauen ob ich irgendwo noch eine 2,5" Platte zum testen rumliegen habe. Dann hau ich Kubuntu noch mal drauf. Wobei ich mich frage ob ich mir die Arbeit machen soll. Das Laptop wird eh verkauft da ich was anderes möchte

 

[ghostadmin]

Mir fällt auch bei Debian auf das die Stabilität nicht mehr so wie früher ist. Vor allem muss man ständig Dinge nach Upgrades anpassen oder Programme tauschen weil das alte Deprecated ist. Also es läuft zwar nach wie vor stabil aber die rumbastelei ist deutlich mehr geworden.

 

[Riddler82]

Auch die Standardversion von Ubuntu mit Gnome tut auf dem Kabinisystem. Hm.

 

[MagicEye04]

Da ich blöderweise vergessen habe, die neu gekaufte SSD mitzunehmen, wollte ich heute einfach Ubuntu noch mal neu drüber bügeln.
Aber nach der Auswahl der Partition blieben die Buttons OK und ABBRECHEN ohne Funktion, es ging also nicht mehr weiter.
Jetzt teste ich den Rechner lieber erstmal noch mit Prime95 auf Rechenfehler. Nicht, dass es ein Hardwareproblem gibt. :/

 

[Riddler82]

Ich würde auch das Image nochmal neu laden, mit md5 verifizieren und ein neues Bootmedium erstellen. Am besten mit einem anderen Rechner.

 

[MagicEye04]

Zu spät.

Prime lief fehlerfrei eine Stunde durch. Das hat mir gereicht.

Ich habe jetzt einfach mal Livepatch und den damit nötigen Gnome-Keyring beim Installieren übersprungen. Vielleicht lag es ja daran.

 

[Riddler82]

Bin gespannt.