/ Linux

Corruption de ma partition système sous Archlinux

Il y a quelques jours, j'ai décidé de mettre à jour Windows en installant la dernière version sortie le 29 juillet 2015 : Windows 10. En soit, je partais du principe que ce n'était pas une mauvaise idée, les premiers retours avaient l'air de dire que l'OS est plutôt stable, avec des améliorations significatives et des fonctionnalités sympas.

L'installation s'est très bien passée, aucun soucis pendant ou après, j'ai pu retrouver l'ensemble de mes données, aucun soucis de compatibilité au niveau de mes logiciels. J'ai bien entendu fait 2/3 tweaks au niveau des paramètres de confidentialité (toi même tu sais :o), puis installé OpenVPN avec un autostart au démarrage de la session et Unbound en tant que résolveur/cache local pour éviter les leaks DNS.

J'en ai profité aussi pour basculer mon compte administrateur/cloud en un compte utilisateur normal (sans privliège) et local (plus relié aux services en ligne de Microsoft). L'utilisation quotidienne d'un compte admin est le plus gros vecteur d'attaque sur les systèmes Windows, 95% des failles sous Windows utilisent un "privilege escalation" via un compte administrateur, c'est pour pas rien qu'en entreprise que seuls les comptes administrateur du domaine peuvent modifier les paramètres des postes.

Bon je reviens au problème initiale, si vous voulez bien :D

En voyant que tout fonctionne bien après la mise à jour, je décide de retourner sur mon Arch préférée. Je redémarre le pc, grub arrive en grande pompe, je choisis l'entrée qui va bien et soudain Systemd me dit qu'il n'a pas trouvé la partition système, le service n'a pas pu la monter correctement. Pour information, Systemd utilise l'utilitaire fsck pour vérifier la cohérence d'une partition. Pour bénéficier de ce mécanisme, il faut s'assurer d'avoir mis la valeur 1 au niveau du « fsck pass » dans /etc/fstab). Pour la suite, un mode rescue est proposé afin de faire un état des lieux de la situation et essayer de régler le problème.

Sur le coup je n'ai pas été surpris pas ce problème, ça peut arriver de devoir faire un petit ajustement au niveau du chargeur d'amorçage ou de la table de partition après une mise à jour de Windows comme celle-ci. Surtout que l'opération de dépannage n'est pas très complexe, souvent il suffit juste de recharger le fichier de configuration de grub ou de réparer l'EFISTUB via efibootmgr ou encore d'apporter une petite correction au fstab.

Je me suis retroussé les manches, je boot sur un liveUSB d'arch pour monter mes partitions et chrooter l'ensemble afin d'avoir accès de nouveau à mon environnement. Mais là c'est le drame, un truc je vous dit, je m'y attendais mais pas du tout. Lorsque j'essaye de monter ma partition système (/dev/sda6) avec la commande mount, le message suivant apparaît :

root@arch > mount /dev/sda6 /mnt

mount: write-protected mounting read-only
mount: wrong fs type bad option bad superblock

missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail  or so

Je me suis dit, là il y a réellement un soucis, ça sent un peu le sapin cette histoire. Donc je décide de regarder ce que pouvais m'indiquer les commandes fdisk et lsblk :

root@arch > fdisk -l

Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 33E12B8F-6820-486A-AE6F-7D738CF27DA0

Device         Start       End   Sectors  Size Type
/dev/sda1       2048    616447    614400  300M Windows recovery environment
/dev/sda2     616448    821247    204800  100M EFI System
/dev/sda3     821248   1083391    262144  128M Microsoft reserved
/dev/sda4    1083392 265320447 264237056  126G Microsoft basic data
/dev/sda5  265320448 266242047    921600  450M Windows recovery environment
/dev/sda6  266242048 369625087 103383040 49.3G Linux filesystem
/dev/sda7  369625088 495454207 125829120   60G Linux filesystem
/dev/sda8  495454208 500118158   4663951  2.2G Linux swap

[...]

root@arch > lsblk -f

