Debian 13 « Read-only file system » : chemin le plus rapide vers la cause et la récupération

décembre 17, 2025 • février 3, 2026 • Lecture : 30 min • Views: 8

Cet article vous a aidé ?

Ça commence toujours petit : un déploiement qui « ne peut pas écrire dans /var », un job de rotation des logs qui échoue silencieusement, une installation de paquet qui meurt en cours. Puis vous le remarquez : Read-only file system. Sur Debian 13, ce n’est pas une tendance. C’est le noyau qui vous dit qu’il a vu quelque chose de suffisamment grave pour ne plus faire confiance à votre disque.

Votre travail n’est pas de « le rendre à nouveau écrivable ». Votre travail est de comprendre pourquoi le système a décidé qu’il ne pouvait pas écrire en sécurité, de préserver les preuves et de récupérer sans transformer un incident récupérable en une histoire de perte de données.

Ce que signifie réellement « read-only file system » (et pourquoi Debian l’a fait)

Quand vous voyez « Read-only file system », vous faites généralement face à une des trois réalités suivantes :

Le système de fichiers est monté en lecture seule (soit au démarrage, soit remounté en lecture seule à l’exécution).
Le périphérique bloc refuse les écritures (protection en écriture au niveau du périphérique, média défaillant, disque virtuel/SAN en difficulté).
Vous n’écrivez pas réellement là où vous pensez (overlay/containers, montages bind, permissions, ou une couche supérieure pleine/en lecture seule).

Sur Debian 13 avec ext4 (toujours le défaut sur beaucoup d’installations), le schéma courant est : une écriture échoue d’une manière qui suggère de la corruption ou de l’instabilité I/O ; ext4 décide que continuer risquerait davantage de dommages ; le noyau remonte le système de fichiers en lecture seule pour arrêter l’hémorragie. XFS a un comportement similaire quand il détecte certaines classes de problèmes.

Ce n’est pas que l’OS dramatise. C’est l’OS qui fait la moins mauvaise chose face à un stockage incertain.

Règle opérationnelle : le passage en lecture seule est un symptôme, pas un diagnostic. Le diagnostic se trouve dans vos logs et dans la pile de stockage sous-jacente au système de fichiers.

Une citation à garder en tête : « L’espoir n’est pas une stratégie. » — Gene Kranz. En réponse d’incident, ce n’est pas motivant ; c’est un rappel de ne pas « simplement redémarrer pour voir ».

Bloc‑note de diagnostic rapide (premier/deuxième/troisième)

Ceci est le chemin le plus court pour identifier le goulot : système de fichiers vs périphérique bloc vs plateforme. Ne faites pas de freestyle. Suivez cet ordre.

Premier : confirmez ce qui est en lecture seule et si cela a changé à l’exécution

Est‑ce le système de fichiers racine ou un montage de données ?
Est‑ce ro dans les flags de montage ?
Le noyau a‑t‑il remounté à cause d’erreurs ?

Second : scrutez les logs du noyau pour la ligne déclencheuse

ext4 : « Errors detected… remounting filesystem read-only »
XFS : « Log I/O error » ou « xfs_do_force_shutdown »
couche bloc : « I/O error », « timeout », « reset », « aborted command »
périphérique : NVMe « media errors », SATA « UNC », SCSI « sense key »

Troisième : décidez si vous avez affaire à un matériel défaillant ou à une corruption récupérable

Si des erreurs I/O/timeout/reset se répètent : traitez d’abord comme problème matériel/plateforme. Planifiez remplacement/migration.
Si c’est une rafale unique (coupure de courant, crash) et que la santé du périphérique semble propre : vous pouvez probablement réparer avec fsck et continuer.

Si vous êtes de garde et tenté de remonter immédiatement en lecture‑écriture, souvenez‑vous : vous ne pouvez pas configurer plus vite qu’un contrôleur NVMe en train de mourir.

Faits et contexte intéressants (brefs, concrets, utiles)

