Fehler bei Kernel-Upgrade auf 6.1.64-1: „broken package“

[cosinus]

6.1.0-14 wurde aus dem Debian Repository entfernt, der läßt sich nicht mehr installieren, auch nicht versehentlich.

Deswegen war ja ja so irritert, weil doch recht zügig 6.1.0-14 'broken' war. Er war aber noch ne Zeit bei ftp.de.debian.org verfügbar.
Dass nun 6.1.0-15 verfügbar ist, hab ich auch gesehen.

[MSfree]

Deswegen war ja ja so irritert, weil doch recht zügig 6.1.0-14 'broken' war. Er war aber noch ne Zeit bei ftp.de.debian.org verfügbar.

Ich habe die Situation auf meinem eigenen Mirror beobachtet. Der hinkt aber ohnehin fast einen Tag hinterher, weil ich den nachts von einem deutschen Mirror rsynce. Da war auch zunächst der 6.1.0-14er noch vorhanden, mit dem rsync heute Nacht ist der nun komplett weg, auf den offiziellen Mirrors ist der also schon seit mehr als einem Tag nicht mehr vorhanden.

[cosinus]

Was ich noch nicht rausgelesen habe, auch da nicht, wie erkenne ich nun eine kaputte Datei? Oder soll ich das nun einfach ignorieren, weil der Bug wie dort beschrieben

The bug appears to be triggered when an ->end_io handler returns a non-
zero value to iomap after a direct IO write.

zu selten/unwahrscheinlich ist? Wann genau passiert so ein "direct IO write"?

[Cordess]

Da ich da überhaupt keinen Durchblick habe und es bei mir eine Angelegenheit von einer guten halben Stunde ist, habe ich gerade vorher die Atombombe gezündet und neu installiert.

Backup hatte ich noch von vorgestern, besser mit dem weiterarbeiten als "weiterzuzittern" ob da mal irgendwann irgendwo (vielleicht schon mit korrumpiertem Backup) was kommt.

'Backup' bezieht sich auf deine Persönlichen Daten, nicht auf das System?!

Dann denke vielleicht mal drüber nach, so was wie timeshift zu nutzen.

Timeshift hätte dich hier nicht gerettet. Wenn du einen amoklaufenden Kernel hast, der dir das Dateisystem komplett zerwürfelt schützt dich Timeshift kein bisschen.

Was hilft ist ein externes Backup oder wenigstens ein NAS auf dem die Daten ausgelagert liegen.

[Cordess]

Da ich da überhaupt keinen Durchblick habe und es bei mir eine Angelegenheit von einer guten halben Stunde ist, habe ich gerade vorher die Atombombe gezündet und neu installiert. :lol

Völlig überflüssige Aktion. Du hättest doch nur den 6.1.0.14er purgen brauchen und dann den letzten Kernel booten können. So habe ich es jedenfalls mit meinem Bookworm gemacht, nachdem ich diesen Thread gelesen hatte.

6.1.0.14er purgen bringt gar nichts, wenn er bereits aktiv war und das Dateisystem schreddern durfte/konnte.
Purgen macht nur dann Sinn, solange noch der 6.1.0.13er gelaufen ist.

[Cordess]

Was ich noch nicht rausgelesen habe, auch da nicht, wie erkenne ich nun eine kaputte Datei? Oder soll ich das nun einfach ignorieren, weil der Bug wie dort beschrieben

The bug appears to be triggered when an ->end_io handler returns a non-
zero value to iomap after a direct IO write.

zu selten/unwahrscheinlich ist? Wann genau passiert so ein "direct IO write"?

