ubuntuusers.de

Dell Precision M4400, letztes BIOS A29 (alt, ca. 10+ Jahre) (X)Ubuntu 24.04

Hallo,

es läuft alles flüssig und gut, aber manchmal (gefühlt jedes 3. Mal) dauert der Boot etwas mehr als 4 Minuten. Danach aber alles flüssig. Die SSD habe ich bereits ausgetauscht, daran lags nicht. Ich vermute BIOS und Kernel haben ein (Kompatibilitäts-)Problem, welches man evtl. mit grub-Optionen umgehen kann. (Windows war vorher drauf, ohne Probleme aber auffällig langsam (anders als jetzt mit Xubuntu), mit openSUSE 15.6 als erstem Versuch gabs auch Probleme, die ich aber nicht weiter analysiert habe)

dmesg, zeigt dann bei den Bootvorgängen Unterschiede bei "tsc: Fast TSC calibration" und "tpm tpm0"

s.w.u. die dmesg-Protokolle. Vielleicht hat dies bereits jemand gebabt und gelöst, ich würde mich über eine Lösung freuen!

dmesg ok : https://paste.ubuntuusers.de/424235/

dmesg ko : https://paste.ubuntuusers.de/424236/

VG Walter

Text gehört in einen Codeblock nicht in Bilder oder sonstige Dateiformate. Und Anhänge haben immer mit der richtigen Dateiendung hochgeladen zu werden.

So wie es jetzt ist wird sich das keiner anguggen.

systemd-analyze blame

@schwarzheit: Danke für den netten Hinweis, geändert.

@DJKUhpisse: "systemd-analyze blame" bringt hier m.E. nichts, da systemd nicht wie der Verursacher aussieht. Für mich sieht dies so aus, dass gerade der Kernel beginnt zu laden und an einer Stelle wartet. Zu sehen in den beiden dmesg-Protokollen und dem Vergleich als pdf.

Schau mal nach was:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

... anzeigt, als zur Verfügung stehende clocksource. Falls acpi_pm dabei ist, versuche es mal damit.

Dafür in die:

/etc/default/grub

... eintragen:

GRUB_CMDLINE_LINUX="clocksource=acpi_pm" 

Die anderen Einträge, die dort bereits zwischen den Anführungszeichen stehen aber beibehalten!

Dann:

sudo update-initramfs -c -k all && sudo update-grub

... und dann rebooten.

Edit: für bearbeiten von /etc/default/grub Nano benutzen, damit nicht mit root Rechten noch irgendwas im $HOME Verzeichnis kaputt gemacht wird:

sudo nano /etc/default/grub

Lesestoff im Wiki:

• Nano

• mit Root-Rechten arbeiten

[   12.059222] random: crng init done
[  288.985319] loop: module loaded

Vllt. probierst Du die Antwort mal.

https://askubuntu.com/questions/1302325/ubuntu-20-04-boot-hungs-after-random-fast-crng-init-done

Scheint bei Vielen mit selben Problem Erfolg gehabt zu haben.

alt, ca. 10+ Jahre)

Veröffentliche doch mal ein "inxi -Fz". Das Gerät/Komponenten könnte 15 Jahre alt sein, nix für Ubuntu in allen Varianten. ☹

hakel2022 schrieb:

alt, ca. 10+ Jahre)

Veröffentliche doch mal ein "inxi -Fz". Das Gerät/Komponenten könnte 15 Jahre alt sein, nix für Ubuntu in allen Varianten. ☹

https://paste.ubuntuusers.de/424237/

Danke für die Tipps, leider hilft nichts ☹

@trollsportverein: GRUB_CMDLINE_LINUX="clocksource=acpi_pm"

@Marantkurz: haveged - ich denke dies kann gar nicht helfen, da der Kernel ganz am Anfang wartet, höchstens es gibt Support dafür in der ramdisk

Hat noch jemand einen Voschlag, oder das Problem schonmal gelöst?

Setz mal den Kernel-Parameter lapic=notscdeadline

oder auch tsc=****

https://www.kernel.org/doc/html/v6.11/admin-guide/kernel-parameters.html

haveged - ich denke dies kann gar nicht helfen,

Das steht nicht nur auf dieser Seite. Die Zeit gibt es natürlich auch her, da fehlen > 4 Min. Zuminmdest den möglichen Zusammenhang würde ich im Auge behalten. Letztlich lässt sich haveged ja auch wieder mühelos deaktivieren/ entfernen falls es nichts bringt.

wla schrieb:

Hat noch jemand einen Voschlag, oder das Problem schonmal gelöst?

Hi, hatte das auch mal und bei mir stand in der crypttab noch ein Eintrag einer SSD die nicht mehr da war.

T9400

15 Jahre alte Laptop CPU mit Quadro Grafik

Wurde hier ja schon öfter diskutiert.

Vielleicht löst ein schlanker Debian Kernel das Problem.

... oder es gibt gar kein "Problem", und es ist wirklich nur die Hardware/Alter (Initialisierung). ☹

Das Verhalten tritt ja nicht immer auf, "Normal" bei mürber Hardware.

Funktioniert nun!

Ich bin mir nicht sicher was entscheidend war, hatte mit GRUB_CMDLINE_LINUX="clocksource=acpi_pm" und "haveged" getestet. GRUB_CMDLINE_LINUX="clocksource=acpi_pm" ist geblieben, "haveged" wieder uninstall und TPM im BIOS deaktiviert. Seither > 10x gebootet, dauert immer gleich lange, 30 Sekunden bis zum X-Login.

Danke für alle Tipps!