Heute kam im Zuge eines Update eine Aktualisierung von Kernel 5.15.58-2-lts auf Kernel 5.15.59-1-lts rein. Auf meinem Lenovo T430 und auch Lenovo W530 fällt danach sofort auf, das nicht nur fschk für seine positive Partitionsüberprüfung nun ungewöhnlich lange braucht, sondern vom Systemstart bis zum Loggin bislang keine 4 Sekunden vergingen - und nun sind es weit über eine Minute. Auch nach dem Loggin ist das System kaum noch nutzbar. Jede Aktion läuft jetzt in Cinnamon zäh wie Brei ab. Ok, mittels Timeshift auf den Stand von Kernel 5.15.58-2-lts zurück gesetzt und dann alle Updates durchgeführt....vorher aber nur das Upgrade von 5.15.59-1-lts deaktiviert. Yeah, nun läuft alles wieder wie am Schnürchen. Sehen wir es mal so: 4 Tage nach der Probefahrt durch einen Neukunden bereits einen Totalschaden am Motor durch einen von der Werkstatt empfohlenen Ölwechsel schreien doch nach einer Erklärung - oder?
Heute: Nach Update auf 5.15.59-1-lts war Arch zäh wie Brei
Bugreport geschrieben oder evtl vorhandene gefunden zum Thema?
- Bearbeitet
skull-y
Danke für deine Antwort. Naja, an einen Bugreport traue ich mich derzeit noch nicht ran und für eine Netzrecherche ist das Ding wohl ohnehin noch zu frisch. Schließlich besteht aber zu ca, 0,3 Promille noch die Möglichkeit, das ich da einen Fehler gemacht habe. Ein Bugreport geht sofort raus, wenn ich nicht der Einzige sein sollte, der das feststellt.
Archibaldo
Hast du zufällig auch den aktuellen Kernel 5.18-16 getestet, ist Arch da auch so zäh?
Aktuell ist momentan 5.15.59-2, vlt. behebt das ja deinen Fehler schon.
Jedoch kann ich damit keine Verlangsamung feststellen.
- Bearbeitet
josefine
Hast du zufällig auch den aktuellen Kernel 5.18-16 getestet...
Ach @josefine, man könnte fast glauben, das du mich gut kennst. Ich habe vorab als Fallback zusätzlich zum LTS auch den aktuellen "Linux Kernel" installiert und im Grub Menü auswählbar gemacht. Yup, das ist derzeit Kernel 5.18-16 und nach dem Wechsel auf diesen haut es ebenfalls mit dem kompletten Update hin. Das will ich aber so natürlich nicht stehen lassen. Ich möchte weiterhin den LTS-Kernel nutzen und kein Kernel-Hopping betreiben.
- Bearbeitet
Weiterhin ein erster Ansatz wären Logfiles vom aktuellen "Guten" und dem "zähen" Boot.
Mit
journalctl -b <IDX>
kannst du auf ein altes Log vom Problemkernel zugreifen, mit
journalctl --list-boots
kriegst du eine Liste der Boots für die IDX Nummer (alte Boots haben ein Minuszeichen, das muß mit angegeben werden (z.B. -b -3).
Diese Logfiles anschauen, prüfen und/oder auf einen Pastebin-Server stellen bzw. hier posten.
Wenn du den "zähen" Kernel noch mal installieren/booten willst würde ich mindest das "quiet" beim Boot als Parameter im Booloader abstellen, ggf. siehst du dann mehr wo/warum es hängt anhand der Boot-Meldungen.
Weiterhin interessant wären dann auch die Ausgaben von:
systemd-analyze
systemd-analyze blame
systemd-analyze critical-chain
vom "zähen" im Vergleich zum "guten" Erscheinungsbild.
//Edit; gerade gesehen
https://bbs.archlinux.org/viewtopic.php?id=278695
https://bugs.archlinux.org/task/75538
- Bearbeitet
GerBra Wenn du den "zähen" Kernel noch mal installieren/booten willst....
Nein danke. @ToterEngel berichtet von einem inzwischen erneut aktualisiertem LTS Kernel. Vor 3 Stunden habe ich meine Spiegelserver erst aktualisiert, da gab es den noch nicht. Das schaue ich mir jetzt vorrangig mal an.....
Wow, abschließende Meldung von der LTS-Kernelfront. So wie es ausschaut, wurde das per Kernel-Update innerhalb eines Tages gepatcht und funktioniert nun.
Na das ist doch schon mal was :-D
Such dir vlt. mal einen "aktuelleren" Spiegelserver, das spart ggf. solche kleinen Probleme, wenn deiner nicht so oft sich abgleicht.