Désastre de redimensionnement de partition : annuler et redémarrer

Règles d’engagement (pour ne pas empirer la situation)

La récupération de partitions n’est pas une question d’héroïsme. Il s’agit de contrôler les écritures. La plupart des « désastres de resize » deviennent irrécupérables parce que quelqu’un continue à « essayer des trucs » qui modifient les métadonnées sur le mauvais périphérique.

Faites ceci en premier

• Arrêtez d’écrire. Si c’est une VM, prenez un snapshot au niveau de l’hyperviseur maintenant. Si c’est physique, clonez le disque ou imagez‑le si possible.
• Travaillez depuis un environnement Live. Ne démarrez pas l’OS cassé en espérant qu’il se rétablisse. Démarrez un ISO de secours pour pouvoir monter en lecture seule et réfléchir clairement.
• Identifiez le disque cible exact. « /dev/sda » n’est pas une caractéristique de personnalité. Utilisez les numéros de série, WWN et identifiants stables.
• Supposez des interactions en couches. Tables de partition, LVM, mdraid, LUKS, systèmes de fichiers, chargeurs de démarrage, fstab/initramfs — les redimensionnements peuvent perturber n’importe lequel de ces éléments.

Une petite plaisanterie, pour décompresser : les partitions sont comme des tatouages — faciles à faire, difficiles à enlever, et elles ne sont jamais plus belles après une séance improvisée.

Feuille de diagnostic rapide

Voici la séquence « reprenez vos repères en moins de 10 minutes ». L’ordre a de l’importance parce qu’il réduit rapidement les domaines de panne.

Première étape : voit‑on même le disque et les partitions ?

• Depuis l’environnement de secours : énumérez les périphériques bloc et les tables de partition.
• Décision : si la table de partition est illisible, vous réparez GPT/MBR avant toute autre chose.

Deuxième étape : peut‑on trouver le système de fichiers racine et le monter en lecture seule ?

• Essayez de monter en lecture seule les partitions susceptibles d’être la racine.
• Décision : si le montage échoue, basculez vers la réparation du système de fichiers et vérifiez les débuts/tailles décalés.

Troisième étape : si la racine se monte, pourquoi ça ne démarre pas ?

• Vérifiez /etc/fstab, les UUID, l’assemblage LVM/mdraid et la configuration du chargeur de démarrage.
• Décision : si les UUID ont changé, corrigez les références et reconstruisez initramfs/GRUB, pas le système de fichiers.

Quatrième étape : incompatibilité UEFI vs BIOS ?

• Vérifiez si le système démarre en mode UEFI et si la partition système EFI existe et est montée.
• Décision : si l’ESP est manquante/corrompue/non montée, réparez‑la et réinstallez GRUB pour l’EFI.

Cinquième étape : confirmez que le « redimensionnement » n’était pas en fait un déplacement

• Comparez les secteurs de départ des partitions avec ce qu’ils étaient auparavant (si vous avez des données historiques, sauvegardes ou notes CMDB).
• Décision : si le secteur de départ a bougé de façon inattendue, traitez‑le comme une récupération de données : minimisez les écritures et restaurez la géométrie correcte.

Faits intéressants et un peu d’histoire

• La limite des 2 TiB de MBR n’est pas un « problème Linux ». Le MBR classique utilise des comptes de secteurs sur 32 bits, ce qui plafonne l’espace adressable sur des secteurs de 512 octets.
• GPT conserve deux copies de son en‑tête et de sa table de partition : une primaire au début et une sauvegarde à la fin du disque. Cela vous sauve quand « le début devient bizarre ».
• UEFI a fait de la partition système EFI (ESP) une citoyenne de première classe. Beaucoup d’échecs de démarrage après un resize sont en réalité des échecs « ESP non montée ».
• GRUB2 est devenu plus modulaire que l’ancien GRUB. Cette flexibilité explique aussi l’existence de « grub rescue> » : il ne trouve pas ses modules ou sa config, donc il panique poliment.
• ext4 peut croître à chaud dans de nombreux cas, mais le réduire reste une opération délicate hors ligne. Les gens se souviennent de « grow est sûr » et oublient que « shrink est un combat au couteau ».
• XFS ne peut pas réduire (par conception). Si vous avez « réduit la partition » sous XFS, vous n’avez pas réduit XFS ; vous avez juste coupé le plancher sous lui.
• LVM a été conçu pour le changement (redimensionnement PV/VG/LV), mais cela ne vous dispense pas d’une table de partition correcte. Il ajoute juste une couche supplémentaire à faire correctement.
• Linux a adopté les montages basés sur UUID pour éviter la variation des noms de périphériques. C’est excellent — jusqu’à ce qu’un redimensionnement/regénération change les identifiants et que votre fstab devienne fiction historique.

Une citation, parce que l’ingénierie de fiabilité apprend la même leçon depuis des décennies. La formulation connue de John Allspaw est souvent paraphrasée ainsi : « Les incidents viennent du travail normal dans des systèmes complexes ; blâmer ne répare pas le système. » (idée paraphrasée)

Ce qui casse réellement lors d’un redimensionnement

« Redimensionner » sonne comme une opération unique. En pratique, c’est une pipeline en plusieurs étapes qui touche des domaines de métadonnées indépendants. Une défaillance à n’importe quelle étape peut casser le démarrage.

