Système de fichiers qui passe en Read Only

Salut,

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é.

$ hostnamectl
 Static hostname: ---
   Icon name: computer-laptop
     Chassis: laptop 💻
  Machine ID: 6---0
     Boot ID: 1---f
Operating System: Debian GNU/Linux 12 (bookworm)  
      Kernel: Linux 6.1.0-26-amd64
Architecture: x86-64
Hardware Vendor: Lenovo
Hardware Model: ThinkPad E14 Gen 5
Firmware Version: R2AET36W(1.11)

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 ’

Bonjour,

qu’as-tu regardé exactement dans les logs (quelles commandes/fichiers/journaux)?

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…

Au même endroit que tout les logs, c’est à dire dans /var/log … ceux là c’est kern.log

Au vue du passage en read only je verrai surtout à vérifier l’état de mon disque dur, voir à en changer :smiley:

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)

Quand un système passe en ro, c’est qu’il a eu un problème de stockage.

Comment t’y es-tu pris?

J’ai choppé le nom des disques avec lsblk puis je les ai passé à smartctl, mais il ne les reconnaissait pas…

# lsblk
NAME                      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                       7:0    0     4K  1 loop  /snap/bare/5
loop1                       7:1    0  66,2M  1 loop  /snap/core24/609
loop2                       7:2    0 406,3M  1 loop  /snap/gnome-46-2404/48
loop3                       7:3    0  91,7M  1 loop  /snap/gtk-common-themes/1535
loop4                       7:4    0 211,5M  1 loop  /snap/mesa-2404/143
loop5                       7:5    0  38,8M  1 loop  /snap/snapd/21759
nvme0n1                   259:0    0 476,9G  0 disk  
├─nvme0n1p1               259:1    0   512M  0 part  /boot/efi
├─nvme0n1p2               259:2    0   488M  0 part  /boot
└─nvme0n1p3               259:3    0   476G  0 part  
  └─nvme0n1p3_crypt       253:0    0 475,9G  0 crypt 
    ├─machine--vg-root   253:1    0 468,4G  0 lvm   /
    └─machine--vg-swap_1 253:2    0   976M  0 lvm   [SWAP]

Et :

# smartctl nvme0n1 -d nvme
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-26-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

Smartctl open device: nvme0n1 failed: No such device

Le disque est un SSD âgé d’un an : /

C’est un disque nvme (un ssd pas au format sta), commence par installer le paquet nvme-cli

nvme error-log /dev/nvme0n1 | grep -A2 Entry  | grep -v "................." 
nvme smart-log /dev/nvme0n1
nvme sanitize-log /dev/nvme0n1

Ok, alors :

# nvme error-log /dev/nvme0n1 | grep -A2 Entry  | grep -v "................." 
 Entry[ 0]   
error_count	: 0
[...]
 Entry[ 62]   
error_count	: 0

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.

Donne nous le retour de ls -la /var/log/

Merci pour ton retour. Voici :

