Si votre partition /boot est trop petite, linux peut manquer de place pour faire les mises à jour de kernel. Et si votre disque est chiffré, ça complique un peu les choses.

Quand il n’est pas possible de l’agrandir, il peut être plus simple de la déplacer (ce qui consiste techniquement à la recréer ailleurs).

J’ai eu ce cas sur un PC portable (Dell XPS 15 7590), pour lequel je n’avais pas suivi mes propres préconisations de mettre assez de place pour la partition /boot. C’était avec Ubuntu 20.04.

Disclaimer

Les opérations décrites ci-dessous sont risquées : en cas d’erreur, on peut facilement se retrouver avec une machine qui ne démarre plus, qu’il faudra réparer en live-USB.

Je vous conseille de tester d’abord ces manipulations dans une machine virtuelle, en y recréant des partitions similaires (c’est ce que j’ai fait, avec Virtualbox, et en activant l’UEFI sur la VM), et surtout de sauvegarder vos données avant toute manipulation sur la « vraie » machine.

Je décline toute responsabilité!

Stratégie

S’il y a de la place après la partition /boot, il est facile de l’agrandir (avec l’application Disques, par exemple).

Mais il est rare qu’il y ait de la place après cette partition. En général, la partition chiffrée est juste après, et il est compliqué/risqué de la déplacer.

Par contre, s’il vous reste de la place ailleurs sur votre disque, je suggère plutôt de créer une nouvelle partition (avec une taille de 1 Go), pour l’utiliser comme partition de boot à la place de l’ancienne.

Dans mon cas de figure, il y avait le partitionnement suivant :

J’ai redimensionné la partition de Windows (en NTFS), pour ajouter une partition de 500 Mo à la fin, que j’ai configurée comme partition /boot :

Puis j’ai supprimé l’ancienne partition de boot, pour agrandir la nouvelle à 1 Go :

Il aurait aussi été possible de créer cette nouvelle partition de boot à un autre endroit (dans l’espace disponible après ma partition chiffrée).

Changement de la partition de boot

Démarrer sur une clé live-USB d’Ubuntu (de la même version qui est installée). Si votre Ubuntu démarre en UEFI, il faut également démarrer sur la clé en UEFI (c’est indispensable)

Avec l’application Disques (ou en ligne de commande), créer la nouvelle partition de boot (en ext4), puis la monter ainsi que l’ancienne partition de boot, et copier le contenu de l’ancienne partition de boot vers la nouvelle (en sudo en ligne de commande, sinon il manquera des droits : sudo cp -ar /media/ubuntu/ancienne_partition/* /media/ubuntu/nouvelle_partition/)

Puis démonter ces deux partitions.

Ouvrir et monter la partition chiffrée. Attention à utiliser le même nom de device luks que celui utilisé par votre installation d’ubuntu (cf ancien article). Si vous ne le connaissez pas, il faut :

• déverrouiller la partition LUKS (dans l’application Disques, par exemple)
• monter la partition, et aller voir dans le fichier /etc/crypttab le nom LUKS de la partition (en général nompartition_crypt)
• démonter et verrouiller la partition LUKS, puis la déverrouiller/monter en ligne de commande avec le bon nom. Exemple (avec nvme0n1p8_crypt comme nom LUKS, sur la partition nvme0n1p8) :

sudo cryptsetup luksOpen /dev/nvme0n1p8 nvme0n1p8_crypt
sudo mount /dev/mapper/nvme0n1p8_crypt /mnt

Puis faire le chroot, en montant les partitions qui vont bien (dans l’exemple ci-dessous, nvme0n1p1 est la partition UEFI, nvme0n1p7 l’ancienne partition de boot, nvme0n1p8 la partition root chiffrée, et nvme0n1p9 la nouvelle partition de boot. Il faut si besoin l’adapter à vos noms de partitions, et sauter la partie EFI si vous ne démarrez pas en mode UEFI) :

sudo mount /dev/nvme0n1p9 /mnt/boot
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
for i in /sys /dev /dev/pts /proc /run; do sudo mount --bind $i /mnt$i; done
sudo chroot /mnt

Une fois dans le chroot, modifier l’UUID de /boot dans /etc/fstab (en utilisant l’UUID de la nouvelle partition de boot, qu’on peut trouver dans l’application Disques, ou avec un lsblk -f), puis lancer la mise à jour de grub :

grub-install /dev/nvme0n1
update-grub

Ignorer l’éventuel message d’erreur « grub-probe : erreur : impossible de trouver un périphérique GRUB pour /dev/sda1. Vérifiez device.map.. » : il est dû à la clé USB sur laquelle on a booté. Puis sortir du chroot, tout démonter proprement puis rebooter :

exit
sudo umount /mnt/{boot/efi,boot,sys,dev/pts,dev,proc,run,}
reboot

Je conseille ensuite de supprimer l’ancienne partition de boot (pour éviter les confusions ultérieures). Dans mon cas de figure, je l’ai fait directement dans l’application Disques, et j’en ai profité pour agrandir la nouvelle partition boot en récupérant la place libérée : ça peut se faire à chaud.

Dernière étape : changer le propriétaire et les droits sur la partition /boot. En la créant depuis le live-USB, le owner devient « systemd-coredump » au lieu de root, et ne laisse pas l’accès aux autre users. Pour corriger ça :

sudo chown root:root /boot
sudo chmod go+rx /boot

(corrigé le 13/11/2020 : j’avais mis un chmod go+rw au lieu de chmod go+rx)

Annexe : redimensionnement d’une partition chiffrée (si nécessaire)

S’il n’y a pas de place ailleurs sur le disque, il peut être nécessaire de redimensionner d’abord la partition chiffrée (depuis une clé live-USB), pour gagner de la place pour une nouvelle partition boot.

L’application Disques ne supporte pas de redimensionner les partitions chiffrées (l’option est grisée). Sur le papier, Gparted le supporte depuis peu (en tous cas dans la version 1.0.0, fournie avec Ubuntu 20.04). MAIS ça ne marche hélas pas avec le format LUKS2 (utilisé par défaut sur les OS récents, dont Ubuntu 20.04) : https://gitlab.gnome.org/GNOME/gparted/-/issues/59. Et ce n’est pas corrigé dans la dernière version à ce jour (1.1.0). Surtout, l’erreur laisse la partition d’un état compliqué à rattraper (même si la partition fonctionne toujours).

Bref, à cause de ce bug, il ne faut pas utiliser gparted pour redimensionner la partition chiffrée, mais plutôt partitionmanager (l’outil équivalent de KDE). Pour cela, il faut d’abord activer le repo « universe » d’Ubuntu (dans « Logiciels et mises à jour »), puis faire un « sudo apt update && sudo apt install partitionmanager ». Puis lancer partitionmanager, faire un clic-droit sur la partition chiffrée et choisir « déverrouiller », puis « redimensionner/déplacer », puis « Appliquer » tout en haut à gauche de la fenêtre. Il m’est arrivé que partitionmanager fasse une erreur lors de ce type de redimensionnement :

Commande : resize2fs /dev/mapper/luks-b3197c62-7ae8-4732-a16c-d6d0ad9114f2 -2234368s

Impossible de redimensionner le système de fichiers chiffré sur la partition « /dev/sda3 ».

C’est probablement un bug de partitionmanager (au moins dans la version actuelle 4.1.0-1) puisque la syntaxe de la commande resize2fs est incorrecte (valeur négative pour la taille). Heureusement, en refaisant la même opération juste après dans partitionmanager, ça fonctionne (en tous cas à chaque fois que ça m’est arrivé).