1) Changements de géométrie de la table de partition

Si le début de la partition bouge, tout ce qui se trouve dessus est décalé. Les systèmes de fichiers et LVM stockent leurs propres attentes sur l’endroit où ils résident. Déplacez le début et vous pointez l’OS vers le mauvais offset disque. Parfois les données sont encore là ; vous regardez juste à la mauvaise adresse.

2) Les métadonnées du système de fichiers ne correspondent plus au périphérique

Pour ext4, vous pouvez vous retrouver avec un système de fichiers qui croit avoir N blocs, mais la partition n’offre plus que N‑Δ. Les montages échouent, fsck se plaint, ou pire : le montage réussit et les écritures aboutissent dans le vide au‑delà de la nouvelle fin.

Pour XFS, « réduire sous lui » équivaut à un risque de corruption. XFS s’attend à ce que le périphérique bloc ne devienne pas plus petit. Quand cela arrive, vous obtenez des erreurs I/O et des échecs de replay du journal.

3) Les chemins et IDs du chargeur de démarrage dérivent

GRUB référence souvent des UUID ou recherche des partitions spécifiques. Les entrées de démarrage UEFI pointent vers un binaire EFI sur l’ESP. Si l’ESP a bougé, a été reformatée ou n’est pas montée pendant les mises à jour, votre système peut démarrer dans le vide.

4) initramfs ne parvient pas à assembler votre pile de stockage

Si votre racine vit sur LVM, mdraid ou LUKS, l’environnement de démarrage initial doit l’assembler. Le redimensionnement peut modifier l’ordre de découverte des périphériques, perturber mdadm, ou invalider les attentes de crypttab. Le noyau démarre, puis vous laisse dans initramfs parce qu’il ne trouve pas /dev/mapper/root.

Runbook : 14 tâches concrètes avec commandes, sorties et décisions

Ces tâches supposent un environnement de secours Linux. Les commandes sont écrites comme si vous étiez sur la console avec les privilèges root (via sudo ou root direct). Remplacez les noms de périphériques avec précaution.

Task 1: List disks and partitions (trust but verify)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,FSUUID,MOUNTPOINTS,MODEL,SERIAL
NAME        SIZE TYPE FSTYPE FSVER FSUUID                                 MOUNTPOINTS MODEL          SERIAL
sda        477G  disk                                                Samsung_SSD     S4X...
├─sda1     512M  part vfat   FAT32 1A2B-3C4D                              /boot/efi
├─sda2       1G  part ext4   1.0   2c1d...                                /boot
└─sda3   475.5G  part LVM2_member      hP0x...                             
  ├─vg0-root 80G lvm  ext4   1.0   9f7a...                                /
  └─vg0-var  50G lvm  xfs          4e2b...                                /var

Ce que cela signifie : Vous pouvez voir le disque, les partitions, leurs systèmes de fichiers, et si LVM est impliqué.

Décision : Si les partitions attendues sont manquantes ou si les tailles semblent incorrectes, concentrez‑vous d’abord sur l’intégrité de la table de partition avant les réparations de système de fichiers.

Task 2: Confirm partition table type and geometry

cr0x@server:~$ sudo parted -s /dev/sda print
Model: Samsung SSD (scsi)
Disk /dev/sda: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB   fat32              boot, esp
 2      538MB   1612MB  1074MB  ext4
 3      1612MB  512GB   510GB

Ce que cela signifie : Les bornes Start/End sont en unités lisibles ; la table est GPT.

Décision : Si vous attendiez MBR mais voyez GPT (ou vice versa), confirmez le mode de firmware et comment GRUB a été installé. Les incompatibilités provoquent des démarrages fantômes.

Task 3: Get exact start sectors (the only numbers that matter)

cr0x@server:~$ sudo sfdisk -d /dev/sda
label: gpt
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 1000215214

/dev/sda1 : start=        2048, size=     1048576, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B
/dev/sda2 : start=     1050624, size=     2097152, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
/dev/sda3 : start=     3147776, size=  996?..., type=E6D6D379-F507-44C2-A23C-238F2A3DF928

Ce que cela signifie : Ce sont les offsets véritables. Si un redimensionnement a accidentellement déplacé un secteur de départ, cette sortie est votre preuve.

Décision : Si les secteurs de départ ont changé par rapport à des valeurs connues‑bonnes (notes, sauvegardes, captures d’écran, état d’automatisation), arrêtez et planifiez une correction de géométrie. Ne lancez pas fsck ; vous pourriez fscker le mauvais offset.

Task 4: Check GPT consistency and recover backup header if needed

cr0x@server:~$ sudo sgdisk -v /dev/sda
Verifying disk /dev/sda
Problem: The secondary GPT header is not at the end of the disk.
Problem: The secondary partition table is not at the end of the disk.
No problems found. 0 free sectors (0 bytes) available in 0 segments.

Ce que cela signifie : Courant après un changement de taille de disque ou des opérations ratées : le GPT de sauvegarde n’est pas à l’endroit attendu.

Décision : Si sgdisk -v signale des problèmes d’emplacement header/table, prévoyez de les relocaliser avec sgdisk -e (avec précaution). Si des erreurs de CRC apparaissent, priorisez la restauration du GPT depuis l’en‑tête de sauvegarde.

Task 5: Relocate the backup GPT to disk end (safe-ish fix for certain GPT warnings)

