Seiten: [1] 
|
 |
|
|
Autor
|
Thema: Boot debug BEVOR systemd übernommen hat (Gelesen 1448 mal)
|
|
Andreas
Administrator
 Offline
Einträge: 1140
Linux von Innen
|
 |
Boot debug BEVOR systemd übernommen hat
« 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
|
|
 Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Andreas
Administrator
Offline
Einträge: 1140
Linux von Innen
|
|
1. Update
« Antwort #1 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
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Dietrich
Full Member
Offline
Einträge: 120
Immer schön neugierig bleiben
|
|
Re:Boot debug BEVOR systemd übernommen hat
« Antwort #2 am: 05. Mai 2020, 15:09:28 »
|
|
HALLO Andreas, die neueste Knopix ist Dein Freund Kernel 5.4.x
|
|
|
|
Andreas
Administrator
Offline
Einträge: 1140
Linux von Innen
|
|
Re:Boot debug BEVOR systemd übernommen hat
« Antwort #3 am: 05. Mai 2020, 16:50:03 »
|
|
Merci. Gleich getestet: Problem tritt damit nicht auf. Sehr seltsam das Ganze.
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Chris
Full Member
Offline
Einträge: 164
Okay, wer hat meine Kekse gegessen?
|
|
Re:Boot debug BEVOR systemd übernommen hat
« Antwort #4 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 rng-tools und haveged.
Der Fehler betrifft meines Wissens nach nur einige Intel CPUs. Vielleicht hilft das ja.
Gruß
Chris
|
|
Gespeichert
|
Der einzig sichere Computer der Welt ist ausgestöpselt, in einem Tresor verstaut und auf dem Meeresboden.
Und nur eine Person kennt die Kombination zum Tresor.
Und diese ist tot.
[Bruce Schneier]
|
|
|
Andreas
Administrator
Offline
Einträge: 1140
Linux von Innen
|
|
Re:Boot debug BEVOR systemd übernommen hat
« Antwort #5 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
|
| « Letzte Änderung: 06. Mai 2020, 10:43:41 von Andreas » |
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