Du brauchst gültige Prüfsummen deiner Dateien, ansonsten hast du keine Chance die fehlerhaften Dateien zu finden. Und wenn über Dateigrenzen hinaus geschrieben wurde, womit ich rechnen würde, dürfte noch mehr kaputt sein. Das Dateissystem neu anlegen und Backups einspielen dürfte hier eine saubere und sichere Lösung sein, wenn dieser kaputte Kernel aktiv war.
Natürlich könnte man sich auch auf Wahrscheinlichkeiten verlassen, aber absolute Sicherheit hat man damit halt nicht. Und ob fsck so ein geschreddertes Dateisystem unter Datenverlust wieder in einen sauberen Zustand überführt ist auch noch so eine Frage.

Bei mir war der kaputte Kernel nie aktiv, deswegen bin ich nicht betroffen und muss hier nicht handeln. Ich hoffe jetzt nur, dass man beim neuen Kernel alles richtig gemacht und nichts vergessen hat.

[cosinus]

Ok. Verstanden. Aber wann wird diese Schreiboperation nun benutzt? Es war doch die Rede davon, dass dieser Fehler auftreten kann, aber nicht muss und die Beschreibung des Bugs wird eingeleitet mit einem "There might be ..."

Ich werde also wegen einer Könnte-Vielleicht-Eventuell-Sache ohne weitere jetzt nicht unsere Server plätten und recovern. Und es wurde mir auch noch kein Fehler gemeldet.

[Livingston]

Direct I/O ist kein Hexenwerk. Das kann man sogar selbst in einem kleinen C-Programm verarbeiten.
Hintergrund ist, dass Schreiboperationen üblicherweise gepuffert werden. Von solchen Puffern und Caches gibt es mehrere auf verschiedenen Ebenen.
Will ich z.B. nur ein einzelnes Byte einer Datei auf der Festplatte ändern, wird erst mal in einen Puffer geschrieben, bevor ein kompletter Datenblock auf der Platte verewigt wird.
Ein Teil dieser Pufferung lässt sich durch Lowlovel-Programmierung umgehen/minimieren. Öffnet man eine Datei mit der Funktion open() aus der C-Standardlibrary kann man sowas nutzen:

O_DIRECT (since Linux 2.4.10)
Try to minimize cache effects of the I/O to and from this
file. In general this will degrade performance, but it is
useful in special situations, such as when applications do
their own caching. File I/O is done directly to/from
user-space buffers. The O_DIRECT flag on its own makes an
effort to transfer data synchronously, but does not give
the guarantees of the O_SYNC flag that data and necessary
metadata are transferred. To guarantee synchronous I/O,
O_SYNC must be used in addition to O_DIRECT. See NOTES
below for further discussion.

Kann man machen, erschwert aber normalerweise das Leben. Datenbanken dagegen, nehmen die Pufferung gerne selbst in die Hand. Eine Datenbank "weiß" sehr genau, wann und wie sie ökonomisch und zeitsparend Plattenzugriffe durchführt. Sie ist soweit optimiert, dass sie sowas in dem konkreten Fall besser hinbekommt als der Kernel mit seinen Vorgaben, wann und wie zu puffern ist.

EDIT: Ein paar Beschreibungen genauer gefasst.

EDIT 2:
@cosinus: Genau da liegt der Hund begraben. Man weiß nicht, was O_DIRECT benutzt. Datenbanken machen es bestimmt. Browserchache Keine Ahnung, definitiv vielleicht. Und was heißt dann "Daten sind korrupt"? Sind nur Inhalte einzelner Dateien durch einen amoklaufenden Filepositionzeiger betroffen oder kann sich das sogar auf den ganzen ext4-mount beziehen? Vor allem: Kann es mit fsck entdeckt werden? (Btw. Du bekommst demnächst ne Mail von mir )

[slu]

Am Samstag hab ich die Patches installiert und als ich Sonntag vom Bug erfuhr sofort alle Debian-Server die mit 6.1.0-14 mit dem Vorgängerkernel rebootet.

Ja so war es bei uns auch, Samstag Abend schön installiert und Sonntags aus allen Wolken gefallen.

Edit: eine weitere VM mit mariadb ist bisher ohne Fehler. Da läuft ein bisschen zum Testen rein intern ein phpBB Forum.

