Tiens, et si on ajoutait “data=writeback” a sa partition racine ?
Et BANG : le système demarre en READ ONLY … la cata: impossible de modifier la conf.
~~READMORE~~
En fait, l'incident a eu lieu comme cela.
Dans mon /etc/fstab j'avais simplement ça (extrait) :
/dev/mapper/vg0-system / ext4 errors=remount-ro 0 1
Pour faire des tests de performances , j'ai simplement ajouté data=writeback , ce qui donne:
/dev/mapper/vg0-system / ext4 data=writeback,errors=remount-ro 0 1
Et bien NON , ça ne suffit pas. (j'aurai du m'en douter en me rappelant le montage d'un disk SSD)
Au reboot suivant, je suis bloqué sur une partition système en READ-ONLY .
On peut le vérifier , entre autres, en voyant ça:
# mount | grep system /dev/mapper/vg0-system on / type ext4 (ro,relatime,user_xattr,barrier=1,data=ordered)
ro (pour readonly) et data=ordered …
Et les mount -o remount=rw / ne sont d'aucune aide !!!
# mount -o remount=rw / mount: /dev/mapper/vg0-system already mounted or / busy mount: according to mtab, /dev/mapper/vg0-system is already mounted on /
Le problème c'est que dés le boot, par défaut, le noyau monte la partition en data=ordered et qu'il n'est plus possible d'en changer par la suite.
Combiné avec “errors=remount-ro” , le système voyant une erreur, puisqu'il ne peut appliquer l'option data=writeback , il remonte la partition en “read-only”.
Donc, pour le boot suivant, dans grub, il faut ajouter:
rootflags=data=writeback
Ensuite, aprés avoir enfin une partition “Read-Write”, pour rendre cette modification définitive, ajouter dans /etc/default/grub :
GRUB_CMDLINE_LINUX_DEFAULT="rootflags=data=writeback quiet"
Appliquer la modif avec:
# update-grub
Source: