Titel: Boot debug BEVOR systemd übernommen hat
Beitrag von: Andreas am 04. Mai 2020, 15:04:42
Wenn ich schon mal ne Frage habe ::)...
Aber wer nicht fragt bleibt dumm!
Ich habe hier ein System was trotz guter Hardware extrem lange zum Booten braucht. core-i7, 8GB RAM, SSD. Von der Meldung, dass der Kernel geladen wird bis zum Login-Screen vergehen fast zwei Minuten. systemd-analyze time oder andere systemd-basierte Tools finden keine Fehler, weil die extreme Verzögerung schon VOR der Übergabe an systemd erfolgt. Das Problem ist ein Zusammenspiel zwischen Hardware und Software. Die betroffene Festplatte bootet in einem anderen Gerät rattenschnell, und andere Systeme booten in dem betroffenen Notebook ebenfalls rattenschnell. Keiner der "üblichen Kernelparameter" (nomodeset, noapic...) hilft, auch nicht das fallback-initramfs. Auch der Kernelparameter loglevel=7 bringt mich nicht weiter. Klar, an wen ich die Frage addressiere - oder ::)
Hast Du da eine Idee, Chris?
LG Andreas |
Titel: 1. Update
Beitrag von: Andreas am 04. Mai 2020, 17:05:35
Ich bin etwas weiter. Die Bootverzögerung ist weg wenn ich den Kernelparameter acpi=off übergebe. Das ist aber komplett inakzeptabel - nichts geht mehr in dem Fall. Kein Touchpad, kein USB, kein WLAN. Gebe ich den Parameter acpi=ht an (bei dem ja nur das CPU Hyperthreading aktiviert ist) ist die Verzögerung wieder da. Seltsamerweise nur mit aktuellen Kernels. Mit älteren läuft alles butterweich. Ich habe noch nicht getestet ob es auch darauf ankommt von welcher Distri die Kernel stammen. Also suche ich parallel 1) ein Live-System mit Kernel 5.>4.x das NICHT Arch-basiert ist 2) eine Möglichkeit Kernelmessages über ACPI-Events auszugeben - und zwar BEVOR systemd übernimmt.
Es bleibt spannend - weil es garantiert eine Möglichkeit gibt. Nur kenne ich die noch nicht.
LG Andreas |
Titel: Re:Boot debug BEVOR systemd übernommen hat
Beitrag von: Dietrich am 05. Mai 2020, 15:09:28
HALLO Andreas, die neueste Knopix ist Dein Freund Kernel 5.4.x |
Titel: Re:Boot debug BEVOR systemd übernommen hat
Beitrag von: Andreas am 05. Mai 2020, 16:50:03
Merci. Gleich getestet: Problem tritt damit nicht auf. Sehr seltsam das Ganze.
LG Andreas |
Titel: Re:Boot debug BEVOR systemd übernommen hat
Beitrag von: Chris am 06. Mai 2020, 09:39:30
Moin,
ich hatte bei einigen Geräten das gleiche Problem. Das lag am PRNG. Es konnten nicht genug Pseudozufallszahlen erzeugt werden. Dafür gibt es zwei alternative Packages (immer nur eins zur Zeit). Werden die aktiviert, klappte das ziemlich gut.
Die Packages lauten haveged (https://wiki.archlinux.org/index.php/Rng-tools]rng-tools[/url] und [url=https://wiki.archlinux.org/index.php/Haveged).
Der Fehler betrifft meines Wissens nach nur einige Intel CPUs. Vielleicht hilft das ja.
Gruß Chris |
Titel: Re:Boot debug BEVOR systemd übernommen hat
Beitrag von: Andreas am 06. Mai 2020, 10:41:12
Hallo Chris, den Verdacht hatte ich auch sofort. Ich habe dann einen Entropietest laufen gelassen und es gab keine Auffälligkeiten. Kann man irgendwie testen ob das die Ursache ist? Es IST ein Intel-Prozessor...
EDIT: Ich habe gerade gesehen dass diese Dienste via systemd gestartet werden. Das kann es also nicht sein - die Verzögerung bei mir liegt VOR der Übernahme durch systemd.
LG Andreas |
Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|