cr0x@server:~$ sudo sgdisk -e /dev/sda
Relocating backup data structures to the end of the disk
The operation has completed successfully.

Ce que cela signifie : Les structures GPT de sauvegarde sont déplacées à la bonne position de fin de disque.

Décision : Ne faites cela que lorsque vous êtes sûr que la taille du disque est correcte et que vous ne tentez pas de préserver une ancienne « fin » pour la récupération de données. En cas de doute : imagez le disque d’abord.

Task 6: Probe filesystem signatures (are we looking at the right thing?)

cr0x@server:~$ sudo blkid /dev/sda1 /dev/sda2 /dev/sda3
/dev/sda1: UUID="1A2B-3C4D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="..."
/dev/sda2: UUID="2c1d..." BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="..."
/dev/sda3: TYPE="LVM2_member" PARTUUID="..."

Ce que cela signifie : blkid lit les superblocs sur disque. S’il ne peut pas identifier quelque chose d’attendu, vous pouvez avoir des offsets erronés ou une corruption.

Décision : Si la racine est censée être ext4 mais que blkid indique « unknown », ne formatez pas. Vous êtes là pour récupérer, pas pour créer de nouveaux désastres.

Task 7: Assemble mdraid if present (common in servers)

cr0x@server:~$ sudo mdadm --examine --scan
ARRAY /dev/md0 metadata=1.2 name=server:0 UUID=8b3c...

Ce que cela signifie : Les arrays sont détectables. Si cela ne retourne rien, les métadonnées md peuvent être manquantes ou les périphériques renommés.

Décision : Si des arrays existent, assemblez‑les avant le travail LVM/système de fichiers.

cr0x@server:~$ sudo mdadm --assemble --scan
mdadm: /dev/md0 has been started with 2 drives.

Décision : Si l’assemblage échoue avec « device busy » ou « wrong uuid », arrêtez‑vous et inspectez les membres individuellement ; ne forcez pas l’assemblage sauf si vous êtes sûr de l’état des membres.

Task 8: Activate LVM (if your root is on LVs)

cr0x@server:~$ sudo pvscan
  PV /dev/sda3   VG vg0   lvm2 [475.50 GiB / 0    free]
  Total: 1 [475.50 GiB] / in use: 1 [475.50 GiB] / in no VG: 0 [0   ]

cr0x@server:~$ sudo vgscan
  Found volume group "vg0" using metadata type lvm2

cr0x@server:~$ sudo vgchange -ay
  2 logical volume(s) in volume group "vg0" now active

Ce que cela signifie : Les métadonnées LVM sont lisibles et les LV sont activés.

Décision : Si pvscan ne voit pas le PV, le début de partition a peut‑être bougé ou l’étiquette PV a été écrasée. Traitez d’abord le problème d’offset/géométrie, pas « LVM est cassé ».

Task 9: Try mounting root read-only (don’t be brave yet)

cr0x@server:~$ sudo mount -o ro /dev/vg0/root /mnt
cr0x@server:~$ ls /mnt
bin  boot  dev  etc  home  lib  lib64  opt  root  sbin  usr  var

Ce que cela signifie : Le système de fichiers est montable et probablement intact.

Décision : S’il se monte en lecture seule, vous pouvez souvent réparer le démarrage sans lancer fsck. S’il ne se monte pas, capturez le message d’erreur et basculez vers les vérifications de système de fichiers.

Task 10: Validate fstab vs real UUIDs (classic post-resize failure)

cr0x@server:~$ sudo cat /mnt/etc/fstab
UUID=9f7a...  /      ext4  defaults  0 1
UUID=2c1d...  /boot  ext4  defaults  0 2
UUID=1A2B-3C4D /boot/efi vfat umask=0077 0 1

Ce que cela signifie : fstab utilise des UUID. Bien. Vérifiez qu’ils correspondent à ce que rapporte blkid.

Décision : Si fstab référence des UUID qui n’existent plus, corrigez fstab (et reconstruisez initramfs si nécessaire). Ne « forcez » pas fsck.

Task 11: Check what the initramfs expects (root device, crypt, md, lvm)

cr0x@server:~$ sudo grep -R "UUID=" -n /mnt/etc/default/grub /mnt/etc/crypttab /mnt/etc/fstab 2>/dev/null
/mnt/etc/fstab:1:UUID=9f7a...  /      ext4  defaults  0 1
/mnt/etc/fstab:2:UUID=2c1d...  /boot  ext4  defaults  0 2

Ce que cela signifie : Vous parcourez la surface de configuration qui casse souvent après des redimensionnements.

Décision : Si crypttab référence un ancien UUID pour le conteneur LUKS, initramfs ne verrouillera pas la racine. Mettez‑le à jour et reconstruisez initramfs.

Task 12: Chroot properly (so your repairs hit the installed system)

cr0x@server:~$ sudo mount --bind /dev  /mnt/dev
cr0x@server:~$ sudo mount --bind /proc /mnt/proc
cr0x@server:~$ sudo mount --bind /sys  /mnt/sys
cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/# mount | head
/dev/mapper/vg0-root on / type ext4 (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)

Ce que cela signifie : Vous opérez maintenant dans le contexte de l’OS installé.

Décision : Si la racine est montée en lecture seule dans le chroot et que vous devez éditer des fichiers, remontez‑la en lecture‑écriture seulement après avoir confiance en l’intégrité du système de fichiers.