Fait 1 : ext4 hérite de son comportement « on error » de la philosophie ext3 : quand l’intégrité des métadonnées est douteuse, remonter en lecture seule sert de valve de sécurité.
Fait 2 : L’option de montage ext4 errors=remount-ro est un défaut de longue date sur de nombreuses distributions parce que « continuer à écrire » répand la corruption.
Fait 3 : XFS ne « fsck » pas au sens traditionnel ; il utilise xfs_repair, et il peut forcer l’arrêt du système de fichiers quand il détecte une incohérence de journal ou des erreurs I/O.
Fait 4 : Les disques NVMe exposent des compteurs « Media and Data Integrity Errors » ; non‑zéro ne signifie pas toujours mort imminent, mais des compteurs croissants oui.
Fait 5 : Un hyperviseur peut présenter un disque en lecture seule quand le datastore est plein, quand la chaîne de snapshots est cassée, ou quand il détecte un problème en aval.
Fait 6 : Linux peut monter un système de fichiers en lecture seule proprement au démarrage s’il détecte qu’il faut une récupération (relecture de journal) mais qu’il ne peut pas le faire en toute sécurité (ou si la relecture échoue).
Fait 7 : LVM et dm‑crypt répercutent généralement les erreurs I/O vers le haut ; c’est le système de fichiers qui décide « je passe en lecture seule maintenant ». Voilà pourquoi la cause racine est souvent en dessous du système de fichiers.
Fait 8 : Beaucoup d’incidents « lecture seule » sont déclenchés par des timeouts, pas par de la corruption : des problèmes de lien transitoires (câble/backplane SATA, firmware HBA, basculements de chemin SAN) peuvent provoquer assez d’échecs d’écriture pour déclencher le comportement protecteur.
Fait 9 : L’expérience de récupération de Debian s’est nettement améliorée depuis que systemd a standardisé les modes emergency/rescue ; vous pouvez obtenir un shell sans deviner les runlevels.

Tâches pratiques : commandes, sorties, décisions (12+)

Ce ne sont pas des « lancez tout parce que ça fait productif ». Chaque tâche contient : commande, ce que la sortie signifie, et la décision à prendre.

Task 1: Confirm mount flags (ro vs rw) and scope

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /
/ /dev/mapper/vg0-root ext4 rw,relatime,errors=remount-ro

Signification : Le root est actuellement écrivable (rw). Si vous voyez encore des erreurs, il peut s’agir d’un autre montage comme /var ou /srv, ou d’un overlay dans un conteneur.

Décision : Si vous voyez ro, poursuivez. Si rw, localisez le chemin/périphérique spécifique en lecture seule avec findmnt -R /path ou vérifiez le montage du conteneur de service.

Task 2: Locate which filesystem contains the failing path

cr0x@server:~$ findmnt -T /var/lib/postgresql -no TARGET,SOURCE,FSTYPE,OPTIONS
/var /dev/mapper/vg0-var ext4 ro,relatime,errors=remount-ro

Signification : C’est /var, pas root. Cela change la récupération : vous pouvez démonter seulement /var en mode mono‑utilisateur et le réparer, en laissant root intact.

Décision : Identifiez le périphérique (/dev/mapper/vg0-var) et concentrez‑vous sur le diagnostic là‑dessus.

Task 3: Check kernel ring buffer for the first error

cr0x@server:~$ dmesg -T | egrep -i 'EXT4-fs error|remounting filesystem read-only|I/O error|blk_update_request|Buffer I/O error|nvme|ata[0-9]|reset|timed out' | tail -n 25
[Sat Dec 28 11:04:10 2025] EXT4-fs error (device dm-2): ext4_journal_check_start:83: Detected aborted journal
[Sat Dec 28 11:04:10 2025] EXT4-fs (dm-2): Remounting filesystem read-only

Signification : ext4 a abandonné le journal sur dm-2 (probablement votre LV LVM). C’est soit une corruption due à un arrêt non propre, soit un problème I/O en amont.

Décision : Vous devez maintenant déterminer si l’abandon a été déclenché par des erreurs I/O en dessous (disque, chemin, contrôleur) ou par un crash ponctuel.

Task 4: Correlate with journal logs across boots

cr0x@server:~$ journalctl -k -b -1 -g 'Remounting filesystem read-only|I/O error|nvme|ata|sd ' --no-pager | tail -n 60
Dec 28 10:12:03 server kernel: nvme nvme0: I/O 123 QID 5 timeout, aborting
Dec 28 10:12:04 server kernel: nvme nvme0: Abort status: 0x371
Dec 28 10:12:05 server kernel: EXT4-fs (dm-2): I/O error while writing superblock
Dec 28 10:12:05 server kernel: EXT4-fs (dm-2): Remounting filesystem read-only

Signification : Ce n’est pas un « arrêt non propre ». C’est le disque qui timeoute. ext4 échoue ensuite à écrire des métadonnées et passe en lecture seule.

Décision : Traitez‑le d’abord comme une instabilité de stockage. Planifiez migration/remplacement. Ne faites pas « fsck et oubliez ».

Task 5: Map device-mapper names to real disks

cr0x@server:~$ lsblk -o NAME,KNAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
nvme0n1     nvme0n1  disk  1.8T
├─nvme0n1p1 nvme0n1p1 part  1G  vfat   /boot/efi
└─nvme0n1p2 nvme0n1p2 part  1.8T LVM2_member
  ├─vg0-root dm-0    lvm   80G  ext4   /
  ├─vg0-var  dm-2    lvm  200G  ext4   /var
  └─vg0-home dm-3    lvm  100G  ext4   /home

Signification : Le système de fichiers en échec est sur dm-2 qui se mappe sur /dev/mapper/vg0-var sur nvme0n1p2.

