Hier ist der Bootlog: journalctl --since "2023-10-08 06:30:00" --until "2023-10-08 06:50:00"
Dankeschön @niemand
Hier ist der Bootlog: journalctl --since "2023-10-08 06:30:00" --until "2023-10-08 06:50:00"
Dankeschön @niemand
hat keiner irgendwie eine idee?
hier nochmal ein Log von journalctl --since "2023-10-14 05:30:00" --until "2023-10-14 05:50:00"
Was sagt denn dmesg im laufenden Betrieb?
Hast du mal versucht mit deaktiviertem ACPI zu booten?
dmesg: https://pastebin.com/RP2V9qUt
mehr power settings hab ich nicht gefunden
EDIT: habe das Motherboard -> Micro-Star International Co., Ltd. MS-7C89/H410M-A PRO (MS-7C89), habe das neuste BIOS update.
Hallo, hast Du mal den neuesten Kernel installiert und ausprobiert?
Unter KDE ist bei mir der neuste 6.5.7 arch1-1
Haii, ich habe denn LTS, ZEN und denn main Kernel jeweils installiert und auch getestet ebenfalls mit der aktuellen version.
dieses problem tritt ebenfalls auch mit älteren versionen auf.
Es könnte m.M.n. sein, dass systemd diesen Fehler verursacht.
Entweder es liegt dann daran, dass systemd einen bug hat oder, dass es systemd nicht gelingt einen service erfolgreich zu beenden. Dumm ist natürlich auch, das es nicht immer geschied.
Zum Testen würde ich ausprobieren, ob das Verhalten auch auftritt, wenn man ohne sich mit einem LoginManager einzuloggen nach dem Starten den PC auf z.B. tty3 gleich wieder mit poweroff
herunterfährt.
Falls das dann auch hier gelegentlich auftritt, dann hast du zumindest wesichtlich weniger Möglichkeiten wonach du fahnden musst. Schreib dir die Zeiten auf, wann es passiert, dann kannst du die journales der jeweiligen sitzungen mit einander vergleichen.
Hilfreich für die Fehler-Analyse könnte auch der Befehl systemctl --type=service --all
sein.
P.S.:
schard Hast du mal versucht mit deaktiviertem ACPI zu booten?
Bemerkung hierzu:
ACPI dient der Energieverwaltung und ist deshalb fehleranfällig weil den Entwicklern nicht jede Hardware in jeder Kombination vorliegt. Es wird wie andere services durch systemd gestartet bzw, wieder beim Runterfahren beendet.
Damit der Rechner in Zukunft ohne ACPI gesartet wird, wie es schard probeweise empfohlen hat, gibst du systemctl disable acpid
in die Konsole ein.
hallo danke für die tipps,
hier sind 3 auszüge von systemctl --type=service --all : ungefähr 5 minuten, 10-13 minuten und 15-18 minuten nach systemstart. clamav die virus daten bank zeigt z.B. ein ''fail'' an beim ersten log, beim 2. werden plymouth als ''failed'' angezeigt und beim 3. link sieht man system elemente mit ''failed''
wegen acpi : dieser befehl systemctl disable acpi funktioniert bei mir nicht. da steht in roter schrift
''Failed to disable unit: Unit file acpi.service does not exist.''
egal ob mit oder ohne root
EDIT: habe mal nach acpi gesucht. z.B. acpid ist installiert (nicht das normale acpi) und zudem hab ich von KDE das powerdevil paket installiert.
Diese beiden pakete sind schon länger installiert, hab jz grad mal nur geguckt was sich so drunter finden lässt wenn ich acpi eingebe.
tuxnix ACPI dient der Energieverwaltung und ist deshalb fehleranfällig weil den Entwicklern nicht jede Hardware in jeder Kombination vorliegt
aber das mein neustart/herunterfahren dadurch behindert wird is schon frech.
FeuFeu-Chan wegen acpi : dieser befehl systemctl disable acpi funktioniert bei mir nicht. da steht in roter schrift
''Failed to disable unit: Unit file acpi.service does not exist.''
Sorry, mein Fehler!
Das Paket heißt acpi
der dazugehörige service heißt acpid
und der korrekte systemd-Befehl lautet deshalb auch systemctl disable acpid
bzw. zum Einschalten systemctl enable acpid
.
Ich habe es oben in meinem Post jetzt nachträglich verbessert, nicht dass irgendwann noch jemand anderes darüber stolpert.
Ist das Problem jetzt behoben?
Wenn ja, dann kannst du das Thema auf gelößt setzen.
Siehe: Wie setze ich mein eigenes Thema auf „gelöst"? in den Foren-FAQs
hey, danke jetzt klappt es
Removed "/etc/systemd/system/multi-user.target.wants/acpid.service".
allerdings wenn es das problem wirklich löst, kann ich es noch nicht bestätigen da wie gesagt das problem unregelmässig auftritt. ich würd ersma noch paar tage abwarten ob ich die kommenden tage mein pc normal runterfahren/neustarten kann
ansschliessend stell ich das thema logischerweisse auf gelöst
und falls nicht meld ich mich nochmal
Den acpid.service abzustellen ist auch noch nicht der wahre Jakob. Jetzt müsste man eigentlich noch herausfinden welches Gerät den Fehler vom acpid.service verursacht und dann könnte man den Enticklern einen einen bug-report schreiben, damit das dann auch gefixt werden kann.
Lade dir das journal doch mal in einen editor und gehe mit der Suche nach acpi durch.
Vielleicht gibt das dort schon genauere Auskunft.
welches journal meinst du genau bzw welches soll ich verwenden?
dann würd ich das mit dem kate texteditor durchsuchen
EDIT: hab grad beim dmesg das hier gefunden:
[0.187997] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
hat das was zu bedeuten und wenn ja was bedeutet das?
im regulären bootlog/journal zu der zeit des herunterfahren wo das problem auftritt hab ich nichts gefunden ausser das ACPI erfolgreich deaktiviert worden ist
Es ist jetzt zumindest vorerst nicht mehr aufgetreten, hab mein PC wie gewohnt verwendet und auch mal 24h angehabt. (auch wenn ich noch aufgrund der unregelmässigkeit noch unsicher bin)
Ich werde das Thema heut abend auf gelöst setzten. gibts eine möglicheit das thema wieder zu ungelöst zu setzten beim erneuten auftreten des problems ?
eine frage hätt ich noch: macht es ein effektiven unterschied wenn ich
systemctl disable acpid
und / oder
systemctl stop acpid
mache ?
EDIT: Ich bedanke mich an alle die ihre Ideen und Vorschläge mit mir geteilt haben und vorallem Danke für eure Zeit. Falls das Problem erneut auftretten sollte Zukünftig irgendwie, werdet ihr von mir hören. Bis dahin
MfG, FeuFeu
ja, disable bedeutet, dass der Dienst gar nicht mehr gestartet werden soll, und stop bedeutet nur, dass du ihn für dieses Mal gestoppt haben willst.
Ein downgrade von systemd, auf den Stand bevor der Fehler auftrat wäre ein Versuch wert.
Das lässt sich so echt schwer sagen.
Weil das problem schon mehrere Monate auftritt und seit dem ich Arch und (davor) EndeavourOS auf diesen PC Installiert habe.
Also Befürchte ich dementsprechend ein Downgrade bringt da leider nichts. Weil es eben keine Version gibt wo das Problem auf diesen PC nicht auftrat.
Auf mein älteren Rechner mit Arch is sowas noch nie passiert. (welche Software Version oder Hardware der hatte kann ich nicht mehr sagen)
Hallo,
beim schnellen Überfliegen des Threads habe ich die Frage nach "Hardware-Fehler" noch nicht gesehen. Vielleicht auch mal in diese Richtung suchen. Mir fällt da das Netzteil ein, das eventuell beim Booten mehr Energie liefern muss, als es kann.
Natürlich kann auch andere Hardware defekt sein.
Just an idea,
Photor
Meinst du? Weil Windows 10 und 11 hat damals sauber funktioniert (auch der Neustart und das Herunterfahren) und während des Arch (und auch endeavour) Betriebs kann ich keine Fehler o.ä. feststellen, da alles ruckelfrei und sauber läuft. Und der Neustart / Herunterfahren freeze tritt ya nur unregelmässig auf.
EDIT: wie kann ich gezielt nach Hardware Problemen suchen auf Arch? hab das tatsächlich so noch nie gemacht.
Arch Linux hat ein Paketarchiv.
Der Link zu alten systemd Versionen ist https://archive.archlinux.org/packages/s/systemd/.