Task 13: Rebuild initramfs (because it caches storage reality)

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.0-31-generic

Ce que cela signifie : L’image de démarrage initiale est régénérée avec les UUID/modules courants.

Décision : Si vous avez modifié crypttab, la config mdadm ou les réglages LVM, reconstruisez initramfs. L’ignorer est la raison pour laquelle vous vous retrouvez de nouveau à l’invite initramfs à vous demander pourquoi l’univers vous en veut.

Task 14: Reinstall GRUB and regenerate config (BIOS and UEFI paths)

cr0x@server:~$ grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-31-generic
Found initrd image: /boot/initrd.img-6.8.0-31-generic
done

Ce que cela signifie : Pour les systèmes BIOS, GRUB est installé dans le MBR/zone d’embedding du disque. Ensuite la config est régénérée.

Décision : Si vous démarrez réellement en UEFI, grub-install /dev/sda n’est pas la bonne solution. Installez sur l’ESP et assurez‑vous qu’elle est montée sur /boot/efi. Vérifiez le mode de démarrage avant d’agir.

Stratégies « annuler » qui fonctionnent en pratique

Vous ne pouvez pas vraiment « annuler » un redimensionnement de partition comme vous annulez un commit git. Vous pouvez cependant restaurer la géométrie et les références des métadonnées à ce que le système attend. C’est généralement suffisant pour démarrer.

Stratégie A : Restaurer le secteur de début correct de la partition (le gros problème)

Si le début de la partition a bougé, votre système de fichiers/LVM est probablement intact mais déplacé. La correction consiste à remettre le secteur de départ exactement. Le « à peu près » n’existe pas ici. Un décalage d’un secteur est toujours incorrect, juste plus confiant.

Comment le faire dépend de l’outil qui l’a modifié. En pratique, utilisez parted ou sfdisk pour recréer l’entrée de partition avec le début d’origine et une taille qui couvre au moins l’ancien bout du système de fichiers. Vous ne formatez pas. Vous ne créez pas de nouveau système de fichiers. Vous corrigez uniquement l’entrée de table.

Si vous ne connaissez pas l’ancien secteur de départ, vérifiez :

• Anciennes demandes de changement/tickets (parfois quelqu’un a collé la sortie de sfdisk -d).
• Inventaires de monitoring ou snapshots CMDB.
• Sauvegardes de /etc qui peuvent contenir des logs d’installation ou scripts de partitionnement.
• En‑tête de sauvegarde GPT (si la primaire a été détruite) et outils de récupération.

Stratégie B : Corriger la dérive des UUID (fstab/crypttab/grub)

Parfois rien n’a bougé. Vous avez juste changé quelque chose qui a fait varier les identifiants, ou vous avez cloné un disque et maintenant le système a des UUID dupliqués et choisit le mauvais. La correction est ennuyeuse : rendez les identifiants cohérents et corrigez les références.

Mouvements courants :

• Mettre à jour /etc/fstab pour correspondre à blkid.
• Pour les racines chiffrées : mettre à jour /etc/crypttab, puis reconstruire initramfs.
• Pour mdraid : assurer que /etc/mdadm/mdadm.conf est correct, puis reconstruire initramfs.
• Régénérer la configuration GRUB pour qu’il découvre la bonne racine.

Stratégie C : Réparer les métadonnées GPT (quand la table est « valide‑même » mais incohérente)

La sauvegarde d’en‑tête GPT sauve beaucoup de monde. Si sgdisk -v signale une erreur CRC ou une corruption d’en‑tête, vous pouvez souvent restaurer depuis l’en‑tête de sauvegarde, ou la relocaliser en fin de disque après une extension virtuelle.

Cela fonctionne bien quand les partitions de données sont intactes et que seule la tenue du GPT est erronée.

Stratégie D : Réparation du système de fichiers (seulement après correction de la géométrie)

Si vous avez redimensionné un système de fichiers et que l’alimentation est tombée en plein milieu, ou si vous avez mal réglé la limite de partition, vous devrez peut‑être lancer fsck (ext4) ou xfs_repair (XFS). Faites‑le après avoir confirmé que vous pointez au bon offset disque et que le périphérique bloc a la taille attendue.

Deuxième petite plaisanterie, parce que vous l’avez mérité : Rien n’accélère un « resize rapide » comme un manager demandant un ETA.

Réparation du chargeur de démarrage : BIOS/MBR, UEFI et pièges habituels

Les échecs de démarrage après des changements de partition sont souvent des échecs du chargeur déguisés en pannes de stockage. L’astuce est de séparer « le noyau ne trouve pas la racine » de « le firmware ne trouve pas le chargeur ».

Connaître votre mode de démarrage

Depuis un environnement de secours, vérifiez si vous avez démarré l’ISO en mode UEFI. Si l’environnement live est en mode BIOS mais que votre OS installé attend UEFI, vous pouvez toujours monter et réparer — mais soyez délibéré sur l’endroit où vous installez GRUB.

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

Ce que cela signifie : Si ceci affiche UEFI, l’environnement courant supporte les variables EFI et vous pouvez gérer les entrées NVRAM.

Décision : Si vous devez réparer un démarrage UEFI, démarrez l’ISO de secours en mode UEFI. Sinon vous réinstallerez GRUB « avec succès » dans un endroit que le firmware n’utilise jamais.

Vérifier la partition système EFI (ESP)

L’ESP doit être en FAT32, typiquement 100–512MB (parfois plus grande), avec le drapeau esp. Si elle est manquante, déplacée, ou non montée sur /boot/efi pendant les mises à jour de GRUB, votre entrée de démarrage UEFI peut pointer vers un fichier qui n’existe plus.

cr0x@server:~$ sudo lsblk -f | grep -E "vfat|/boot/efi"
sda1 vfat   FAT32 1A2B-3C4D                             /mnt/boot/efi

Décision : Si l’ESP n’est pas montée, montez‑la et relancez l’installation/la génération de config GRUB dans le chroot.

Modèle de réinstallation GRUB UEFI (dans le chroot)

cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
Installing for x86_64-efi platform.
Installation finished. No error reported.

root@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-31-generic
done

Ce que cela signifie : Le binaire EFI est écrit sur l’ESP et la config GRUB est régénérée.

Décision : Si le firmware ne démarre toujours pas, inspectez les entrées NVRAM et envisagez le chemin de secours \EFI\BOOT\BOOTX64.EFI selon les politiques de la plateforme.

Modèle de réinstallation GRUB BIOS (dans le chroot)

Pour les installations BIOS, GRUB nécessite de l’espace d’embedding (souvent dans le gap post‑MBR) ou une partition BIOS boot sur disques GPT. Les opérations de redimensionnement peuvent accidentellement supprimer ce gap ou relabeler la partition BIOS boot.

cr0x@server:~$ sudo parted -s /dev/sda print | grep -i "bios"
Partition Table: gpt

Décision : Si c’est GPT+BIOS, assurez‑vous d’avoir une petite partition BIOS boot (généralement 1–2MB) avec le drapeau bios_grub. Sans cela, l’installation de GRUB peut échouer ou « réussir » sans permettre le démarrage.

Réparation et vérification des systèmes de fichiers (ext4, XFS)

ext4 : vérifier, puis réparer

ext4 est tolérant, mais ne confondez pas « tolérant » avec « invincible ». Si la fin de partition a été définie plus petite que le système de fichiers, ext4 peut monter en lecture seule, refuser de monter, ou afficher des erreurs de replay du journal.

cr0x@server:~$ sudo e2fsck -f -n /dev/vg0/root
e2fsck 1.47.0 (5-Feb-2023)
/dev/vg0/root: clean, 412345/5242880 files, 8123456/20971520 blocks

Ce que cela signifie : -n est un dry‑run. « clean » est ce que vous voulez voir.

Décision : Si le dry‑run indique seulement des problèmes mineurs, planifiez une vraie réparation avec -y en fenêtre de maintenance. Si ça affiche « bad magic number », vous pointez probablement le mauvais périphérique/offset.

cr0x@server:~$ sudo e2fsck -f -y /dev/vg0/root
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vg0/root: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vg0/root: 412346/5242880 files, 8123460/20971520 blocks

Décision : Si fsck modifie le système de fichiers, relancez‑le jusqu’à ce qu’il déclare « clean ». Ensuite montez en lecture seule et validez les chemins clés (/etc, /boot, données applicatives).

XFS : réalités de la réparation

XFS peut croître ; il ne peut pas rétrécir. Si vous avez réduit le périphérique bloc sous‑jacent, vous avez peut‑être tronqué des métadonnées vivantes. Parfois vous pouvez réparer ; parfois il faut restaurer depuis des sauvegardes.

cr0x@server:~$ sudo xfs_repair -n /dev/vg0/var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
Phase 3 - for each AG...
No modify flag set, skipping filesystem flush and exiting.

Ce que cela signifie : Mode dry‑run ; il vous dit si une réparation tenterait des modifications.

Décision : Si cela signale un fort décalage de géométrie, arrêtez et vérifiez si la taille du LV/partition correspond à ce que XFS attend. Corrigez d’abord la taille sous‑jacente (expand), puis réparez.

LVM, RAID et chiffrement : la couche de douleur

Les systèmes modernes empilent des abstractions parce que cela facilite la vie 99 % du temps. Pendant la récupération, vous payez la taxe du 1 % avec intérêts. La clé est de reconstruire la pile du bas vers le haut : disque → partition → mdraid → LUKS → LVM → système de fichiers.

Si vous avez redimensionné une partition contenant un PV LVM

Meilleur cas : la partition a grandi, le PV non, donc vous avez juste besoin de pvresize. Pire cas : la partition a rétréci ou bougé et l’étiquette PV n’est pas là où LVM l’attend.

cr0x@server:~$ sudo pvs -o+pv_used,pv_size,vg_name
  PV         VG  Fmt  Attr PSize    PUsed    VG
  /dev/sda3  vg0 lvm2 a--  <475.50g 130.00g  vg0

Ce que cela signifie : LVM voit le PV et sa taille. Si la taille PV est plus petite que la partition et que vous vouliez l’agrandir, c’est une étape normale post‑resize.

Décision : Si le PV est visible et que vous avez seulement agrandi la partition, lancez pvresize /dev/sda3. Si le PV n’est pas visible, ne créez pas un nouveau PV. Cela écraserait les métadonnées.

cr0x@server:~$ sudo pvresize /dev/sda3
  Physical volume "/dev/sda3" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Si mdraid n’assemble pas après un redimensionnement

