Oki, y'a aucun outil simple pour agrandir une partition chiffrée.
En gros :
- Si la partition chiffrée est la dernière du disque (ou que la dernière partition du disque peut-être déplacée ou supprimée), il suffit d'effacer son entrée dans la table des partitions en la supprimant avec fdisk puis en la recréant (toujours avec fdisk) à partir du même offset de départ et avec une plus grande taille, puis, enfin, de suivre le tuto pointé par ce shaarli (
cryptsetup resize
, pvresize
, lvresize
, etc.) ;
- Si ce n'est pas la dernière partition du disque et qu'elle est suivie par une autre partition chiffrée, alors c'est la grouille : il faut modifier la table des partitions pour déplacer la dernière partition chiffrée puis déplacer les données de cette partition (voir http://matthiaslee.com/moving-a-luks-encrypted-lvm-with-dd-and-sfdisk/ ) puis utiliser la méthode du paragraphe précédent pour la partition chiffrée prise en sandwich…
Dans mon cas, je voulais copier tout le contenu de mon SSD interne sur un autre SSD plus grand et agrandir mes deux partitions chiffrées (car je manque d'espace sur les 2). J'ai 4 partitions primaires:
- /boot/efi - 192M
- /boot : 192M
- / - chiffrée : 60G
- backups - chiffrée : 60G
Ce que j'ai fait :
- J'ai booté sur une clé USB Debian Live, j'ai fait la configuration pour me connecter à Internet sans la Livebox, j'ai installé les logiciels supplémentaires nécessaires (lvm2…) ;
- J'ai
dd
urandom sur l'intégralité du nouveau disque (afin qu'on ne puisse pas faire la différence entre l'espace réellement occupé par les données chiffrées l'espace vide) ;
- J'ai
dd
l'intégralité de l'ancien disque sur le nouveau (branché en USB) ;
- Je me rends compte qu'aucun outil (ni gparted, ni gnome disk utility, ni kde partition manager) est capable de redimensionner/déplacer des partitions chiffrées ;
- Comme les données présentes sur la partition backups sont dispos sur le disque source, je supprime cette partition avec fdisk (d - 4 - w) ;
- "J'agrandis" la partition chiffrée système avec fdisk en la supprimant puis en la recréant au même offset de début (d - 3 - n - p - entrée - +96G (la capacité initiale + l'espace libre supplémentaire) - w) ;
- J'ouvre le volume chiffré, j'active les volumes logiques LVM, je
crypsetup resize
, je pvresize, je lvresize, je resize2fs, tout comme dans le tuto pointé par ce shaarli ;
-
Avec gparted, je crée une nouvelle partition non formatée. J'en fais un volume chiffré, je l'ouvre, j'y mets un système de fichiers ext4 ;
-
À ce stade, ma table des partitions est la suivante :
- /boot/efi - 192M
- /boot : 192M
- / - chiffrée : 96G
- backups - chiffrée : 142G
- J'ouvre et je monte la partition backups de l'ancien disque, je copie sur la nouvelle partition et… erreur : plus d'espace libre disponible. Mais comment ça,
df
indique qu'il reste 92 G dde libre ! Sauf que df -i
montre que la table des inodes est pleine… Ben oui, en créant mon système de fichiers, j'ai viré l'espace réservé à root et j'ai défini un type d'usage "ce disque stockera peu de fichiers mais ce seront de gros fichiers", comme je le fais sur tous mes système de fichiers sur mes supports dédiés au stockage. Sur un disque de 2 T, ça fait environ 466 000 inodes. Sur un disque de 256 G, ça fait seulement environ 36 000 inodes… Évidemment, ce n'est pas un paramètre modifiable à chaud donc je recrée un système de fichiers ext4 avec la commande mkfs.ext4 -L nom -m0 -T largefile /dev/sdXy
. Cette fois-ci, mon système de fichiers peut loger environ 143 000 inodes dans sa table, c'est bien suffisant. Je copie à nouveau tous les dossiers et fichiers de l'ancienne partition vers la nouvelle ;
- Plus qu'à remplacer physiquement l'ancien SSD par le nouveau et à booter dessus : succès. \o/