Cette commande n’a pas copié les partitions mais seulement la table de partition.
Dans le cas d’une table au format GPT, il me semble que cela clone les UUID de partition (PARTUUID), ce qui peut avoir un impact sur l’amorçage EFI : l’entrée d’amorçage EFI créée par GRUB fait référence à l’UUID de la partition système EFI, s’il y a deux partitions avec cet UUID le firmware UEFI peut réagir de façon imprévue.
Inconvénient : une double copie des données du PV, et une resynchronisation « aveugle » du RAID qui va copier et marquer comme utilisés tous les blocs des SSD, même ceux qui ne contiennent pas de données. Quand la synchronisation sera terminée, tu pourras passer fstrim sur les systèmes de fichiers montés pour TRIMer les blocs inutilisés. Par contre s’il y a de l’espace libre dans le VG je ne connais pas de commande LVM pour le TRIMer ; le seul moyen que je connais consiste à créer un LV factice occupant tout l’espace libre du VG (100%FREE) et à utiliser blkdiscard dessus, ou bien simplement le supprimer si issue_discards = 1 dans /etc/lvm/lvm.conf.
Bienvenue dans la jungle. Amorçage UEFI et RAID logiciel ne font pas bon ménage.
Ton doute est fondé.
Ces deux actions ne sont pas cohérentes. /dev/nvme0n1p1 est déjà « formatée » comme membre de l’ensemble RAID /dev/md0 ; si tu la reformates en partition système EFI (FAT) elle perdra ses attributs de membre RAID. Quant à la synchronisation, elle se fera du membre actuel /dev/nvme0n1p1 vers le nouveau membre /dev/sda1. Tu perdras donc à la fois le contenu de /dev/sda1 et le membre /dev/nvme0n1p1 dans une telle opération.
Avant de poursuivre, tu dois te poser une question : as-tu besoin de mettre en place un amorçage redondant ?
Concernant la mise en RAID logiciel d’une partition EFI, il y a deux problèmes :
-
le firmware UEFI ne reconnaît pas le format RAID de Linux. Une partition système EFI doit être une partition « simple ». On peut contourner ce problème avec un ensemble RAID 1 au format 1.0 qui place le superblock à la fin de la partition et non au début comme le format par défaut 1.2. Ainsi le firmware pourra reconnaître chaque partition membre comme une partition normale.
-
grub-installne peut pas enregistrer un ensemble RAID dans les entrées d’amorçage EFI de la NVRAM. On peut contourner le problème en n’enregistrant pas d’entrée d’amorçage (--nvram) et en installant GRUB dans le « chemin de support amovible » de la partition EFI (--force-extra-removable) si le firmware UEFI le supporte, à pérenniser viadpkg-reconfigure grub-efi-amd64. Les partitions doivent avoir le type « EFI » dans la table de partition.
Une autre méthode consiste à créer deux partitions EFI indépendants (non RAID), à en monter une sur /boot/efi et synchroniser l’autre manuellement avec grub-install --efi-directory=xx après chaque mise à jour de grub-efi-amd64. Inconvénient : avec certains firmwares UEFI, cela ne crée qu’une seule entrée d’amorçage « debian » et remplace la précédente au lieu d’en ajouter une seconde, donc pas de redondance (sauf peut-être si les deux partitions ont le même PARTUUID mais je n’ai pas testé). Contournement : installer GRUB dans le chemin de support amovible comme précédemment.
Dernière possibilité si le firmware UEF I le supporte : basculer l’amorçage en mode BIOS/legacy. Le paquet grub-pc supporte de base l’installation de GRUB dans les MBR de plusieurs disques, il suffit de les spécifier à l’installation. On peut préparer les disques pour les deux modes d’amorçage.