Bei uns ist bis jetzt auch nichts aufgefallen, aber das muss ja nichts heißen.
Unser KVM Host schreibt die qcow2 auf ext4 mounts, ob da das Direct I/O verwendet wird habe ich noch nicht herausgefunden.

[KP97]

Ich baue ja meine Kernel selbst, heute kam der 6.1.67 in kernel.org. Da wird dann sicher noch was ins Repo nachkommen.
Hoffentlich ist dann wieder alles ok.

[Livingston]

Bei uns ist bis jetzt auch nichts aufgefallen, aber das muss ja nichts heißen.
Unser KVM Host schreibt die qcow2 auf ext4 mounts, ob da das Direct I/O verwendet wird habe ich noch nicht herausgefunden.

Ich hab da was gefunden: https://pve.proxmox.com/wiki/Performance_Tweaks
Es geht zwar um proxmox, aber hier wird Bezug auf KVM genommen. Such mal auf der Seite nach O_DIRECT:

chache=none
...
This mode causes qemu-kvm to interact with the disk image file or block device with O_DIRECT semantics, so the host page cache is bypassed and I/O happens directly between the qemu-kvm userspace buffers and the storage device. Because the actual storage device may report a write as completed when placed in its write queue only, the guest's virtual storage adapter is informed that there is a writeback cache, so the guest would be expected to send down flush commands as needed to manage data integrity. Equivalent to direct access to your hosts' disk, performance wise.

EDIT:
Dann noch das (es erwähnt nicht direkt O_DIRECT, scheint aber der selbe Schalter zu sein wie auf der Proxmox-Seite): https://access.redhat.com/documentation ... io-caching
und außerdem:
https://access.redhat.com/documentation ... io-io_mode

[slu]

Danke für den Link.

Bei uns steht im virt-manager bei der Disk "Cache mode: Hypervisor default".

Laut qemu-img -h wäre der Default "[...] 'writeback' (default, except for convert) [...], damit wäre es writeback und laut Proxmox Seite
Zitat:"interact with the disk image file or block device with neither O_DSYNC nor O_DIRECT semantics".

Wenn ich das richtig verstehe (?) kein Direct I/O?

[Livingston]

Danke für den Link.

Bei uns steht im virt-manager bei der Disk "Cache mode: Hypervisor default".

Laut qemu-img -h wäre der Default "[...] 'writeback' (default, except for convert) [...], damit wäre es writeback und laut Proxmox Seite
Zitat:"interact with the disk image file or block device with neither O_DSYNC nor O_DIRECT semantics".

Wenn ich das richtig verstehe (?) kein Direct I/O?

Eindeutig kein O_DIRECT. Hab hier gerade mal strace über eine KVM-Maschine mit writeback ausgeführt. Keine Spur von Systemaufrufen mit O_DIRECT.

[slu]

Eindeutig kein O_DIRECT. Hab hier gerade mal strace über eine KVM-Maschine mit writeback ausgeführt. Keine Spur von Systemaufrufen mit O_DIRECT.

Damit wären alle meine extrem kritischen Systeme Safe, das wäre ein sehr großes Glück.

@ Livingston, vielen Dank für deine Beiträge und die Eingrenzung / Versuche.

[detix]

Nur mal so ne Frage in die Runde:
Hat denn einer tatsächlich Probleme mit dem gestrigen Kernelupdate gehabt, so das danach irgendetwas nicht mehr funktionierte?

[cosinus]

Nur mal so ne Frage in die Runde:
Hat denn einer tatsächlich Probleme mit dem gestrigen Kernelupdate gehabt, so das danach irgendetwas nicht mehr funktionierte?

