[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian : changer de matériel

Le 20/01/2024 à 20:17, culte.org (via linux-31 Mailing List) a écrit :


Dans mon cas, je passe de BIOS à UEFI donc :
"BIOS -> UEFI (si la nouvelle carte mère ne supporte pas l'amorçage legacy BIOS) 

Vérifier ce dernier point avant de se lancer dans des manips lourdes.
Il faut créer une partition système EFI formatée en FAT, la monter sur /boot/efi (répertoire à créer), installer le paquet grub-efi-amd64, le configurer pour forcer l'installation de GRUB dans le "chemin de support amovible" et exécuter grub-install --force-extra-removable --no-nvram" 

J'ai oublié un paramètre : --target=x86_64-efi
sinon grub-install essaiera d'installer GRUB pour la plate-forme par défaut, i386-pc (BIOS).
Je vais donc suivre : https://www.baeldung.com/linux/convert-disk-mbr-gpt-uefi à partir du §2.5 (ais je bon ? )
On va dire ça. En principe il n'est pas indispensable de convertir la table de partition au format GPT car le firmware UEFI est censé supporter le format DOS/MBR. Mais entre la théorie et la pratique il y a parfois un gouffre, les bugs d'implémentation d'UEFI sont nombreux avec des restrictions toutes plus arbitraires les unes que les autres.
Par contre si tu restes en DOS/MBR il vaut mieux créer une partition EFI pricipale, je ne suis pas sûr qu'une partition EFI logique fonctionne. 


avec comme contrainte :
sdb                      8:16   0 953.9G  0 disk
├─sdb1                   8:17   0   487M  0 part  /boot
Il reste de l'espace libre non partitionné ? Sinon il va falloir réduire une des deux partitions. Réduire la partition /boot sdb1 est plus simple mais cela réduit d'autant l'espace disponible pour GRUB, les noyaux et leurs initramfs. Réduire la partition étendue sdb2 nécessite de réduire la partition logique sdb5, ce qui nécessite de réduire le volume chiffré, ce qui nécessite de réduire le volume physique LVM, ce qui nécessite probablement de réduire un volume logique LVM si tout le PV est alloué. 


Je m'interroge sur l'utilité du §2.7 Adding the ESP Entry in /fstab/
Ou du moins sur la nécessité de laisser l'entrée dans la fstab après les manipulations.
Contrairement à ce que Joyce a écrit, ne pas monter /boot/efi automatiquement au démarrage n'empêchera pas le système de démarrer normalement. Cette partition n'est utile que pour les phases du démarrage qui se déroulent avant que /etc/fstab soit lu. Par contre elle doit être montée pour que GRUB puisse être installé ou mis à jour, lors de la mise à jour des paquets grub* ou shim*.
A noter que la ligne ajoutée dans fstab en 2.7 utilise un PARTLABEL (nom de partition, à ne pas confondre avec l'étiquette de système de fichiers) qui n'existe qu'avec le format GPT et pas avec le format DOS/MBR. D'autre part la syntaxe standard actuelle est PARTLABEL=nom. L'utilisation de l'UUID du système de fichiers (identifiant FAT) avec la syntaxe UUID=XXXX-XXXX est plus universelle. 

La commande grub-install en 2.8 n'est pas bonne.
L'option --bootloader-id=GRUB ne fonctionnera pas avec l'image signée de GRUB pour le secure boot, il faut laisser la valeur par défaut ("debian"). L'option --efi-directory=/boot/efi est déjà la valeur par défaut, elle est donc superflue et ne fait qu'alourdir la commande inutilement. Il manque l'option --force-extra-removable qui permettra de démarrer sans avoir enregistré Debian dans les variable de boot EFI de la nouvelle carte mère (ce qui ne sera possible qu'après avoir démarré en mode EFI).
Ensuite il est inutile de reconstruire grub.cfg avec grub-mkconfig ou grub-install tant qu'on n'a pas démarré en mode EFI. Et même après, cela ne fera tout au plus qu'ajouter une entrée de menu pour entrer dans les paramètres UEFI de la carte mère.