Décision : Votre rayon d’impact inclut tout ce qui est sur cet NVMe. Préparez‑vous à un incident disque complet, pas seulement un LV isolé.

Task 6: Check if the underlying block device is itself read-only

cr0x@server:~$ cat /sys/block/nvme0n1/ro
0

Signification : Le noyau ne considère pas le périphérique comme protégé en écriture. L’état lecture seule est probablement au niveau du système de fichiers, pas une protection matérielle.

Décision : Poursuivez les vérifications de santé du périphérique ; n’assumez pas une « verrouillage matériel ».

Task 7: NVMe SMART / health snapshot

cr0x@server:~$ smartctl -a /dev/nvme0n1 | egrep -i 'model number|firmware|critical warning|media and data integrity errors|error information log entries|percentage used|available spare|temperature'
Model Number:                       ACME NVMe 2TB
Firmware Version:                   3B2QEXM7
Critical Warning:                   0x00
Temperature:                        63 Celsius
Available Spare:                    100%
Percentage Used:                    7%
Media and Data Integrity Errors:    12
Error Information Log Entries:      57

Signification : Des erreurs media/integrity non nulles et de nombreuses entrées d’erreur ne sont pas « normales ». Le disque peut traîner pendant des mois ou tomber en panne ce soir. Quoi qu’il en soit, il a une histoire.

Décision : Si vous tenez aux données, traitez‑le comme à remplacer/migrer. Utilisez les réparations pour rendre le système assez stable pour évacuer, pas pour « rétablir la confiance ».

Task 8: SATA/SCSI disks: check for link resets and bad sectors

cr0x@server:~$ dmesg -T | egrep -i 'ata[0-9].*reset|SATA link|UNC|I/O error|failed command|sense key|medium error' | tail -n 20
[Sat Dec 28 09:58:31 2025] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Sat Dec 28 09:58:33 2025] ata2.00: failed command: WRITE FPDMA QUEUED
[Sat Dec 28 09:58:33 2025] blk_update_request: I/O error, dev sdb, sector 918273645 op 0x1:(WRITE) flags 0x0 phys_seg 8 prio class 0

Signification : Fluctuations de lien + écritures échouées. Cela peut provenir du média du disque, du contrôleur, du backplane, du câble, de l’alimentation, ou simplement d’un alignement de mauvais sorts.

Décision : Arrêtez d’essayer de « réparer le système de fichiers » tant que le transport n’est pas stabilisé. Déplacez la charge, puis investiguez le matériel.

Task 9: Determine if the filesystem thinks it had errors (ext4)

cr0x@server:~$ tune2fs -l /dev/mapper/vg0-var | egrep -i 'Filesystem state|Errors behavior|Last error|Last mount time|Last checked'
Filesystem state:         clean with errors
Errors behavior:          Remount read-only
Last error:               ext4_journal_check_start: Detected aborted journal
Last mount time:          Sat Dec 28 10:11:57 2025
Last checked:             Tue Dec 10 02:14:18 2025

Signification : ext4 a enregistré un état d’erreur. Même si vous remontez en rw, vous travaillez maintenant sur un système de fichiers qui admet avoir eu un mauvais passage.

Décision : Planifiez un démontage contrôlé et un fsck. Si le périphérique est instable, faites‑le après évacuation ou depuis un environnement de récupération stable.

Task 10: Check for “disk full masquerading as read-only”

cr0x@server:~$ df -hT /var
Filesystem              Type  Size  Used Avail Use% Mounted on
/dev/mapper/vg0-var     ext4  197G  197G     0 100% /var

Signification : Les systèmes de fichiers pleins provoquent généralement « No space left on device », pas « read-only file system ». Mais ils peuvent déclencher des échecs en cascade : problèmes de journal, crashs d’applications et états non sûrs.

Décision : Traitez immédiatement la pression d’espace (supprimez en sécurité, faites tourner les logs, déplacez les caches). Mais si le montage est ro, vous avez aussi besoin de la vraie cause dans les logs.

Task 11: Confirm whether systemd put you into emergency mode due to fsck failure

cr0x@server:~$ systemctl status
● server
    State: degraded
     Jobs: 0 queued
   Failed: 1 units
    Since: Sat 2025-12-28 11:07:12 UTC; 2min 13s ago

cr0x@server:~$ systemctl --failed
  UNIT          LOAD   ACTIVE SUB    DESCRIPTION
● var.mount     loaded failed failed /var

Signification : Le démarrage a continué mais une unité de montage a échoué. Parfois systemd vous met en shell d’urgence ; parfois il continue avec une disponibilité partielle des services.

Décision : Concentrez‑vous sur l’unité en échec et son périphérique ; ne poursuivez pas des erreurs applicatives aléatoires en premier.

Task 12: Attempt a safe remount to collect logs (only if storage looks stable)