Nein, also bei uns sind keine Fehler bisher aufgefallen. Und wenn das wär hätte garantiert einer unsere Kollegen sich bei mir gemeldet. Es waren einige VMWare vSphere VMs auf denen auch MariaDB läuft, die liefen nicht ganz nen Tag von Samstag bis Sonntag mit 6.1.0-14.
Dann noch ein Admin-Desktop-PC, bei dem lief auch für ein paar Stunden der faulty kernel. Keine Probleme. Auch fsck über ein livegrml meldet null Probleme.

[Livingston]

Schnell-Check: Bin ich von dem Kernel-Bug betroffen?

Der Bug kann zuschlagen, wenn Programme einen Systemaufruf der Funktionen open, stat und einigen anderen mit dem Parameter O_DIRECT ausführen. Um ein Programm zu identifizieren, das unter Verdacht steht, mit diesem Parameter zu arbeiten, kann man es mit dem Tool strace aus dem gleichnamigen Paket strace untersuchen. Es protokolliert jeden Betriebssystemaufruf und ist daher sehr geschwätzig. Mit der Option -o werden die Ergebnisse, die strace liefert, in eine Log-Datei geschoben

Code: Alles auswählen

strace -o LOGFILE PROGRAMMNAME

Hier mal ein konkreter Versuch mit dem Editor gedit:

Code: Alles auswählen

strace -o ~/geditprotokoll.txt gedit

Im Editor schreibe ich nun ein paar Buchstaben und erzwinge eine Schreibaktion, indem ich das Dokument abspeichere. Danach beende ich gedit und schaue mir den Log von strace mit less ~/geditprotokoll.txt an. Da der aber viel zu lang ist, kann ich auch gleich nach dem Delinquenten mit grep suchen:

Code: Alles auswählen

grep "O_DIRECT" ~/geditprotokoll.txt

und werde vermeintlich fündig:

Code: Alles auswählen

openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 9
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gvfs/modules", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/home/lstone/.local/share/gedit/plugins", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gedit/plugins", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 10
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gedit/plugins/externaltools", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gedit/plugins/pythonconsole", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gedit/plugins/quickopen", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
openat(AT_FDCWD, "/usr/lib/gedit/plugins", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/etc/fonts/conf.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 10
openat(AT_FDCWD, "/usr/share/fontconfig/conf.avail", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 10
openat(AT_FDCWD, "/home/lstone/.local/share/gtksourceview-4/language-specs", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/local/share/gtksourceview-4/language-specs", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/gtksourceview-4/language-specs", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 10
openat(AT_FDCWD, "/usr/share/icons", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 10
openat(AT_FDCWD, "/usr/share/pixmaps", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 10
openat(AT_FDCWD, "/home/lstone/.local/share/gtksourceview-4/styles", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/local/share/gtksourceview-4/styles", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/gtksourceview-4/styles", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 10
openat(AT_FDCWD, "/home/lstone/.local/share/gedit/styles", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/enchant-2", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/enchant-2", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
openat(AT_FDCWD, "/usr/lib/aspell", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
openat(AT_FDCWD, "/usr/lib/aspell", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
openat(AT_FDCWD, "/home/lstone/.config/enchant/hunspell", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/local/share/hunspell", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/hunspell", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
openat(AT_FDCWD, "/usr/share/enchant/hunspell", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/hunspell", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
openat(AT_FDCWD, "/home/lstone/.config/enchant/hunspell", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/local/share/hunspell", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/hunspell", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
openat(AT_FDCWD, "/usr/share/enchant/hunspell", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/hunspell", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11

Noch mal Glück gehabt: Hier taucht zwar der Parameter O_DIRECTORY aber nicht einmal O_DIRECT auf.
D.h. gedit ist höchstwahrscheinlich clean und ist nicht von dem Bug betroffen.

Man sollte aufpassen, wenn man komplexere Programm mit strace aufruft. Es können Prozesse vom Hauptprogramm abgekoppelt werden, die dann nicht mehr von strace beobachtet werden. Ich meine zwar, dass sowas generell auch mit strace machbar ist, müsste mich aber erst mal wieder in das Thema einlesen.

NACHTRAG:
Um auch abgespaltene Prozesse unter strace mitzubeobachten, reicht der Parameter -f, also z.B. zur Beobachtung von Libreoffice Writer:

Code: Alles auswählen

strace -f -o ~/lowriterprotokoll.txt lowriter

Der Output ist ziemlich fett; deshalb sollte man die Untersuchung mit grep durchführen, statt sich durch direktes Nachlesen die Augen kaputtzumachen.

[dasebastian]

Hat denn einer tatsächlich Probleme mit dem gestrigen Kernelupdate gehabt, so das danach irgendetwas nicht mehr funktionierte?

Der betroffene Kernel lief bei mir ein paar Stunden, während derer ich frisch fröhlich an st herumgepatched und anschließend eine Build-Umgebung verräumt habe. Mir ist nichts aufgefallen (mehrmals rebootet). Mir war das Risiko aber dann doch zu groß, weil was, wenn ich jetzt backuppe und irgendwann komm ich drauf, da ist was schief gelaufen. Das ist mein Arbeitsrechner. Deshalb bin ich auf Nummer Sicher gegangen. Wäre der Kernel nicht gelaufen, wär's mir egal gewesen.

Kurze Antwort: lief einige Stunden, nichts aufgefallen, ungutes Gefühl blieb - hier liegen Firmendaten.

[JTH]

@cosinus: Wer von euch beiden zuerst nix mehr in Sachen Kleinkrieg sagt, hat gewonnen.

Hey genau, da schließen wir uns quasi an:

[…]

[…]

Also, nochmal als letzte Warnung an dich, Cordess, und, mitreingezogen, dich cosinus, und wer auch immer sich noch angesprochen fühlen möchte:

Verzichtet hier auf weitere einseitige, beharrlich persönlich gerichtete Kritik und Sticheleien. Beim nächsten entsprechenden Beitrag gibts für denjenigen mindestens einen Tag* Forenauszeit.

Ihr habt eure Kritik geäußert, es gab Gegenargumente – alles weitere führt hier offensichtlich und erfahrungsgemäß zu nichts.

*) Je nachdem, welcher Mod auf den Button klickt …

Im Bereich 'Smalltalk' mag das ja ganz nett sein, da zuzuschauen, aber hier?

Mal schauen, ob sich die hilfreichen Beiträge sinnvoll raustrennen lassen … Eigentlich bringt dieses Thema ja einige für andere interessante Infos mit.

[TRex]

Mal schauen, ob sich die hilfreichen Beiträge sinnvoll raustrennen lassen … Eigentlich bringt dieses Thema ja einige für andere interessante Infos mit.

Erledigt: viewtopic.php?t=188545 (der Transparenz halber gesperrt im Smalltalk).

[slu]

Nur mal so ne Frage in die Runde:
Hat denn einer tatsächlich Probleme mit dem gestrigen Kernelupdate gehabt, so das danach irgendetwas nicht mehr funktionierte?

Tatsächlich ist bei uns heute auch nichts aufgefallen, das muss jedoch nichts heißen.
Zumindest ist es nicht so das gleich ein DB Dump komplett abbricht, man kann die DB also generell lesen.

Wenn ich mir so die Changelog von Hardware Raid Controllern anschaue, da steht ja sehr oft was von möglichen defekten Daten.
Ich will auch gar nicht wissen wie oft andere Hardware Probleme nicht auffallen oder andere Bugs (Festplatten/SSDs) usw. aber klar
die Kernel Geschichte hätte man vermeiden können.

[cosinus]

Tatsächlich ist bei uns heute auch nichts aufgefallen, das muss jedoch nichts heißen.

Ich find's trotzdem erstaunlich, dass hier keiner der Betroffenen irgendwelche Fehler bisher feststellen konnte.
BTW: ich hab die Archiv-DEBs von dem 6.1.0-14 noch. Spiel ich gleich mal in eine VM ein und beobachte.

[Livingston]

Vorläufige Zusammenfassung

Durch die konstruktive Recherche vieler hier im Forum, war es möglich herauszufinden, wie sich der Bug des Kernels 6.1.64 auswirken kann.
Es stellte sich heraus, dass im Kernel bestimmte Schreiboperationen falsch synchronisiert waren. Dadurch wurden Aufrufe von Anwendungsprogramme, die diese Operationen nutzten, potenzielle Amokläufer, die wild in Dateien - vielleicht auch an anderen Stellen - innerhalb von ext4-Dateisystemen herumschrieben.
Ein Update auf den aktuellen Kernel verhindert, dass weiterer Schaden angerichtet werden kann.

Die Frage, ob man davon betroffen war/ist, lässt sich nicht komplett beantworten. Sicher ist, dass nur Programme Schaden anrichten können, die bestimmte Betriebssystemaufrufe mit einem besonderen Parameter aufrufen. Dieser heißt O_DIRECT (nicht O_DIRECTORY) und wird hier genau beschrieben:

Code: Alles auswählen

man 2 open

In der manpage findet man dazu eine Kurzerläuterung und weiter unten im Text eine ausführliche Beschreibung.

Will man wissen, ob ein bestimmtes Programm ein Wackelkandidat ist und den entsprechenden Aufruf nutzt, kann man wie hier vorgeschlagen vorgehen:
viewtopic.php?p=1347569#p1347530

Darüberhinaus kann man sich als root auch in laufende Prozesse einklinken und auch diese protokollieren. Der Aufruf von strace erfolgt dann nicht über Angabe des Programnamens sondern mithilfe des Parameters -p und der Prozessnummer, die man mit ps ermitteln kann. Man erhält damit natürlich nur Systemaufrufe ab diesem Zeitpunkt. Im Zweifelsfalle sieht man nichts davon, wie eine Datei vorher geöffnet/erstellt wurde, insbesondere nicht, ob der Parameter O_DIRECT genutzt wurde oder nicht.
Absolute Sicherheit erlangt man demzufolge mit diesem einfachen Hilfsmittel nicht.

Sicher ist, dass viele Datenbanken den (jetzt nicht mehr) gefährlichen Aufruf nutzen. Sie organisieren sich das Schreiben auf HDD/SSD gerne selbst. O_DIRECT hilft dabei, die Schreibvorgänge zu optimieren.

Wer hier mehr Ahnung von der Materie hat, darf gerne ein paar Tipps in die Runde werfen

[slu]

Hier wurde nochmal etwas ergänzt:
https://bugs.debian.org/cgi-bin/bugrepo ... 1057843#78

[MSfree]

Hier wurde nochmal etwas ergänzt:
https://bugs.debian.org/cgi-bin/bugrepo ... 1057843#78

Nochmal zur Verdeutlichung:

While this does not affect every write ever happend on the system on a ext4 filesystem with a broken kernel, O_DIRECT writes might be quite common in in programms trying to get high performance. It might be argued that it is not that common, but it's not inexistant.

Nur Programme, die O_DIRECT zum Schreiben verwenden, konnten Dateien zerstören. Normale Desktopbenutzer sind von dam Problem überhaupt nicht betroffen, denn keines der normalen Desktopprogramme verwendet O_DIRECT.

Wer eine MariaDB betreibt, z.B. als Unterbau für ein Mediawiki oder Nextcloud, der kann betroffen sein.

TTOMK, such file corruptions cannot be easily detected. Candidates to check are every modified file written since booted with the broken kernel 6.1.64-1.

Man soll also alle Dateien suchen, die seit dem Boot des kaputten Kernels verändert wurde, da kann man z.B. mit find machen. Zumindest bekommt man eine Liste potentiell korrupter Dateien. Auch hier gilt, was nicht von eine Datenbank geschrieben wurde, ist mit fast 100%iger Sicherheit in Ordnung.