5.18.16 bekomme Freeze nach 6-8 Tagen ohne Log-File (gelöst)

[silizium]

Guten Tag zusammen,
habe Kernel 5.18.16 compiliert und getestet. Habe nach längerer Laufzeit einfach einen Komplett-Freeze und kann in keine Konsole oder sonst was machen.
Kann nur den Rechner komplett ausschalten.
Habe versucht mir Log-Files anzusehen aber es gibt kein Fehler der aufgenommen wurde.
Somit stehe ich vor einen unlösbaren Fehler.
Geht es vielleicht anderen Debian-Nutzer ebenfalls so?
Würde mich auf Feedback freuen.

Habe den Kernel 5.10 wieder gestartet und der läuft ohne Fehler.
Das doofe ist ich kann für den Kernel 5.18.16 kein Fehler melden oder überhaupt der Community helfen ohne einen aufgezeichneten Fehler zu haben.

Danke für eure Feedbacks .

LG

[DeletedUserReAsG]

Habe versucht mir Log-Files anzusehen aber es gibt kein Fehler der aufgenommen wurde.

In welchen Logfiles hast du nachzusehen versucht? Wie? Was steht drin? Wie hast du den Kernel gebaut? Aus welchen Quellen? Welche Konfiguration hast du verwendet? Welche Rahmen- und Randbedingungen gab es dabei? Wurden Patches verwendet? Welche? Unter welchem System wurde der Kernel gebaut? Welche Architektur? Welche Hardware ist in Benutzung?

Das doofe ist ich kann für den Kernel 5.18.16 kein Fehler melden oder überhaupt der Community helfen ohne einen aufgezeichneten Fehler zu haben.

Ohne die Antworten auf o.g. Fragen wär’s eh nicht hilfreich.

[silizium]

Habe versucht mir Log-Files anzusehen aber es gibt kein Fehler der aufgenommen wurde.

In welchen Logfiles hast du nachzusehen versucht? Wie? Was steht drin? Wie hast du den Kernel gebaut? Aus welchen Quellen? Welche Konfiguration hast du verwendet? Welche Rahmen- und Randbedingungen gab es dabei? Wurden Patches verwendet? Welche? Unter welchem System wurde der Kernel gebaut? Welche Architektur? Welche Hardware ist in Benutzung?

Das doofe ist ich kann für den Kernel 5.18.16 kein Fehler melden oder überhaupt der Community helfen ohne einen aufgezeichneten Fehler zu haben.

Ohne die Antworten auf o.g. Fragen wär’s eh nicht hilfreich.

User.log habe ich nachgesehen und Demesg und Jounalctl. Es steht leider nichts über den Fehler drin.
Den Kernel habe ich unter Debian11 gebaut mit Kernel 5.10 im Hintergrund.
Den Kernel habe ich aus Kernel.org.
Patches habe ich keine angewandt.
Meine eignen Konfigurationen, die auf Sicherheit optimiert ist.
Es gibt keine Rahmen- und Randbedingungen.
Architektur mit 64 Bit für einen Intel i7 mt 32 gig. Arbeitspeicher.

[schorsch_76]

Hier [1][2][3][4] sind einige Hinweise der Kernel Maintainer wie man sowas angeht. Diese Doku ist echt gut.

Check ‘taint’ flag¶

Check if your kernel was ‘tainted’ when the issue occurred, as the event that made the kernel set this flag might be causing the issue you face.

The kernel marks itself with a ‘taint’ flag when something happens that might lead to follow-up errors that look totally unrelated. The issue you face might be such an error if your kernel is tainted. That’s why it’s in your interest to rule this out early before investing more time into this process. This is the only reason why this step is here, as this process later will tell you to install the latest mainline kernel; you will need to check the taint flag again then, as that’s when it matters because it’s the kernel the report will focus on.