cr0x@server:~$ mount -o remount,rw /var
mount: /var: cannot remount /dev/mapper/vg0-var read-write, is write-protected.

Signification : Soit le noyau l’a forcé en lecture seule à cause d’erreurs, soit la couche périphérique refuse les écritures.

Décision : Ne bouclez pas cette commande. Retournez aux logs et à la santé du périphérique ; envisagez un démarrage de récupération et un fsck hors ligne.

Task 13: Check mdadm RAID state (if applicable)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[0] sdb1[1]
      976630336 blocks super 1.2 [2/1] [U_]
      bitmap: 1/8 pages [4KB], 65536KB chunk

unused devices: <none>

Signification : RAID1 dégradé : un disque absent ou en échec. Les lectures peuvent encore fonctionner ; les écritures peuvent devenir compliquées selon le mode d’échec et la configuration.

Décision : Remplacez le membre défaillant. Si vous avez aussi des erreurs système de fichiers, déterminez si le problème RAID a précédé le passage en lecture seule ou l’inverse.

Task 14: Check LVM for missing PVs or read-only activation

cr0x@server:~$ pvs -o pv_name,vg_name,pv_size,pv_free,pv_attr
  PV             VG  PSize  PFree  Attr
  /dev/nvme0n1p2  vg0 1.80t  1.42t  a--

Signification : Le PV est présent et actif. Si vous aviez vu des PV manquants ou une activation partielle, cela vous aurait immédiatement orienté vers des problèmes de câblage/chemin de stockage.

Décision : Continuez les vérifications système de fichiers/périphérique ; LVM n’est pas le coupable immédiat ici.

Task 15: Verify whether you’re in a container overlay situation

cr0x@server:~$ mount | egrep -i 'overlay|docker|containerd' | head
overlay on /var/lib/docker/overlay2/abc123/merged type overlay (ro,relatime,lowerdir=...,upperdir=...,workdir=...)

Signification : Le montage overlay est en lecture seule ; cela peut arriver si le upperdir du overlay est sur un système de fichiers qui est devenu en lecture seule ou si le runtime l’a remounté suite à des problèmes.

Décision : Ne vous acharnez pas sur un « bug Docker ». Trouvez le filesystem qui sert de upperdir et diagnostiquez ce montage/périphérique.

Carte des causes racines : stockage, système de fichiers, couche bloc et déclencheurs userspace

1) Le système de fichiers s’est protégé après une vraie erreur I/O

C’est le cas le plus fréquent et le plus important. ext4 et XFS ne passent pas en lecture seule parce qu’ils s’ennuient. Ils le font parce que le noyau leur a signalé qu’une écriture a échoué, ou parce que le système de fichiers a détecté une incohérence interne.

Lignes typiques du noyau :

blk_update_request: I/O error
Buffer I/O error
EXT4-fs error ... Detected aborted journal
XFS (dm-0): log I/O error

Les causes sous‑jacentes vont des SSD défaillants aux HBA instables, en passant par l’instabilité du chemin SAN ou un « quelqu’un a débranché le câble d’alimentation ». Votre objectif est d’identifier quelle couche s’est mal comportée en premier.

2) Le périphérique (ou l’hyperviseur) vous met effectivement en protection écriture

Même si Linux indique /sys/block/.../ro à 0, vos écritures peuvent échouer parce que la plateforme les refuse. En VM, « lecture seule » peut être la version polie de « le datastore est plein » ou « la chaîne de snapshots est cassée ». Sur un SAN, cela peut être un mode de protection côté array après détection d’un problème.

Indice : vous voyez des codes sense SCSI, des timeouts persistants, ou des échecs cohérents sur plusieurs systèmes de fichiers à la fois.

3) Le système de fichiers a été monté en lecture seule au démarrage parce que la récupération n’a pas pu être complétée

Si la relecture du journal échoue, ou si le système de fichiers est marqué pour vérification et que la séquence de démarrage ne peut pas l’effectuer en toute sécurité, vous pouvez vous retrouver avec des montages ro ou dans le mode emergency.

Dans ce scénario, le système dit essentiellement : « Je pourrais monter ça, mais je ne lui fais pas confiance pour écrire sans surveillance. » C’est une limite raisonnable.

4) Vous n’êtes pas sur un système de fichiers normal

OverlayFS, squashfs, images live, images de base immuables et certains environnements durcis peuvent rendre la lecture seule le comportement voulu. La différence : la lecture seule voulue est propre et cohérente ; la lecture seule accidentelle est accompagnée d’erreurs dans le journal du noyau et généralement d’un horodatage précis où les choses ont déraillé.

5) Le système est sain, votre hypothèse ne l’est pas

Parfois le système de fichiers est écrivable ; votre application écrit sur un montage bind en lecture seule, ou tente d’écrire sur une exportation NFS en lecture seule, ou est bloquée par une politique SELinux/AppArmor qui fait ressembler l’erreur à un « read-only » au niveau applicatif. Debian 13 n’est pas spécial ici, mais les déploiements modernes sont suffisamment en couches pour tromper efficacement.

Blague n°1 : Les défaillances de stockage sont comme les réunions — si vous pensez en avoir fini en 15 minutes, c’est que vous n’avez pas encore trouvé le vrai ordre du jour.

Trois mini‑histoires d’entreprise (anonymisées, plausibles et instructives)

Mini‑histoire 1 : L’incident causé par une fausse hypothèse

L’entreprise opérait une flotte Debian propre sur du matériel correct. Un vendredi, un hôte de production a commencé à lancer « Read-only file system » pendant une mise à jour de paquet. L’astreinte a fait ce que beaucoup font sous pression : a remounté root en lecture‑écriture, relancé la mise à jour et déclaré victoire.

L’hypothèse erronée était subtile : ils ont supposé que le remount en lecture seule venait d’un arrêt non propre la semaine d’avant. C’est une cause normale, et l’hôte avait effectivement été redémarré récemment. La cohérence narrative est séduisante.

Mais les logs noyau contenaient deux lignes qui ne cadraient pas : timeouts NVMe intermittents et commandes avortées. Elles ont été ignorées parce que la machine « avait l’air rapide » et la supervision montrait une latence normale la plupart du temps.

Le week‑end, le mode de défaillance du disque s’est aggravé. Les écritures de métadonnées ont échoué plus fréquemment, le système de fichiers est repassé en lecture seule, et la base de données a commencé à journaliser là où elle le pouvait—jusqu’à ne plus le pouvoir. Le lundi matin a amené non seulement une indisponibilité, mais une récupération chaotique : segments WAL partiels, état applicatif incohérent, et une restauration depuis sauvegarde décidée sous supervision exécutive.

La correction n’a pas été brillante. Ils ont remplacé le NVMe, restauré proprement, et mis à jour les runbooks : tout remount en lecture seule nécessite de vérifier les erreurs en couche bloc avant de toucher au système de fichiers. La deuxième fois que ça s’est reproduit des mois plus tard, la réponse a été ennuyeuse et rapide. Ennuyeux, c’est un compliment.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une autre organisation avait une « équipe tigre performance ». Ils optimisaient des charges à fort écritures et voulaient moins de pics de latence. Quelqu’un a proposé des options de montage agressives et du tuning de queue, et ils ont aussi allongé les intervalles de sondage de santé disque pour réduire le bruit de monitoring. Cela a légèrement atténué les graphes. Tout le monde se sentait malin.

Puis un hôte a commencé à voir des timeouts rares sur son chemin de stockage. Avec des contrôles de santé moins fréquents et moins de signaux d’alerte précoces, le premier symptôme visible a été ext4 remountant en lecture seule un volume de données très sollicité. Quand l’équipe a regardé, la charge avait déjà accumulé des erreurs et des retries, amplifiant les timeouts applicatifs.

L’analyse post‑incident a montré que les erreurs de stockage étaient détectables plus tôt : entrées d’erreur SMART et compteurs de timeout croissants dans les logs noyau. Mais la cadence « optimisée » de monitoring n’a pas permis de repérer la tendance. L’équipe avait optimisé pour des dashboards silencieux plutôt que pour une détection précoce.

La leçon était peu glamour : gardez la télémétrie de santé assez fréquente pour détecter les dérives. Une poignée de métriques en plus coûte moins cher qu’un gel de production en pleine journée. Ils ont annulé le changement de sondage et ajouté une alerte spécifique pour les événements « filesystem remounted read-only » extraits du journal noyau.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société financière exploitait des systèmes Debian avec un contrôle de changement strict et une habitude presque désuète : chaque hôte avec stockage avait un « plan d’évacuation » testé et une image de récupération connue disponible via la gestion distante. Ils gardaient aussi un petit /var/log séparé dimensionné raisonnablement et rotated agressivement. Pas excitant. Très adulte.

Un matin, un hôte a mis /var en lecture seule. L’équipe applicative a paniqué parce que cela semblait être « le serveur est mort ». L’ingénieur SRE de garde a sorti le playbook : vérifier les flags de montage, regarder les logs noyau, confirmer des erreurs NVMe sous‑jacentes, et arrêter d’écrire.

Parce que les logs étaient sur un montage séparé avec assez de marge, la piste d’erreur était intacte. Ils ont capturé journalctl, sauvegardé les données SMART, et initié un basculement planifié vers un nœud standby. Ensuite, ils ont démarré l’hôte défaillant en mode récupération, exécuté une vérification en lecture seule d’abord, et n’ont réparé qu’après évacuation des données. Pas de chirurgie nocturne héroïque.

Il a fallu plus de temps pour expliquer à la direction pourquoi la correction était « remplacer le disque » que pour maintenir le service. C’est comme ça qu’on veut faire.

Schémas de récupération qui n’empirent pas les choses

Priorité 1 : Arrêter l’hémorragie, préserver les preuves

Si le système de fichiers est passé en lecture seule à cause d’erreurs I/O, continuer à le marteler de retries peut rendre la plateforme moins stable. Votre premier geste est de réduire la pression d’écriture :

Arrêtez les gros émetteurs d’écritures (bases de données, expéditeurs de logs, queues).
Si c’est un volume non‑root, démontez‑le si possible.
Capturer des preuves : extrait de log noyau, données SMART, mapping lsblk et table de montages.

Priorité 2 : Décidez si vous évacuez ou réparez sur place

Soyons francs : si vous voyez des timeouts de périphérique répétés, des aborts, des resets, ou des compteurs SMART qui montent, évacuez d’abord. La réparation d’un système de fichiers sur un matériel non fiable est un pari, et la physique gagne.

Priorité 3 : Utilisez le bon outil de réparation, au bon mode, au bon moment

ext4 : fsck.ext4 (ou e2fsck). Commencez par une vérification en lecture seule quand vous le pouvez.
XFS : xfs_repair. Si le système de fichiers était monté, vous devez le démonter. XFS repair peut être destructeur s’il est mal utilisé.
btrfs : la récupération suit un autre playbook (scrub, check, stats des devices). N’appliquez pas bêtement des conseils ext4.

Priorité 4 : Remontez en lecture‑écriture seulement après avoir supprimé la cause

Remonter en rw n’est pas une réparation. C’est une décision de reprendre les écritures. Ne le faites que lorsque :

la couche périphérique est stable (plus d’erreurs/timeouts en cours), et
le système de fichiers est cohérent (fsck/replay effectué), et
vous avez accepté le risque (ou migré la charge).

Blague n°2 : Le moyen le plus rapide de rendre un système de fichiers à nouveau écrivable est de lui offrir un dîner et de promettre de ne plus ignorer les avertissements SMART la prochaine fois.

Listes de contrôle / plan étape par étape

Checklist A: Triage système en direct (5–10 minutes)

Identifiez le montage en échec : findmnt -T /path
Confirmez qu’il est effectivement ro : findmnt -no OPTIONS /mount
Extraire la ligne déclencheuse des logs noyau : journalctl -k -b filtrez pour les erreurs I/O et les événements de remount
Mappez dm/LVM aux disques physiques : lsblk
Capturez l’état santé du périphérique : smartctl -a (ou outils vendor si nécessaire)
Réduisez les écritures : stoppez les services ; envisagez un mode lecture seule côté applicatif
Décidez : évacuation vs tentative de réparation

Checklist B: Récupération contrôlée pour ext4 sur un montage non‑root

Arrêtez les services utilisant le montage (bases de données en priorité).
Essayez un unmount propre :
```
cr0x@server:~$ umount /var
umount: /var: target is busy.
```
Signification : Quelque chose tient encore des fichiers ouverts.

Décision : Identifiez et arrêtez les responsables avant de forcer quoi que ce soit.
Trouvez les fichiers ouverts :
```
cr0x@server:~$ lsof +f -- /var | head
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
rsyslogd  612 syslog  1w   REG  253,2  1048576  123 /var/log/syslog
```
Signification : Le logging écrit encore.

Décision : Arrêtez rsyslog/journald persistence (avec précaution), ou redirigez temporairement les logs.
Une fois démonté, lancez un fsck en lecture seule :
```
cr0x@server:~$ fsck.ext4 -fn /dev/mapper/vg0-var
e2fsck 1.47.2 (1-Jan-2025)
Pass 1: Checking inodes, blocks, and sizes
Inode 513124 has illegal block(s).  Clear? no

/dev/mapper/vg0-var: ********** WARNING: Filesystem still has errors **********
/dev/mapper/vg0-var: 123456/13107200 files, 9876543/52428800 blocks
```
Signification : Il y a des erreurs ; -n a refusé de modifier. Bien. Vous savez maintenant qu’une réparation est nécessaire.

Décision : Si le matériel est stable et que vous avez des sauvegardes/évacuation, procédez à une vraie réparation. Sinon, évacuez d’abord.

Réparez avec fsck (cela modifiera les structures sur disque) :

cr0x@server:~$ fsck.ext4 -fy /dev/mapper/vg0-var
e2fsck 1.47.2 (1-Jan-2025)
Pass 1: Checking inodes, blocks, and sizes
Inode 513124 has illegal block(s).  Clear? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/vg0-var: FILE SYSTEM WAS MODIFIED
/dev/mapper/vg0-var: 123455/13107200 files, 9876501/52428800 blocks

Signification : Des réparations ont été appliquées.

