Yo uso btrfs con Linux 4.10.8. Después de un reinicio completo, Google Chrome afirmó que no pudo encontrar los datos locales. Parte de esto volvió tan pronto como agregué las ID de usuario relevantes, así que tenía curiosidad por saber qué estaba pasando. Miré en ~/.config/google-chrome y encontré esto:
$ ls -i
...
3529523 'Local State'
3529523 'Local State'
...
Es el mismo archivo, con el mismo inodo, dos veces. Supongo que esta podría ser la razón por la que Google Chrome se confundió, aunque parece funcionar bien entre cada reinicio, escribiendo mucho en este archivo Local\State. Sin embargo, cuando lo reinicio, dice que no puede cargar el estado local. Ni las comprobaciones SMART ni btrfsck informan ningún error. ¿Algunas ideas?
Respuesta1
Tengo el mismo problema en btrfs con kernel 4.14.0
pero mi archivo duplicado era .config/google-chrome-unstable/Default/TransportSecurity
. Pude solucionarlo haciendo
cd .config/google-chrome-unstable/Default
mkdir -p ~/tmp/Default
chmod 700 ~/tmp/Default
tar cf - . | (cd ~/tmp/Default && tar xf -)
cd ~
rm -rf .config/google-chrome-unstable/Default # this will error because the directory isn't empty because the duplicated file left some residue
mv .config/google-chrome-unstable/Default{,.old}
mv ~/tmp/Default .config/google-chrome-unstable/
Ahora cuando ls -l .config/google-chrome-unstable/Default.old
obtengo:
ls: cannot access '.config/google-chrome-unstable/Default.old/TransportSecurity': No such file or directory
total 0
-????????? ? ? ? ? ? TransportSecurity
En este punto reinicié en modo de usuario único y ejecuté:
umount /home
btrfs check --repair /dev/sdc1
Se dio cuenta del directorio dañado y lo reparó. Es posible que puedas comenzar desde allí, pero dejaré los otros pasos que tomé para que estén completos.