Redimensionner des partitions qui servent de membres mdraid peut changer leurs tailles. mdraid est pointilleux : les tailles des membres doivent être compatibles. Si un membre est plus petit, l’array peut refuser de s’assembler ou le marquer comme défaillant.

cr0x@server:~$ sudo cat /proc/mdstat
Personalities : [raid1]
md0 : inactive sdb1[1] sda1[0]
      976630336 blocks super 1.2

unused devices: <none>

Ce que cela signifie : L’array est inactive. Ce n’est pas « correct ». C’est « la racine est sur le point de disparaître ».

Décision : Inspectez chaque membre avec mdadm --examine, comparez les compteurs d’événements, et assurez‑vous que les tailles de partition sont cohérentes avant de forcer l’assemblage.

Si LUKS est en jeu

Si la racine est chiffrée, initramfs doit la déverrouiller. Un redimensionnement ne touche peut‑être pas LUKS lui‑même, mais il peut affecter l’UUID ou le chemin de périphérique référencé dans crypttab, ou le mapping de la partition sous‑jacente.

cr0x@server:~$ sudo cryptsetup luksDump /dev/sda3 | head
LUKS header information for /dev/sda3
Version:        2
UUID:           7c0b...

Décision : Si l’en‑tête LUKS se lit bien, ne « réparez » pas. Corrigez les références et la chaîne de démarrage. Si l’en‑tête est illisible, vous avez une autre classe d’incident — restaurez depuis des sauvegardes ou un backup d’en‑tête si disponible.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: “grub rescue>” prompt after reboot

Cause racine : GRUB ne trouve pas ses modules/config parce que les IDs de partition ont changé, /boot a bougé, ou l’UUID du système de fichiers a changé.

Correctif : Démarrez un ISO de secours, montez la racine et /boot/ESP, chroot, lancez grub-install (approprié à BIOS/UEFI), update-grub, reconstruisez initramfs si la pile de stockage a changé.

2) Symptom: drops to initramfs with “cannot find UUID=…”

Cause racine : fstab/crypttab/initramfs attend un ancien UUID, ou le périphérique n’est pas assemblé (mdraid/LVM non activé) au démarrage initial.

Correctif : En secours, comparez la sortie de blkid avec /etc/fstab et /etc/crypttab. Mettez à jour, puis update-initramfs -u -k all.

3) Symptom: filesystem mounts, but /var or /home missing

Cause racine : Les volumes logiques existent mais n’ont pas été activés, ou les entrées fstab ont changé et les points de montage échouent silencieusement.

Correctif : vgchange -ay, vérifiez les LV avec lvs, examinez journalctl après le démarrage ou montez manuellement pour voir l’erreur réelle.

4) Symptom: ext4 “bad magic number” on fsck

Cause racine : Vous lancez fsck sur le mauvais périphérique (mauvaise partition, mauvais offset dû à un début déplacé), ou le superbloc est endommagé.

Correctif : Confirmez avec blkid et les secteurs de départ de partition. Si la géométrie est correcte, essayez des superblocs alternatifs (mke2fs -n pour lister). Si la géométrie est fausse, réparez la table de partition d’abord.

5) Symptom: XFS log replay errors after resize

Cause racine : Le périphérique bloc sous‑jacent a rétréci ou été tronqué ; XFS voit une géométrie incohérente.

Correctif : Étendez la partition/LV au moins à la taille précédente si possible, puis lancez xfs_repair. Si elle a été réellement tronquée, planifiez une restauration depuis sauvegarde.

6) Symptom: system boots, but kernel panics on root mount

Cause racine : initramfs manque des pilotes/modules pour la pile de stockage, ou le paramètre root= dans GRUB est incorrect.

Correctif : Chroot et reconstruisez initramfs ; régénérez la config GRUB ; vérifiez que les modules de stockage sont inclus.

7) Symptom: “no bootable device” at firmware screen

Cause racine : L’entrée NVRAM UEFI pointe vers un binaire EFI manquant ; l’ESP est corrompue ; ou le secteur de boot BIOS a été écrasé.

Correctif : Montez l’ESP, réinstallez la cible GRUB EFI, assurez‑vous que /boot/efi est correct ; éventuellement créez le chemin EFI de secours. Pour BIOS, réinstallez GRUB sur le disque correct.

Checklists / plan pas à pas

Checklist A: Contenir le périmètre des dégâts

1. Snapshot au niveau hyperviseur/couche de stockage si virtualisé.
2. Si physique, envisagez d’imiter le disque avant d’écrire des réparations.
3. Démarrez un ISO de secours dans le même mode de démarrage (UEFI vs BIOS) que le système installé.
4. Identifiez le disque correct en utilisant model/serial, pas seulement /dev/sdX.

Checklist B: Trier vers le bon domaine de panne

1. Exécutez lsblk et parted print pour voir si les partitions existent et semblent plausibles.
2. Exécutez sfdisk -d pour capturer les secteurs de départ ; comparez aux valeurs connues si disponibles.
3. Exécutez blkid pour confirmer les signatures de systèmes de fichiers sur les partitions attendues.
4. Assemblez mdraid (mdadm --assemble --scan) et activez LVM (vgchange -ay) si applicable.
5. Essayez de monter la racine en lecture seule.