sda
├─sda1          ntfs     Récupération 18DE7B41DE7B15EA
├─sda2          vfat                  287D-5AB8
├─sda3
├─sda4          ntfs                  06848D73848D65D1
├─sda5          ntfs                  E4A66477A6644BDC
├─sda6
├─sda7          ext4                  a7e55b69-c395-47da-befe-3563300c2c50
└─sda8          swap                  29cb1cf1-d95c-4a1a-a068-629e9196cfb2
sdb
├─sdb1          ntfs     data windows 00DDFF501F77A76A
└─sdb2          ext4     data linux   c8677da0-4c58-4880-9333-8dfda1c5a11f
sdc
├─sdc1          iso9660  ARCH_201507  2015-07-01-16-59-27-00               /run/archiso/bootmnt
└─sdc2          vfat     ARCHISO_EFI  C26D-4E29
[...]

Donc physiquement la partition système (/dev/sda6) est toujours présente sur le disque mais le système n'arrive même pas à reconnaître son type et à lui attribuer un UUID. Donc il y a de fortes chances que la partition soit corrompue. Ce qui est confirmé par la commande fsck.ext4 :

root@arch > fsck.ext4 -v /dev/sda6

fsck.ext4: Group descriptors look bad... trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sda6

/dev/sda6:
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:

    e2fsck -b 8193
 or
    e2fsck -b 32768

La commande fsck conseille d'utiliser un superblock alternatif en tant que backup, le man recommande l'utilisation de mke2fs avec l'option -n pour lister les adresses des superblocks alternatifs potentiels :

root@arch > mke2fs -n /dev/sda6

Creating filesystem with 12922880 4k blocks and 3235840 inodes
Filesystem UUID: ea48b221-602f-473e-b47f-5122f5f8d1b1

Superblock backups stored on blocks:
   32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
   4096000, 7962624, 11239424

Ensuite je tente une réparation avec la commande fsck.ext4. N'hésitez pas à regarder le man pour avoir plus d'information sur les paramètres :

fsck.ext4 -cDfty -C 0 -b {SuperblockAddr}

Il faut bien sûr remplacer {SuperblockAddr} par une des adresses donnée par la commande mke2fs. J'ai essayé la première, la seconde...etc sans succès jusqu'à l'avant dernière adresse (7962624), qui elle a fonctionné.

Après 6h d'exécution, la commande fsck a fini son job. Je vous avouerais qu'à ce moment là je n'y croyais pas des masses, je suis pas un pro de la récupération de données et de la réparation de partition, mais bon je me dit essayons un petit reboot pour voir. La partiton système a bien été réparée par la commande fsck, le système reconnaissait correctement son type et a pu lui attribuer un UUID. Malheureusement, j'ai perdu l'intégralité des données qui étaient dedans, il ne restait plus que le répertoire lost+found, tout avait disparu.

Ô désespoir ! Qu'ai-je fait pour mériter cela ? C'est la première fois que je vois un tel problème se produire, je pense que c'est relativement rare de nos jours, les systèmes de fichier comme EXT3/4 aujourd'hui sont très fiables et robustes mais comme on dit le risque zéro n'existe pas et n'existera jamais.

Heureusement dans l'histoire, j'ai pu retrouver 95% de mes données grâce à un backup que j'avais fait il y a un mois. Après une petite mise à jour via yaourt et une maj du kernel, j'ai pu retrouver mon environnement. Heureusement que la partition home n'a pas été touchée, parce qu'un delta d'un mois sur root (/) ça va, mais sur /home, ça m'aurait fait beaucoup plus mal.

Ceux qui veulent faire la mise à jour vers Windows 10, je vous conseille vivement de sauvegarder l'intégralité de vos données sur un autre disque dur, dans l'idéal sur une autre machine (NAS ou autre).

Pour la sauvegarde, j'ai utilisé rsync de cette manière :

rsync -aAXv --delete --exclude={ ... } /* /data/backup

J'exclus tout ce qui est inutile ou qui prend de la place comme :

/dev
/proc
/sys
/tmp
/run
/mnt
/media
/lost+found
/var/cache
/var/tmp
/var/lib/docker
/home/hardware/.cache
/data/bitcoin/blocks

C'est simple et ça fonctionne du tonnerre !

N'hésitez pas à partager votre expérience dans les commentaires si vous avez déjà eu un cas de corruption d'une partition et partager aussi vos utilitaires de sauvegarde.

Corruption de ma partition système sous Archlinux
Share this