Allouer 192 Mo à ma partition /boot, ce n'est pas suffisant. Deux noyaux + deux initramfs + des broutilles = 135 Mo = pas de place pour un troisième.

Ça fait des années que je le sais. À chaque mise à jour de sécurité par Debian, vlam, erreur lors de la confection de l'initramfs :

pigz: abort: write error on <stdout> (No space left on device)
E: mkinitramfs failure pigz 28
update-initramfs: failed for /boot/initrd.img-5.10.0-16-amd64 with 1

À chaque fois, je supprime (apt purge) un ancien noyau qui traîne et ça débloque l'installation du nouveau.

Mais, avec mon utilisation de la version du noyau empaquetée dans les backports afin de faire fonctionner mon lecteur de cartes SD, ce problème va empirer : puisque j'ai deux noyaux en permanence (celui de Bullseye, au cas où, et celui des backports), j'aurais une erreur à chaque mise à jour de sécurité de Debian puisque la version corrigée du noyau ne pourra pas être installée.

Agrandir ma partition /boot est dans ma liste des choses à faire depuis des années.

Mon SSD est partitionné en quatre : 192 Mo pour la partition EFI (/boot/efi), 192 Mo pour /boot, 96 G pour le système (chiffrement LUKS + LVM), et 142 Go pour quelques données (LUKS). Aucun espace non-alloué.

Redimensionner une partition chiffrée, c'est ardu, alors avec du LVM en plus, laisse tomber.

En revanche, seuls 6 Mo sont occupés sur la partition EFI. J'ai jamais vu ce taux d'occupation augmenter. C'est donc cette partition que je vais réduire.

Avant de procéder, je copie (cp -a) tout mon dossier personnel et mes données sur un disque dur externe que je débranche de mon ordinateur. J'effectue également, avec dd, une copie intégrale de mon SSD dans un fichier image stocké sur un autre disque dur externe que je débranche tout autant.

Je démarre sur un live USB Ubuntu 22.04 (je l'avais tout prêt sous la main, sinon j'aurais dégainé un Debian live).

gparted m'indique qu'il ne peut pas travailler sur du FAT32 car il lui manque les paquets logiciels dosfstools et mtools. sudo apt install dosfstools mtools et c'est réglé.

Je lance le redimensionnement de la partition EFI. gparted affiche une erreur lors de l'étape de la réduction de la partition : « GNU Parted ne peut redimensionner cette partition à cette taille. Nous y travaillons ! ».

Avec une recherche web, j'identifie un autre outil permettant de redimensionner une partition FAT32 sans détruire les données : fatresize. Il faut activer les dépôts universe et l'installer (paquet du même nom).

Mais lui aussi se casse les dents sur ma partition EFI :

$ sudo fatresize /dev/sdb1 -s 42M
fatresize 1.1.0 (20201114)
part(start=2048, end=395263, length=393216)
Error: Unable to satisfy all constraints on the partition.

Amusant : s'il est lancé en mode verbeux (« -v » et « -i ») avec affichage de la progression (« -p »), il n'affiche pas l'erreur. :-

Ça me gonfle. Je décide de détruire la partition EFI et de la recréer à la taille désirée (42 Mo).

Je monte la partition et j'en copie (cp -a) le contenu. Mais, ça sert à rien : j'ai un seul système, Debian, donc grub-install repeuplera tout seul /boot/efi.

Je supprime la partition EFI avec gparted. J'en crée une nouvelle avec gparted. Bien entendu, je laisse l'espace non-alloué après la partition EFI et avant la partition /boot. Je n'oublie pas de positionner les drapeaux « esp » et « boot », présents sur la partition d'origine, sur la nouvelle partition EFI.

J'agrandis la partition /boot de 150 Mo avec gparted. Ça fonctionne impec.

Il faut réinstaller GRUB. J'utilise la méthode chroot classique qui a fait ses preuves. Mais, avec du LUKS (chiffrement), du LVM, et /usr et /var séparées, il y a quelques étapes supplémentaires, alors on va réviser :D :

sudo -i
mkdir /mnt/chroot

cryptsetup luksOpen /dev/sdb3 ssdsys
vgdisplay --short
lvchange -ay debian

mount /dev/mapper/debian-racine /mnt/chroot/
mount /dev/mapper/debian-usr /mnt/chroot/usr/
mount /dev/mapper/debian-var /mnt/chroot/var/
mount /dev/sdb2 /mnt/chroot/boot
mount /dev/sdb1 /mnt/chroot/boot/efi/

mount --bind /dev /mnt/chroot/dev
mount --bind /dev/pts /mnt/chroot/dev/pts
mount --bind /sys /mnt/chroot/sys
mount -t proc /proc /mnt/chroot/proc

chroot /mnt/chroot/
update-grub2
grub-install /dev/sdb
exit

umount /mnt/chroot/proc
umount /mnt/chroot/sys
umount /mnt/chroot/dev/pts
umount /mnt/chroot/dev

umount /mnt/chroot/boot/efi/
umount /mnt/chroot/boot
umount /mnt/chroot/var/
umount /mnt/chroot/usr/
umount /mnt/chroot/

lvchange -an debian
cryptsetup luksClose ssdsys

reboot

Le système ne démarre pas. LUKS me demande ma phrase de passe puis ouvre le conteneur chiffré. LVM fait son taff. / et /usr sont montés (aucun message concernant /var). systemd commence à démarrer des services dont rpcbind que je masque, ce qui affiche l'erreur habituelle et… rien de plus, aucun message d'erreur, rien.

Je redémarre dans le mode de récupération (recovery mode). Au même stade, l'erreur s'affiche clairement : « A start job is running for /dev/disk/by-uuid/723A-1671 ». Ben oui, j'ai recrée la partition /boot/efi, donc elle a changé d'identifiant unique, et celui-ci doit être utilisé dans fstab.

Je laisse systemd attendre 1 minute 30 puis je saisis le mot de passe root pour accéder au shell du mode de récupération. Je récupère le nouvel identifiant de la partition EFI avec un ls -lh /dev/disk/by-uuid (j'aurais aussi pu utiliser blkid /dev/sdb1, mais force de l'habitude…), puis je corrige /etc/fstab (qui consignait « UUID=723A-1671 /boot/efi »).

Je redémarre et cela fonctionne. \o/

Ma partition /boot devrait pouvoir contenir 4 noyaux et initrd, et ma partition /boot/efi est 7 fois plus grande que son binaires EFI de GRUB qu'elle contient, ça laisse le temps de voir venir. \o/