Décision : Remontez et validez le comportement applicatif, mais continuez à investiguer le déclencheur initial (surtout s’il y avait des erreurs I/O).

Remontez :
```
cr0x@server:~$ mount /var
```
Signification : Si cela réussit et monte en rw, le système de fichiers est revenu.

Décision : Surveillez l’hôte et planifiez des vérifications plus approfondies. Un système de fichiers réparé sur un disque douteux n’est pas « résolu », il est « temporairement cohérent ».

Checklist C: Root filesystem recovery (the reality show version)

Si le root (/) est en lecture seule et que vous ne pouvez pas récupérer en ligne, utilisez un environnement de démarrage de récupération. Selon votre configuration, c’est l’accès console via gestion distante, un ISO de secours, ou un shell initramfs.

Démarrez en mode rescue/emergency (ou une image live) et assurez‑vous que le root n’est pas monté en écriture.

Identifiez le périphérique bloc root :

cr0x@server:~$ blkid | egrep 'ext4|xfs|btrfs|LVM2_member'
/dev/nvme0n1p2: UUID="..." TYPE="LVM2_member"
/dev/mapper/vg0-root: UUID="..." TYPE="ext4"

Signification : Root est un LV ext4.

Décision : Poursuivez le workflow ext4.

Exécutez fsck hors ligne :
```
cr0x@server:~$ fsck.ext4 -fy /dev/mapper/vg0-root
e2fsck 1.47.2 (1-Jan-2025)
/dev/mapper/vg0-root: recovering journal
/dev/mapper/vg0-root: clean
```
Signification : La relecture du journal a réussi ; le système de fichiers est maintenant cohérent.

Décision : Redémarrez normalement. Si vous avez vu des erreurs périphériques auparavant, ne déclarez pas victoire ; planifiez une remédiation matérielle.

Erreurs courantes : symptôme → cause racine → correctif

Mistake 1: “Everything is read-only” after a single app error

Symptôme : Un service journalise « Read-only file system », mais findmnt montre que le système de fichiers est rw.

Cause racine : Le service écrit sur un autre montage (bind mount, overlay de conteneur), ou il touche une exportation NFS en lecture seule, ou un problème de permissions/politique est mal rapporté.

Correctif : Utilisez findmnt -T /path et vérifiez les montages de conteneur. Confirmez avec un test d’écriture direct dans le même namespace que le processus.

Mistake 2: Immediate reboot to “clear” read-only

Symptôme : La machine passe en ro ; quelqu’un la redémarre ; elle revient ; l’incident « résolu »… jusqu’à la prochaine fois.

Cause racine : Le redémarrage efface le symptôme mais détruit le contexte médico‑légal et peut aggraver la corruption si le périphérique est en train de tomber en panne.

Correctif : Avant de redémarrer : capturez journalctl -k, smartctl, et le mapping des périphériques. Si c’est une VM, vérifiez l’état du datastore de l’hyperviseur. Ensuite décidez évacuation vs réparation.

Mistake 3: Running fsck on a mounted filesystem

Symptôme : Quelqu’un exécute fsck.ext4 sur /dev/mapper/vg0-var alors que /var est encore monté.

Cause racine : Panique + réflexe.

Correctif : Démontez d’abord (ou démarrez en récupération). Si vous ne pouvez pas démonter parce que c’est occupé, stoppez les services ; si c’est root, utilisez la récupération hors ligne.

Mistake 4: “It’s filesystem corruption” when it’s actually storage transport

Symptôme : ext4 a abandonné le journal ; fsck le « répare » ; cela se reproduit un jour plus tard.

Cause racine : Erreurs I/O/timeouts sous‑jacents provenant d’un NVMe, d’un lien SATA, du firmware HBA, ou de basculements de chemin SAN.

Correctif : Traitez les erreurs I/O comme primaires. Remplacez le disque, mettez à jour le firmware, réinsérez câbles/backplane, investiguez le multipath. Puis réparez le système de fichiers.

Mistake 5: Remounting rw and continuing heavy writes to “buy time”

Symptôme : mount -o remount,rw réussit et tout semble aller bien pendant 20 minutes.

Cause racine : La condition d’erreur est toujours présente ; la prochaine écriture de métadonnées échouera et vous ramènera en lecture seule, parfois avec plus de dommages.

Correctif : Utilisez le remount rw uniquement comme étape contrôlée pour évacuer des données ou valider après réparation. Ne reprenez pas la charge normale tant que le déclencheur n’est pas traité.

Mistake 6: Ignoring a full filesystem because “read-only is the real issue”

Symptôme : /var est plein à 100 %, les services échouent, puis le système de fichiers devient bizarre.

Cause racine : La pression d’espace provoque des crashs applicatifs et du churn de métadonnées ; combinée à un crash, cela peut laisser le système de fichiers dans un état nécessitant une récupération. Cela peut aussi faire cesser la journalisation au moment où vous en avez besoin.