# ls -la /var/log/
total 2260
drwxr-xr-x  18 root              root              4096  8 nov.  08:57 .
drwxr-xr-x  15 root              root              4096 25 oct.  17:20 ..
-rw-r--r--   1 root              root                 0  4 nov.  08:56 alternatives.log
-rw-r--r--   1 root              root             30769 10 oct.  14:25 alternatives.log.1
-rw-r--r--   1 root              root              2470 11 sept. 09:04 alternatives.log.2.gz
-rw-r--r--   1 root              root               207 17 juin  09:03 alternatives.log.3.gz
-rw-r--r--   1 root              root               575 12 juin  13:29 alternatives.log.4.gz
-rw-r--r--   1 root              root               740 29 avril  2024 alternatives.log.5.gz
-rw-r--r--   1 root              root              2447 28 mars   2024 alternatives.log.6.gz
-rw-r--r--   1 root              root              9338  5 févr.  2024 alternatives.log.7.gz
drwxr-xr-x   2 root              root              4096 22 nov.  09:01 apt
-rw-------   1 root              root            220051 21 nov.  08:14 boot.log
-rw-------   1 root              root             26652  8 nov.  08:57 boot.log.1
-rw-------   1 root              root            157716  4 nov.  08:56 boot.log.2
-rw-------   1 root              root            147340 30 sept. 08:24 boot.log.3
-rw-------   1 root              root            257183 17 sept. 09:17 boot.log.4
-rw-------   1 root              root             50458  5 juil. 07:57 boot.log.5
-rw-------   1 root              root            120437 29 juin  08:32 boot.log.6
-rw-------   1 root              root             57708 13 juin  08:18 boot.log.7
-rw-rw----   1 root              utmp                 0  4 nov.  08:56 btmp
-rw-rw----   1 root              utmp                 0 17 sept. 09:17 btmp.1
drwxr-xr-x   2 clamav            clamav            4096  4 nov.  08:56 clamav
drwxr-xr-x   2 root              root              4096  8 nov.  08:57 cups
-rw-r--r--   1 root              root              7637 22 nov.  09:01 dpkg.log
-rw-r--r--   1 root              root            273801 28 oct.  09:35 dpkg.log.1
-rw-r--r--   1 root              root             59694 12 sept. 14:10 dpkg.log.2.gz
-rw-r--r--   1 root              root              1675  4 juil. 11:53 dpkg.log.3.gz
-rw-r--r--   1 root              root             19141 12 juin  13:58 dpkg.log.4.gz
-rw-r--r--   1 root              root              5451 30 avril  2024 dpkg.log.5.gz
-rw-r--r--   1 root              root             16145 28 mars   2024 dpkg.log.6.gz
-rw-r--r--   1 root              root              2898 11 mars   2024 dpkg.log.7.gz
-rw-r--r--   1 root              root            175086  6 févr.  2024 dpkg.log.8.gz
drwxr-s---   2 Debian-exim       adm               4096  8 nov.  08:58 exim4
-rw-r--r--   1 root              root                 0  2 nov.   2023 faillog
-rw-r--r--   1 root              root              6780 18 sept. 09:16 fontconfig.log
drwx--x--x   2 root              Debian-gdm        4096  2 nov.   2023 gdm3
drwxr-xr-x   3 root              root              4096  3 nov.   2023 installer
drwxr-xr-x   2 root              root              4096 29 mai   08:38 ipp-usb
drwxr-sr-x+  3 root              systemd-journal   4096  3 nov.   2023 journal
-rw-rw-r--   1 root              utmp            292292 29 juil. 08:31 lastlog
drwxr-xr-x   2 neo4j             adm               4096 15 juil. 19:39 neo4j
drwxr-xr-x   2 root              root              4096 21 juin   2023 openvpn
drwxrwxr-t   2 root              postgres          4096  4 nov.  08:56 postgresql
drwx------   2 root              root              4096  2 nov.   2023 private
lrwxrwxrwx   1 root              root                39  2 nov.   2023 README -> ../../usr/share/doc/systemd/README.logs
drwxr-xr-x   3 root              root              4096 15 juil. 16:06 runit
drwxr-x---   2 root              adm               4096 10 oct.   2023 samba
drwx------   2 speech-dispatcher root              4096 25 nov.   2022 speech-dispatcher
drwxr-xr-x   2 root              root              4096 30 avril  2024 sysstat
-rw-r--r--   1 root              root               102  7 oct.  09:33 vbox-setup.log
-rw-r--r--   1 root              root               102 16 sept. 08:10 vbox-setup.log.1
-rw-r--r--   1 root              root               102 11 sept. 09:04 vbox-setup.log.2
-rw-r--r--   1 root              root               102 30 avril  2024 vbox-setup.log.3
-rw-r--r--   1 root              root               102 29 avril  2024 vbox-setup.log.4
-rw-r--r--   1 root              root             58599  9 nov.   2023 vnetlib
-rw-rw-r--   1 root              utmp            428544 21 nov.  08:15 wtmp

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.

Que te renvoie un cat /etc/issue ?

Rassures moi t’as quand même pas suivi ça ? : Install gnome-46-2404 on Debian using the Snap Store | Snapcraft

Ok ^^ Bon je vais regarder comment faire tout ça.

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à ?

Ceci :

$ cat /etc/issue
Debian GNU/Linux 12 \n \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…

Si tu es sous Debian, c’est rsyslog, pas syslog-ng.

Ah mince. C’est quoi la différence entre les deux ?

Et du coup je suis censé chercher quoi dans les logs ? Vu que le peu que j’avais en tête ne m’a rien donné…

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

Ok, je connaissais pas, merci. Mais du coup rsyslog et les fichiers dans /var/log, j’en fais quoi ?

tu laisses comme ça pour le moment. Ca peut aussi servir à l’occasion.
Résoudre l’incident en premier, ensuite tu aviseras :slight_smile: