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?

  • josefine hat auf diesen Beitrag geantwortet.

    Bugreport geschrieben oder evtl vorhandene gefunden zum Thema?

      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.

        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.

        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

          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.