Correctif : Résolvez la pression d’espace durant le triage : libérez de l’espace en sécurité, ajoutez de la capacité, séparez les logs, et appliquez la rétention.

FAQ

1) Pourquoi Debian remonte ext4 en lecture seule au lieu de seulement faire échouer l’écriture ?

Parce que l’intégrité des métadonnées compte. Si ext4 voit des conditions impliquant une incohérence (ou s’il ne peut pas commit des transactions de journal en sécurité), continuer les écritures risque d’élargir la corruption. La lecture seule est une contention.

2) Puis‑je simplement exécuter `mount -o remount,rw` et continuer ?

Vous pouvez, mais vous prenez explicitement le pari que la cause sous‑jacente a disparu. Si les logs noyau montrent des erreurs I/O ou des timeouts, ce pari est généralement perdant. Utilisez le remount rw pour une évacuation contrôlée, pas pour nier le problème.

3) Si `fsck` le répare, cela veut‑il dire que le matériel est sain ?

Non. Les systèmes de fichiers échouent souvent « après » qu’un périphérique ait commencé à lâcher. Un résultat fsck propre indique seulement que la structure sur disque est cohérente à cet instant. Vérifiez SMART, les erreurs I/O noyau et les logs plateforme.

4) Comment savoir si c’était une coupure de courant ou un disque en train de mourir ?

Une coupure de courant montre généralement un arrêt non propre et un besoin de relecture du journal, mais pas des timeouts/aborts répétés de périphérique. Un disque en fin de vie affiche des erreurs I/O, des aborts, des resets, ou des compteurs SMART qui augmentent.

5) Pourquoi je vois ça dans un conteneur alors que le filesystem host est OK ?

Les conteneurs utilisent fréquemment OverlayFS. Si l’upperdir de l’overlay se trouve sur un système de fichiers qui est devenu en lecture seule, le conteneur voit ce comportement. De plus, certaines images montent des chemins en lecture seule volontairement.

6) Quelle est la commande fsck la plus sûre en premier pour ext4 ?

Commencez par une vérification non destructive en lecture seule : fsck.ext4 -fn /dev/DEVICE. Cela vous indique si des réparations sont nécessaires sans modifier quoi que ce soit. Ensuite décidez quand et où exécuter les réparations réelles.

7) XFS a‑t‑il le même comportement « remount ro » ?

Mécanisme différent, même intention. XFS peut forcer l’arrêt du système de fichiers sur certaines erreurs ; le résultat est fonctionnellement similaire : les écritures échouent et le système de fichiers doit être réparé hors ligne avec xfs_repair.

8) Dois‑je laisser le système allumé pour copier des données, ou l’éteindre immédiatement ?

Si le périphérique génère activement des erreurs (timeouts/reset en boucle), gardez l’activité minimale et priorisez l’évacuation. S’il est stable mais que le système de fichiers est en ro, vous pouvez souvent le garder assez longtemps pour collecter les logs et planifier une réparation contrôlée.

9) Et si le filesystem root est en lecture seule et que je ne peux pas me connecter normalement ?

Utilisez l’accès console et démarrez en rescue/emergency. Si vous arrivez dans initramfs, vous pouvez parfois inspecter les logs (limitations possibles) et exécuter des vérifications hors ligne une fois le périphérique visible.

10) Après la récupération, que dois‑je surveiller pour attraper ça plus tôt la prochaine fois ?

Au minimum : modèles de logs noyau pour erreurs I/O et « remounting filesystem read-only », compteurs SMART critiques, et latence/timeouts de stockage. Alertez aussi sur les systèmes de fichiers approchant la capacité, surtout /var.

Prochaines étapes à faire aujourd’hui

Ajoutez un hook de détection : alertez sur les messages noyau contenant « Remounting filesystem read-only » et les erreurs I/O de couche bloc.
Exercez le chemin de récupération : vérifiez que vous pouvez démarrer en mode rescue et accéder aux volumes chiffrés/LVM avec vos identifiants opérationnels réels.
Séparez les rayons d’impact : envisagez des montages séparés pour /var, les bases de données et les logs, dimensionnés avec une marge réaliste.
Rendez l’évacuation banale : documentez comment basculer ou déplacer les charges quand le stockage d’un hôte commence à mentir.
Cessez de faire confiance à « c’est revenu » comme résolution : après tout remount en ro, exigez une note de cause racine : ligne déclencheuse du système de fichiers, snapshot santé du périphérique, et décision de remédiation.

Le passage en lecture seule est la façon dont le noyau vous dit : « Je ne vais pas vous aider à détruire vos propres données. » Prenez l’avertissement. Diagnostiquez le déclencheur, stabilisez le stockage, réparez hors ligne si nécessaire, et ne reprenez les écritures normales qu’ensuite.