On a running system is easy to check if the kernel tainted itself: if cat /proc/sys/kernel/tainted returns ‘0’ then the kernel is not tainted and everything is fine. Checking that file is impossible in some situations; that’s why the kernel also mentions the taint status when it reports an internal problem (a ‘kernel bug’), a recoverable error (a ‘kernel Oops’) or a non-recoverable error before halting operation (a ‘kernel panic’). Look near the top of the error messages printed when one of these occurs and search for a line starting with ‘CPU:’. It should end with ‘Not tainted’ if the kernel was not tainted when it noticed the problem; it was tainted if you see ‘Tainted:’ followed by a few spaces and some letters.

If your kernel is tainted, study Tainted kernels to find out why. Try to eliminate the reason. Often it’s caused by one these three things:

A recoverable error (a ‘kernel Oops’) occurred and the kernel tainted itself, as the kernel knows it might misbehave in strange ways after that point. In that case check your kernel or system log and look for a section that starts with this:

Oops: 0000 [#1] SMP

That’s the first Oops since boot-up, as the ‘#1’ between the brackets shows. Every Oops and any other problem that happens after that point might be a follow-up problem to that first Oops, even if both look totally unrelated. Rule this out by getting rid of the cause for the first Oops and reproducing the issue afterwards. Sometimes simply restarting will be enough, sometimes a change to the configuration followed by a reboot can eliminate the Oops. But don’t invest too much time into this at this point of the process, as the cause for the Oops might already be fixed in the newer Linux kernel version you are going to install later in this process.

Your system uses a software that installs its own kernel modules, for example Nvidia’s proprietary graphics driver or VirtualBox. The kernel taints itself when it loads such module from external sources (even if they are Open Source): they sometimes cause errors in unrelated kernel areas and thus might be causing the issue you face. You therefore have to prevent those modules from loading when you want to report an issue to the Linux kernel developers. Most of the time the easiest way to do that is: temporarily uninstall such software including any modules they might have installed. Afterwards reboot.

The kernel also taints itself when it’s loading a module that resides in the staging tree of the Linux kernel source. That’s a special area for code (mostly drivers) that does not yet fulfill the normal Linux kernel quality standards. When you report an issue with such a module it’s obviously okay if the kernel is tainted; just make sure the module in question is the only reason for the taint. If the issue happens in an unrelated area reboot and temporarily block the module from being loaded by specifying foo.blacklist=1 as kernel parameter (replace ‘foo’ with the name of the module in question).

[1] https://docs.kernel.org/admin-guide/index.html
[2] https://docs.kernel.org/admin-guide/bug-hunting.html
[3] https://docs.kernel.org/admin-guide/ramoops.html
[4] https://docs.kernel.org/admin-guide/rep ... ssues.html

[DeletedUserReAsG]

Es steht leider nichts über den Fehler drin.

Glaube ich erstmal nicht vorbehaltlos. Du wärest nicht der Erste, der behauptet, da würde nichts zum Fehler drinstehen, während tatsächlich eine detaillierte Info zu finden ist, vor der nur nicht groß, rot und fett „Dies ist der Fehler!“ steht. Schon, dass du „Demesg“ (gemeint war dmesg?) nach einem Reboot bemüht hast, zeigt dann doch recht deutlich, dass da ein paar Sachen zum Verständnis fehlen – no offense intended, siehe unten.

Meine eignen Konfigurationen, die auf Sicherheit optimiert ist.

Solange du die nicht zur Verfügung stellst, damit man ggf. versuchen kann, den Fehler nachzuvollziehen, wäre eine entsprechende Meldung weiterhin sinnarm.

Es gibt keine Rahmen- und Randbedingungen.

Es gibt immer Rahmen- und Randbedingungen. Die Frage war daher auch nicht „ob“, sondern „welche“. Beteiligte Hardware würde auch weiterhin noch fehlen (eine der Rahmenbedingungen).

Versteh’s nicht falsch – ich hab weder die Zeit, noch die Lust, dir hier deinen Kernel zu debuggen – ich wollte nur kurz aufzeigen, dass deine „Informationen“ nahe an der unsäglichen Fehlerbeschreibung „Ich hab irgendwas gemacht, und es geht nich!“ sind. Und ich bin weiterhin der Ansicht, dass dir dann doch einige Grundlagen fehlen, ohne die dein Engagement zwar durchaus löblich, aber letztlich dann doch ohne tatsächlichen Sinn ist, bzw. gar kontraproduktiv sein kann (wenn du nämlich aus der Situation heraus die Devs mit „geht nich!“-Meldungen belegen würdest). Wie wär’s, wenn du es richtigherum angingest?

[silizium]

Hier [1][2][3][4] sind einige Hinweise der Kernel Maintainer wie man sowas angeht. Diese Doku ist echt gut.

Check ‘taint’ flag¶

Check if your kernel was ‘tainted’ when the issue occurred, as the event that made the kernel set this flag might be causing the issue you face.

The kernel marks itself with a ‘taint’ flag when something happens that might lead to follow-up errors that look totally unrelated. The issue you face might be such an error if your kernel is tainted. That’s why it’s in your interest to rule this out early before investing more time into this process. This is the only reason why this step is here, as this process later will tell you to install the latest mainline kernel; you will need to check the taint flag again then, as that’s when it matters because it’s the kernel the report will focus on.

On a running system is easy to check if the kernel tainted itself: if cat /proc/sys/kernel/tainted returns ‘0’ then the kernel is not tainted and everything is fine. Checking that file is impossible in some situations; that’s why the kernel also mentions the taint status when it reports an internal problem (a ‘kernel bug’), a recoverable error (a ‘kernel Oops’) or a non-recoverable error before halting operation (a ‘kernel panic’). Look near the top of the error messages printed when one of these occurs and search for a line starting with ‘CPU:’. It should end with ‘Not tainted’ if the kernel was not tainted when it noticed the problem; it was tainted if you see ‘Tainted:’ followed by a few spaces and some letters.

If your kernel is tainted, study Tainted kernels to find out why. Try to eliminate the reason. Often it’s caused by one these three things:

A recoverable error (a ‘kernel Oops’) occurred and the kernel tainted itself, as the kernel knows it might misbehave in strange ways after that point. In that case check your kernel or system log and look for a section that starts with this:

Oops: 0000 [#1] SMP

That’s the first Oops since boot-up, as the ‘#1’ between the brackets shows. Every Oops and any other problem that happens after that point might be a follow-up problem to that first Oops, even if both look totally unrelated. Rule this out by getting rid of the cause for the first Oops and reproducing the issue afterwards. Sometimes simply restarting will be enough, sometimes a change to the configuration followed by a reboot can eliminate the Oops. But don’t invest too much time into this at this point of the process, as the cause for the Oops might already be fixed in the newer Linux kernel version you are going to install later in this process.

Your system uses a software that installs its own kernel modules, for example Nvidia’s proprietary graphics driver or VirtualBox. The kernel taints itself when it loads such module from external sources (even if they are Open Source): they sometimes cause errors in unrelated kernel areas and thus might be causing the issue you face. You therefore have to prevent those modules from loading when you want to report an issue to the Linux kernel developers. Most of the time the easiest way to do that is: temporarily uninstall such software including any modules they might have installed. Afterwards reboot.

The kernel also taints itself when it’s loading a module that resides in the staging tree of the Linux kernel source. That’s a special area for code (mostly drivers) that does not yet fulfill the normal Linux kernel quality standards. When you report an issue with such a module it’s obviously okay if the kernel is tainted; just make sure the module in question is the only reason for the taint. If the issue happens in an unrelated area reboot and temporarily block the module from being loaded by specifying foo.blacklist=1 as kernel parameter (replace ‘foo’ with the name of the module in question).

[1] https://docs.kernel.org/admin-guide/index.html
[2] https://docs.kernel.org/admin-guide/bug-hunting.html
[3] https://docs.kernel.org/admin-guide/ramoops.html
[4] https://docs.kernel.org/admin-guide/rep ... ssues.html

Vielen Dank ^_^.
Werde ich mir durchlesen und anschauen.


Edit: ich erneuere meine Treiber immer wieder. Die gibt es kostenlos auf Kernel.org und ich lass den Kernel über keine Virtualbox und habe auch keine Nvidia Grafikkarte sondern eine schlichte Intel HD Grako. Da gibt es keine Fehler. Ich habe schon alle Fehler ausgeschlossen der liegt nur am Kernel 5.18 und 5.19. Bei 5.10 läuft mein Rechner immer ohne Fehler. Auch wenn ich den selber compiliere.

[Tintom]

Edit: ich erneuere meine Treiber immer wieder. Die gibt es kostenlos auf Kernel.org

Ähm, ja - wie meinst du das genau?

[...] und ich lass den Kernel über keine Virtualbox und habe auch keine Nvidia Grafikkarte sondern eine schlichte Intel HD Grako [...]

Da steht for example, gemeint sind damit alle Kernelmodule (du nennst sie vielleicht 'Treiber'), die nicht-freie Bestandteile (etwa Firmware) nachladen. Dazu gehören z.B. seit einiger Zeit auch die Intel-Grafikkarten.

[silizium]

Edit: ich erneuere meine Treiber immer wieder. Die gibt es kostenlos auf Kernel.org

Ähm, ja - wie meinst du das genau?

[...] und ich lass den Kernel über keine Virtualbox und habe auch keine Nvidia Grafikkarte sondern eine schlichte Intel HD Grako [...]

Da steht for example, gemeint sind damit alle Kernelmodule (du nennst sie vielleicht 'Treiber'), die nicht-freie Bestandteile (etwa Firmware) nachladen. Dazu gehören z.B. seit einiger Zeit auch die Intel-Grafikkarten.

ja genau die Firmware. Normal oder

[Livingston]

Normal oder

Nö.
Wenn, dann passend zu einem neuen Kernelmodul. Auf jeden Fall muss man auf Kompatibilität zwischen den Versionen achten.

[silizium]

Normal oder

Nö.
Wenn, dann passend zu einem neuen Kernelmodul. Auf jeden Fall muss man auf Kompatibilität zwischen den Versionen achten.

Seit wann?
Ist doch alles Abwärts-kompatibel dachte ich. Ich habe immer die neueste Firmware benutzt und es ging bis jetzt auch immer.
Beim Kernel 5.18.16 habe ich auch mit der alten Firmware probiert und da habe ich immer ein Freeze egal ob neue Firmware oder alte.
Wäre für mich echt neu wenn das wirklich so ist mit der Firmware.

Wo ist dann die Firmware für den Kernel 5.18.16, hast du dafür einen Link?

[Livingston]

Die Firmware stammt in aller Regel vom Hersteller der Karte.
Bitte bedenke, dass das Schreiben von freien oder proprietären Grafikkarten-Modulen Hexenwerk ist. Ich ziehe den Hut vor den Entwicklern, die sich mit diesem hardwarnahen Krempel auseinandersetzen.
Firmware ist dagegen schwarze Magie, meist völlig intransparent für User und Entwickler, und Modulbauer müssen sich auf die Informationen des Hardwareherstellers verlassen.
Neue Module müssen also berücksichtigen, welche konkrete Hardware läuft und die spezifische Firmware nachladen können. Wenn das nicht der Fall ist, musst Du es patchen und/oder die Firmware selbst am richtigen Platz verstauen. Infos, was zu tun ist findest, Du hoffentlich auf Upstream bei den Modul-Entwicklern, die dann oft auf eine Downloadseite des Hardware-Herstellers verweisen. Zur Not kann ein Blick in die Source des Moduls helfen.

[silizium]

Die Firmware stammt in aller Regel vom Hersteller der Karte.
Bitte bedenke, dass das Schreiben von freien oder proprietären Grafikkarten-Modulen Hexenwerk ist. Ich ziehe den Hut vor den Entwicklern, die sich mit diesem hardwarnahen Krempel auseinandersetzen.
Firmware ist dagegen schwarze Magie, meist völlig intransparent für User und Entwickler, und Modulbauer müssen sich auf die Informationen des Hardwareherstellers verlassen.
Neue Module müssen also berücksichtigen, welche konkrete Hardware läuft und die spezifische Firmware nachladen können. Wenn das nicht der Fall ist, musst Du es patchen und/oder die Firmware selbst am richtigen Platz verstauen. Infos, was zu tun ist findest, Du hoffentlich auf Upstream bei den Modul-Entwicklern, die dann oft auf eine Downloadseite des Hardware-Herstellers verweisen. Zur Not kann ein Blick in die Source des Moduls helfen.

Ich kopiere immer den ganzen Firmware ordner in /lib/Firmware und führe noch ein Befehl aus "initramfs -u" und gut ist.
Ich habe nur Intel Hardware und die ist meines Wissens total Linux Kompatibel.
Würde es verstehen wenn man bestimmte WIFI-Karten oder exotische Graka´s nutzt oder sonst was.
Aber ich denke eigentlich nicht damit das ein problem ist.
Wenn ja dann lerne ich gerne dazu .

[schorsch_76]

Ich bin vor einigen Jahren auch in die Firmwarefalle getappt mit einer AMD Evergreen Karte. Uralt.... Die Firmware kann APIs zwischen Treiber und Hardware ändern!Je nach Hardware kann die Firmware ein Fpga "Programm" oder/und ein Programm für eine MCU sein. Die Hersteller wissen das es Bugs geben wird und machen sehr viel sehr flexibel.

[silizium]

Ich bin vor einigen Jahren auch in die Firmwarefalle getappt mit einer AMD Evergreen Karte. Uralt.... Die Firmware kann APIs zwischen Treiber und Hardware ändern!Je nach Hardware kann die Firmware ein Fpga "Programm" oder/und ein Programm für eine MCU sein. Die Hersteller wissen das es Bugs geben wird und machen sehr viel sehr flexibel.

ja ok, ich werde mir das nochmals in Ruhe anschauen.
Aber von euch hat keiner sonst Probleme mit den Kernel 5.18 oder 5.19?

[JTH]

Aber von euch hat keiner sonst Probleme mit den Kernel 5.18 oder 5.19?

Der 5.18er aktuell aus den Backports läuft bei mir schon eine Weile auf drei Geräten ohne Auffälligkeiten. Ein 5.19 in einer VMs zum Entwickeln auch, der hängt nur durch mein eigenes Verschulden sehr vereinzelt.

So eine Beobachtung ist aber sicher keine Garantie, dass nicht jemand anderes Probleme hat. Dafür spielt da zu viel mit rein.

[MSfree]

Aber von euch hat keiner sonst Probleme mit den Kernel 5.18 oder 5.19?

Nein, keine Probleme hier. Bookworm setzt im Moment auf den 5.18er und das läuft hier auf verschiedenen Rechnern völlig problemlos.

[cosinus]

Nein, keine Probleme hier. Bookworm setzt im Moment auf den 5.18er und das läuft hier auf verschiedenen Rechnern völlig problemlos.

Kann ich bestätigen. Eben gerade ist auch 5.18.0-4 reingekommen (5.18.16-1 (2022-08-10)) und läuft ohne Probleme. Da fragt man sich doch, warum der TO überhaupt sich den Kernel selbst kompiliert oder hab ich das Warum überlesen?

[JTH]

oder hab ich das Warum überlesen?

Meine eignen Konfigurationen, die auf Sicherheit optimiert ist.

[cosinus]

Wie kann man denn damit die Sicherheit signifikant erhöhen? Sind andere Maßnahmen nicht wesentlich effektiver?

[schorsch_76]

Wie kann man denn damit die Sicherheit signifikant erhöhen? Sind andere Maßnahmen nicht wesentlich effektiver?

Ein Punkt wäre: grsecurity. Das braucht aber "nicht mainline" Patches. Ein anderer Punkt sind die Stacksmashing Protection Optionen (CONFIG_STACKPROTECTOR) und die ganze Reihe an Punkten in der Security Dokumentation insbesondere selfprotection [1]. Wieviel der Standardkernel von Debian umgesetzt hat kann ich nicht beantworten.

[1] https://www.kernel.org/doc/Documentation/security/
[2] https://zatoichi-engineer.github.io/201 ... ction.html
[3] https://lwn.net/Articles/698827/

[cosinus]

Ist das wirklich praktikabel? Angenommen ich habe eine Menge Server zu betreuen, da kann ich doch nicht einzeln auf jedem einen selbst kompilierten Kernel einspielen, sonder warte auf die neuen Kernel im Repo. Debian ist doch da recht fix was Sicherheitsaktualisierungen angeht. Meine Server schicken mir per apticron täglich eine Mail mit der Zusammenfassung verfügbarer Updates.

[schorsch_76]

Ist das wirklich praktikabel? Angenommen ich habe eine Menge Server zu betreuen, da kann ich doch nicht einzeln auf jedem einen selbst kompilierten Kernel einspielen, sonder warte auf die neuen Kernel im Repo. Debian ist doch da recht fix was Sicherheitsaktualisierungen angeht. Meine Server schicken mir per apticron täglich eine Mail mit der Zusammenfassung verfügbarer Updates.

Jede Menge Server: Eigenes Repo anlegen [1] für die eigene Software und den eigenen Kernel mit unattended-upgrades. Repo aktualisieren und es landet auf allen Servern. grsecurity ist ja nur noch gegen Bezahlung verfügbar. Die machen das ziemlich sicher so wenn das auf vielen Servern laufen soll.

[1] https://debiananwenderhandbuch.de/debia ... ories.html

[DeletedUserReAsG]

Ein Punkt wäre: grsecurity. Das braucht aber "nicht mainline" Patches. Ein anderer Punkt sind die Stacksmashing Protection Optionen (CONFIG_STACKPROTECTOR) und die ganze Reihe an Punkten in der Security Dokumentation insbesondere selfprotection [1].

Nix für ungut, aber wenn du dir die Beiträge des TE durchliest: glaubst du wirklich, dass er auf dieser Ebene agiert? Ich meine, da fehlen offensichtlich grundlegende Basics, und zumindest mir fällt es schwer, mir unter dem Gesichtspunkt vorzustellen, dass irgendeine Maßnahme des TE die Sicherheit tatsächlich erhöhen würde. Wenn ich ehrlich bin, würde ich eher das Gegeneil annehmen. Dunning und Kruger lagen halt doch nicht so falsch …

Laut eigener Aussage des TE ist sein eigener „Sicherheitskernel“ nicht gepatched, btw. – die Frage ist legitim: was genau wurde da beim Bau anders konfiguriert, als beim Standard-Debian-Kernel? Insbesondere auch mit Hinblick auf das Threadthema wäre das eine sehr wichtige Information. Warum gibt’s dazu keine Infos, silizium? Die Logs fehlen übrigens weiterhin. Ich schreib’s gerne nochmal: dass du daraus nichts lesen kannst heißt nicht, dass da nichts drinsteht.

OT: insbesondere auch vor dem Hintergrund von viewtopic.php?p=1307371#p1307371 hat’s dann doch einen gewissen Geschmack, wenn hier nun offenbart wird, dass es sich offensichtlich nicht einmal um einen von Debian bereitgestellten Kernel handelt, der das Problem verursacht, auf dessen Grundlage sich der TE über die mangelnde Stabilität seine Debiansystems beschwert und das Debian selbst anhängen will. Ich such’ schonmal den Fisch …

[JTH]

Wieviel der Standardkernel von Debian umgesetzt hat kann ich nicht beantworten.

Ein Blick in die /boot/config-*, die jedes Kernelpaket mitbringt, verrät dir mehr. Das erwähnte CONFIG_STACKPROTECTOR z.B. ist gesetzt.

[cosinus]

Jede Menge Server: Eigenes Repo anlegen [1] für die eigene Software und den eigenen Kernel mit unattended-upgrades. Repo aktualisieren und es landet auf allen Servern. grsecurity ist ja nur noch gegen Bezahlung verfügbar. Die machen das ziemlich sicher so wenn das auf vielen Servern laufen soll.

[1] https://debiananwenderhandbuch.de/debia ... ories.html

Aber macht das denn wirklich Sinn? Ich würde da lieber bei einem Standardkernel (LTS) bleiben. Zuviel customizing kann die Sicherheit beeinträchtigen und erst recht die Fehlersuche. Und der TO hat ja nunmal massive Stabilitätsprobleme. Das ist doch für den Hintern sowas