je viens vous voir car mon système de fichiers passe régulièrement, et cela depuis un an que j’utilise cette machine, en Read-Only. C’est assez insupportable surtout que la seule solution que j’ai trouvée, c’est de shutdown en force, avec accessoirement la perte de tout ce que je n’ai pas sauvegardé.
Je déteste les Lénovo, mais j’ai pas le choix, vu que c’est mon PC Pro ^^
J’ai lancé un test de RAM avec le tool présent sur memtest.org (aucune erreur détectée), bien que je ne sache pas trop comment se comporte un PC sous Linux quand il y a une cellule foireuse sur la RAM, mais ça me paraitrait bizarre qu’une faute matérielle aboutisse à une modification des droits sur tout le système de fichier ; je sais que sur Windows on a un beau BSOD et le système plante, ce qui me parait plus logique, après je suis pas un expert en code kernel xD
Au début, je pensais que c’était dû à VirtualBox, mais j’ai eu ce problème même sans avoir préalablement lancé VirtualBox, alors j’ai soupçonné une faute liée à ma carte réseau - je sais plus trop pourquoi, je crois que j’avais des messages d’erreur - mais aucune certitude. Quant aux logs Kernel bah…une fois le PC rebooté, je les ai plus, ou alors je sais pas où les chercher.
Donc, si vous avez des petites pistes, je suis preneur. Merci ’
Justement, je n’ai pas eu accès aux logs, vu que je rebootais le PC en force - j’ai pas essayé dmesg avant de reboot -…j’ai juste fait un grep -rni errors=remount,ro * dans /var/logs pour le moment, sans succès…
Justement, je vois aucun logs kernel dans le dossier. Puis on m’a suggéré d’utiliser smartctl mais il reconnait aucun de mes disques, je dois m’y prendre comme un manche x)
Il itère de 0 à 62, et le error_count reste à 0.
Puis :
# nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning : 0
temperature : 25°C (298 Kelvin)
available_spare : 100%
available_spare_threshold : 5%
percentage_used : 1%
endurance group critical warning summary: 0
Data Units Read : 58���34738 (2,99 TB)
Data Units Written : 101���42988 (5,19 TB)
host_read_commands : 781���29777
host_write_commands : 2���540���42398
controller_busy_time : 338
power_cycles : 300
power_on_hours : 4132
unsafe_shutdowns : 32
media_errors : 0
num_err_log_entries : 1
Warning Temperature Time : 0
Critical Composite Temperature Time : 0
Temperature Sensor 1 : 25°C (298 Kelvin)
Thermal Management T1 Trans Count : 0
Thermal Management T2 Trans Count : 0
Thermal Management T1 Total Time : 0
Thermal Management T2 Total Time : 0
Et enfin :
# nvme sanitize-log /dev/nvme0n1
Sanitize Progress (SPROG) : 65535
Sanitize Status (SSTAT) : 0
Sanitize Command Dword 10 Information (SCDW10) : 0
Estimated Time For Overwrite : 4294967295 (No time period reported)
Estimated Time For Block Erase : 20
Estimated Time For Crypto Erase : 6
Estimated Time For Overwrite (No-Deallocate) : 4294967295 (No time period reported)
Estimated Time For Block Erase (No-Deallocate) : 4294967295 (No time period reported)
Estimated Time For Crypto Erase (No-Deallocate): 4294967295 (No time period reported)
Maintenant que la cause la plus importante est écarté il faudrait vérifier si ce n’est ni le contrôleur ni autre chose qui corrompe le système de fichier.
Il va falloir du coup étudier le fichier journal, tu peux chercher sur la toile comment parser à l’aide de la commande journalctl.
Il te faudra aussi regarder comment est configuré ta journalisation car ce n’est pas du classique, habituellement il y a des fichiers de log comme kern.log, messages, auth.log, etc …
Idem de voir que le système est déclaré comme un Debian 12 avec du Gnome 46 m’étonne beaucoup, surtout si il est en snap.
Qu’est-ce qui est étonnant du coup ? Sachant que j’ai Gnome comme environnement de bureau.
J’ai eu besoin de snap une fois mais j’ai trouvé ça insupportable alors je l’ai dégagé…normalement. Mais je me souviens pas quel tuto j’avais suivi. Il a quoi celui-là ?
Re, il me manquait les paquets syslog-ng et syslog-ng-core. Maintenant j’ai bien :
m@u:/var/log# ls |grep -E "kern|auth|message"
auth.log
kern.log
messages
kern.log contient 12485 rien que pour la journée du 19 (la dernière fois que mon système de fichiers est passé en read-only). J’ai cherché des patterns genre read, only, etc…mais rien de concluant x)
Edit : en fait j’avais pris une photo juste avant de reboot en force la dernière fois que j’ai eu le problème, du coup ça m’a permis de retrouver quelques logs. En gros j’ai ça :
Nov 7 08:34:19 mamachine kernel: Filesystems sync: 0.007 seconds
Nov 7 08:34:19 mamachine kernel: (NULL device *): firmware: direct-loading firmware i915/adlp_dmc_ver2_16.bin
Nov 7 08:34:19 mamachine kernel: (NULL device *): firmware: direct-loading firmware regulatory.db
Nov 7 08:34:19 mamachine kernel: (NULL device *): firmware: direct-loading firmware regulatory.db.p7s
Nov 7 08:34:19 mamachine kernel: (NULL device *): firmware: direct-loading firmware intel/sof-tplg/sof-hda-generic-2ch.tplg
Nov 7 08:34:19 mamachine kernel: (NULL device *): firmware: direct-loading firmware intel/ibt-0040-4150.ddc
Nov 7 08:34:19 mamachine kernel: (NULL device *): firmware: direct-loading firmware i915/adlp_guc_70.bin
Nov 7 08:34:19 mamachine kernel: (NULL device *): firmware: direct-loading firmware i915/tgl_huc.bin
Nov 7 08:34:19 mamachine kernel: (NULL device *): firmware: direct-loading firmware intel/ibt-0040-4150.sfi
Nov 7 08:34:19 mamachine kernel: (NULL device *): firmware: direct-loading firmware iwlwifi-so-a0-hr-b0-72.ucode
Nov 7 08:34:19 mamachine kernel: Freezing user space processes
Nov 7 08:34:19 mamachine kernel: Freezing user space processes completed (elapsed 0.235 seconds)
Nov 7 08:34:19 mamachine kernel: OOM killer disabled.
Nov 7 08:34:19 mamachine kernel: Freezing remaining freezable tasks
Nov 7 08:34:19 mamachine kernel: Freezing remaining freezable tasks completed (elapsed 0.002 seconds)
Nov 7 08:34:19 mamachine kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Nov 7 08:34:19 mamachine kernel: e1000e: EEE TX LPI TIMER: 00000011
Nov 7 08:34:19 mamachine kernel: ACPI: EC: interrupt blocked
Nov 7 08:34:19 mamachine kernel: ACPI: EC: interrupt unblocked
Nov 7 08:34:19 mamachine kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1
Nov 7 08:34:19 mamachine kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3
Nov 7 08:34:19 mamachine kernel: i915 0000:00:02.0: [drm] HuC authenticated
Nov 7 08:34:19 mamachine kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Nov 7 08:34:19 mamachine kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled
Nov 7 08:34:19 mamachine kernel: i915 0000:00:02.0: [drm] GuC RC: enabled
Nov 7 08:34:19 mamachine kernel: nvme nvme0: 8/0/0 default/read/poll queues
Nov 7 08:34:19 mamachine kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
Nov 7 08:34:19 mamachine kernel: OOM killer enabled.
Nov 7 08:34:19 mamachine kernel: Restarting tasks ... done.
Nov 7 08:34:19 mamachine kernel: random: crng reseeded on system resumption
Nov 7 08:34:19 mamachine kernel: thermal thermal_zone9: failed to read out thermal zone (-61)
Nov 7 08:34:19 mamachine kernel: PM: suspend exit
Nov 7 08:34:20 mamachine kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Down
Nov 7 08:34:23 mamachine kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Nov 7 08:34:23 mamachine kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp0s31f6: link becomes ready
Nov 7 08:34:23 mamachine kernel: PM: suspend entry (s2idle)
Nov 7 08:34:26 mamachine kernel: Filesystems sync: 0.371 seconds
Nov 7 08:34:26 mamachine kernel: Freezing user space processes
Nov 7 08:34:26 mamachine kernel: Freezing user space processes completed (elapsed 0.014 seconds)
Nov 7 08:34:26 mamachine kernel: OOM killer disabled.
Nov 7 08:34:26 mamachine kernel: Freezing remaining freezable tasks
Nov 7 08:34:26 mamachine kernel: Freezing remaining freezable tasks completed (elapsed 0.002 seconds)
Nov 7 08:34:26 mamachine kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Nov 7 08:34:26 mamachine kernel: e1000e: EEE TX LPI TIMER: 00000011
Nov 7 08:34:26 mamachine kernel: ACPI: EC: interrupt blocked
Nov 7 08:34:26 mamachine kernel: ACPI: EC: interrupt unblocked
Nov 7 08:34:26 mamachine kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1
Nov 7 08:34:26 mamachine kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3
Nov 7 08:34:26 mamachine kernel: i915 0000:00:02.0: [drm] HuC authenticated
Nov 7 08:34:26 mamachine kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Nov 7 08:34:26 mamachine kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled
Nov 7 08:34:26 mamachine kernel: i915 0000:00:02.0: [drm] GuC RC: enabled
Nov 7 08:34:26 mamachine kernel: nvme nvme0: 8/0/0 default/read/poll queues
Nov 7 08:34:26 mamachine kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
Nov 7 08:34:26 mamachine kernel: OOM killer enabled.
Nov 7 08:34:26 mamachine kernel: Restarting tasks ... done.
Nov 7 08:34:26 mamachine kernel: random: crng reseeded on system resumption
Nov 7 08:34:26 mamachine kernel: thermal thermal_zone9: failed to read out thermal zone (-61)
Nov 7 08:34:26 mamachine kernel: PM: suspend exit
Nov 7 08:34:26 mamachine kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Down
Nov 7 08:34:29 mamachine kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Nov 7 08:34:29 mamachine kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp0s31f6: link becomes ready
Nov 7 09:09:21 mamachine kernel: microcode: microcode updated early to revision 0x4121, date = 2023-12-07
Sachant que j’ai pris la photo à 9h07 et que j’ai reboot en force à 9h09.
Edit : c’est un peu con l’affichage sur le forum : on est obligé de faire du scroll horizontale parce que la boîte code est ridiculement étroite alors que les écrans sont carrément larges…
Quand tu as un crash, tu reboot et en fonction de l’heure tu peux par exemple retrouver les logs de la façon suivante:
Soit 23:15 l’heure du crash tu peux demander les logs deux heures: journalctl --since "2024-11-26 21:15:00" --until "2024-11-25 23:15:00"
puis pour les logs à partir du dernier reboot: journalctl -b