Checklist C: Réparer la chaîne de démarrage (le chemin « ça se monte, mais ça ne démarre pas »)

1. Montez la racine sur /mnt.
2. Montez /boot et /boot/efi si ce sont des partitions séparées.
3. Vérifiez que les UUID dans /mnt/etc/fstab et /mnt/etc/crypttab correspondent à blkid.
4. Bind‑montez /dev, /proc, /sys, puis chroot.
5. Reconstruisez initramfs.
6. Réinstallez GRUB selon le mode de démarrage ; régénérez la config GRUB.
7. Quittez le chroot, démontez, redémarrez.

Checklist D: Réparer le système de fichiers (le chemin « ça ne se monte pas »)

1. Confirmez les secteurs de départ de partition corrects avant fsck/xfs_repair.
2. Pour ext4 : e2fsck -f -n d’abord ; ensuite réparation réelle si nécessaire.
3. Pour XFS : xfs_repair -n d’abord ; ne tentez jamais de « le réduire à nouveau ». Étendez d’abord le périphérique sous‑jacent si géométrie incohérente.
4. Après réparation : montez en lecture seule, validez les données critiques, puis poursuivez les réparations de démarrage.

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

Incident causé par une mauvaise hypothèse : « C’est juste /dev/sda »

Une entreprise SaaS de taille moyenne avait un playbook standard : quand le disque root d’un nœud se remplit, étendre le disque virtuel, faire un partition grow, puis agrandir le système de fichiers. Routinièrement. Jusqu’à ce que ça ne le soit plus.

L’ingénieur d’astreinte a suivi son automatisme et a lancé le resize contre /dev/sda. Dans ce cluster d’hyperviseur, l’ordre udev n’était pas stable selon le template : le disque OS était /dev/sdb, et /dev/sda était un disque de données attaché pour les logs. L’opération de resize a « fonctionné ». Elle a même affiché des messages rassurants. Personne n’aime ces messages autant que celui qui vient de redimensionner le mauvais disque.

Le redémarrage qui a suivi a été catastrophique de façon subtile. Le nœud a démarré, mais le volume de logs était maintenant mal aligné ; le système de fichiers montait sale ; l’application a démarré ; puis a planté sous charge d’écriture. Les alertes étaient confuses : on aurait dit une régression applicative. C’était en fait un problème de géométrie de stockage.

La récupération a pris plus de temps qu’elle n’aurait dû parce que l’équipe a cherché les symptômes au mauvais niveau. Une fois que quelqu’un a comparé lsblk -o MODEL,SERIAL avec la cartographie des disques de la VM, tout s’est éclairci : ils avaient redimensionné le mauvais périphérique, et les noms de périphériques n’étaient pas des identifiants fiables.

Ils ont réparé de la manière ennuyeuse : détacher le disque mal redimensionné, en faire un snapshot, réparer la géométrie de partition en utilisant les secteurs de départ connus du jour précédent, puis exécuter des vérifications de système de fichiers. Le disque OS a ensuite été redimensionné correctement en utilisant des chemins stables /dev/disk/by-id dans les scripts.

Une optimisation qui a mal tourné : rétrécir « l’espace inutilisé » pour économiser

Une équipe d’entreprise voulait réduire les coûts cloud. Quelqu’un a remarqué qu’une flotte de serveurs de build avait des disques de 200GB mais n’utilisait que 40GB. Gain facile : réduire les volumes, économiser. Le plan a été approuvé parce que ça ressemblait à du ménage, pas à de la chirurgie.

Le piège était XFS sur /var, contenant des caches de build et des couches de conteneurs. Le script a réduit la taille de partition d’abord, prévoyant de réduire ensuite le système de fichiers. Cette dernière étape n’existe pas pour XFS. Le script ne le savait pas ; il savait juste appeler parted puis « faire des trucs sur le système de fichiers ».

La plupart des serveurs n’ont pas échoué immédiatement. Ils ont échoué plus tard, sous charge, quand XFS a tenté des allocations près de l’ancienne fin du périphérique. Ça a produit des erreurs I/O, des problèmes de journal, et finalement des nœuds qui ont démarré en mode d’urgence parce que systemd ne pouvait pas monter /var. Les incidents sont arrivés comme une fuite lente, ce qui est le pire type de fuite pour l’attention organisationnelle.

La récupération a été brutale : réétendre les disques à leur taille initiale, réparer XFS si possible, et restaurer depuis des sauvegardes là où la troncature avait endommagé les métadonnées. L’« optimisation » a fini par coûter plus en temps d’ingénierie et en risque opérationnel qu’elle n’a économisé.

Leçon apprise : réduire n’est pas l’inverse d’agrandir. Ni opérationnellement, ni mathématiquement, ni émotionnellement.

Une pratique ennuyeuse mais correcte qui a sauvé la situation : capturer les cartes de partition avant toute modification

Une équipe de services financiers avait une exigence fastidieuse avant tout changement : avant toute opération disque/partition, capturer la sortie de sfdisk -d et la joindre au ticket de changement. Les ingénieurs se plaignaient. Ça ressemblait à de la paperasse déguisée en ingénierie.

Puis une VM de base de données de production a eu une extension de disque et un partition grow. Un ingénieur junior a utilisé un outil GUI qui a accidentellement déplacé le secteur de départ de la partition LVM. C’était une erreur unique, mais elle a décalé l’offset PV. Au redémarrage, le système est tombé dans initramfs. LVM ne trouvait pas le VG. La base de données était down.

Au lieu de deviner, l’astreinte a récupéré le sfdisk -d pré‑changement depuis le ticket, l’a comparé à la géométrie actuelle, et a recréé l’entrée de partition avec le secteur de départ d’origine. LVM a immédiatement reconnu le PV, le VG s’est activé, et la racine a été montée comme si de rien n’était.

Le reste de la réparation a été routinier : reconstruire initramfs pour que le démarrage initial sache comment assembler la pile, réinstaller GRUB par sécurité, redémarrer. Le downtime total a été mesuré en « gens contrariés », pas en « direction convoquée ».

La pratique ennuyeuse a fonctionné parce qu’elle a transformé un mystère en correction géométrique. C’est la différence entre réponse à incident et archéologie.

FAQ

1) Puis‑je « annuler » un redimensionnement de partition ?

Pas d’un simple bouton. Vous pouvez souvent restaurer la géométrie précédente de la partition (surtout le secteur de départ) et corriger la dérive des UUID/config. C’est l’équivalent pratique d’un undo pour de nombreux incidents.

2) Dois‑je lancer fsck immédiatement ?

Non. Confirmez d’abord que vous ciblez le bon périphérique au bon offset. Si le début de la partition a bougé, fsck échouera au mieux et aggravera la situation au pire.

3) Pourquoi ça démarrait avant le redémarrage et échoue après ?

Parce que le noyau en cours d’exécution avait les anciennes mappings en mémoire et utilisait des périphériques bloc déjà ouverts. Le redémarrage force le système à redécouvrir le monde à partir des métadonnées disque, qui est là où vous avez rompu la réalité.

4) Si blkid affiche les bons UUID, pourquoi ça ne monte pas ?

La présence d’un UUID ne garantit pas la cohérence du système de fichiers. Le superbloc peut être lisible mais le journal ou les métadonnées d’allocation incohérentes. Montez en lecture seule ; vérifiez dmesg pour des erreurs I/O ; lancez l’outil de réparation approprié.

5) Quelle est la manière la plus rapide de détecter UEFI vs BIOS ?

En Linux : vérifiez si /sys/firmware/efi existe. Recherchez aussi une partition système EFI (vfat, drapeau esp). Alignez ensuite votre réparation GRUB sur ce mode.

6) Ma racine est sur LVM. Répare‑t‑on les partitions ou LVM en premier ?

Les partitions d’abord. Les métadonnées LVM vivent à des offsets fixes à l’intérieur du PV. Si l’entrée de partition pointe vers le mauvais secteur de départ, LVM cherchera au mauvais endroit et prétendra qu’il manque.

7) Est‑ce que sgdisk -e est sans danger ?

Généralement oui quand le seul problème est que les structures de sauvegarde GPT ne sont pas à la fin du disque après une extension. Ce n’est pas une baguette magique universelle pour réparer GPT. Imagez d’abord si vous suspectez une corruption plus profonde.

8) Pourquoi redimensionner l’ESP importe‑t‑il ?

Le firmware UEFI démarre un binaire EFI depuis l’ESP. Si l’ESP a bougé, a été reformatée, ou n’était pas montée pendant les mises à jour, votre entrée de démarrage peut pointer vers un fichier qui n’existe plus.

9) Et si j’ai réduit la partition plus petite que les données ?

Si vous avez tronqué des données vivantes, vous ne pourrez peut‑être pas tout récupérer. Votre meilleure option est d’étendre immédiatement la partition/LV à la taille précédente (si possible) puis réparer. Si des données au‑delà de la nouvelle fin sont perdues, restaurez depuis sauvegarde.

10) Comment éviter ça la prochaine fois ?

Capturez les cartes de partition avant les changements, utilisez des identifiants stables (/dev/disk/by-id) dans les scripts et runbooks, répétez sur des clones, et séparez clairement « étendre le disque » de « changer le début de partition » avec des garde‑fous explicites dans les outils.

Conclusion : étapes suivantes pour éviter les récidives

Si vous êtes ici parce qu’un resize a anéanti le démarrage, votre travail est d’arrêter l’hémorragie, restaurer la géométrie ou les références, et retrouver une racine montable. La voie la plus rapide n’est rarement « réparer tout ». C’est « réparer la couche qui ment ».

Faites ceci ensuite, même si vous êtes de nouveau en ligne :

• Capturez la vérité post‑récupération : enregistrez lsblk, sfdisk -d, blkid et les détails du mode de démarrage avec le dossier d’incident.
• Automatisez les snapshots pré‑changement : snapshot VM ou snapshot de stockage avant les opérations de partition. Faites‑en une politique, pas de l’héroïsme.
• Standardisez l’identification des périphériques : préférez /dev/disk/by-id dans les scripts et les runbooks.
• Interdisez le shrink casual : traitez les opérations de réduction comme des projets de migration, pas comme du « nettoyage ». Surtout avec XFS.
• Testez le redémarrage : après tout changement de stockage/démarrage, planifiez un redémarrage contrôlé tant que vous avez encore le contexte et le temps.

Les partitions ne sont pas effrayantes. Les écritures non planifiées le sont. Gardez la main stable, vos offsets exacts, et vos réparations ennuyeuses.