Partition EFI sur raid après changement de disque

Salut,

Quelle galère ces histoires de disk HS (SSD je suppose qu'il claqué sans aucun avertissement ?).

Perso je ferai une copie des fichiers de la partition EFI SSD1 sur le 2eme SSD mais je suppose que c'est ce que tu as fait...

Le mieux serai de pouvoir tester un boot avec le 1er disk désactivé.
En tout cas le sujet m’intéresse au plus haut point et j'espère que tu nous diras les actions menés.

Vi c'est pénible, c'est un nvme qui a disparu d'un coup, aucune alerte avant rien.
Pour le moment je n'ai rien recopié, je me demande si c'est suffisant, si il n'y a pas une commande à faire pour "rebuild" la partition...
J'en n'ai pas la moindre idée en fait :D

J'ai demandé au support si OVH proposait de s'occuper de remonter le raid "proprement" contre facturation... Mais non, ils ne font pas... Alors que leurs techs pourrait faire ça souvent et avoir l'habitude... Moi je fais ça une fois toutes les x années... Depuis les disques SSD puis NVMe les pannes disque devenant vraiment très rares...

Je suis quasi certain qu'il faut recopier le contenu de la partition EFI

ll /boot/efi/EFI/debian/
total 5.9M
drwxr-xr-x 2 root root 8.0K Oct 28 2022 .
drwxr-xr-x 3 root root 8.0K Oct 28 2022 ..
-rwxr-xr-x 1 root root 108 Apr 30 06:17 BOOTX64.CSV
-rwxr-xr-x 1 root root 86K Apr 30 06:17 fbx64.efi
-rwxr-xr-x 1 root root 157 Apr 30 06:17 grub.cfg
-rwxr-xr-x 1 root root 4.0M Apr 30 06:17 grubx64.efi
-rwxr-xr-x 1 root root 832K Apr 30 06:17 mmx64.efi
-rwxr-xr-x 1 root root 931K Apr 30 06:17 shimx64.efi

Après est-ce que ça suffit, je ne sais pas mais je pense que oui car il y a des UUID dans le fichier de conf :

cat /boot/efi/EFI/debian/grub.cfg
search.fs_uuid 60c3b16a-ae14-41fb-94c4-2d6c63132a18 root mduuid/c90815d26a9ecf6d91a07962214fa8c7
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

Pour le moment je n'ai rien recopié

Bonjour,

En novembre j'ai pris un kimsufi KS-16 en location, avec 3 disques de 2 TB (Hitachi/HGST Ultrastar 7200 rpm).
Avant de le mettre en service, j'ai simulé la perte d'un disque et j'ai un peu ramé aussi.

Je l'ai configuré comme suit:
/ (100000 MB) Raid1 sur les 3 disques ;
swap 3x 512 MB ;
/home 4050000 MB Raid5 ;
il reste 3944 MB inutilisés

Installation à partir d'un template OVH
Étape 4 sur 4

Vous êtes sur le point de lancer l'installation d'un template OVH
Type Système de fichier Point de montage Nom du volume LVM Raid
Taille de la partition
Espace consommé
1 primary Ext4 / - 1 100.0 Go 300.0 Go
2 primary Swap swap - - 3 x 512.0 Mo 1.5 Go
3 primary Ext4 /home - 5 4.1 To 6.1 To

Système installé:

> root@k4:~# lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> sda 8:0 0 1.8T 0 disk
> ├─sda1 8:1 0 1M 0 part
> ├─sda2 8:2 0 97.7G 0 part
> │ └─md2 9:2 0 97.6G 0 raid1 /
> ├─sda3 8:3 0 512M 0 part [SWAP]
> ├─sda4 8:4 0 1.7T 0 part
> │ └─md4 9:4 0 3.4T 0 raid5 /home
> └─sda5 8:5 0 2M 0 part
> sdb 8:16 0 1.8T 0 disk
> ├─sdb1 8:17 0 1M 0 part
> ├─sdb2 8:18 0 97.7G 0 part
> │ └─md2 9:2 0 97.6G 0 raid1 /
> ├─sdb3 8:19 0 512M 0 part [SWAP]
> └─sdb4 8:20 0 1.7T 0 part
> └─md4 9:4 0 3.4T 0 raid5 /home
> sdc 8:32 0 1.8T 0 disk
> ├─sdc1 8:33 0 1M 0 part
> ├─sdc2 8:34 0 97.7G 0 part
> │ └─md2 9:2 0 97.6G 0 raid1 /
> ├─sdc3 8:35 0 512M 0 part [SWAP]
> └─sdc4 8:36 0 1.7T 0 part
> └─md4 9:4 0 3.4T 0 raid5 /home
> root@k4:~# fdisk -l
> Disk /dev/sdc: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
> Disk model: HGST HUS724020AL
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: 88F04E86-7894-4471-BC64-A01B48AF10FB

> Device Start End Sectors Size Type
> /dev/sdc1 2048 4095 2048 1M BIOS boot
> /dev/sdc2 4096 204804095 204800000 97.7G Linux RAID
> /dev/sdc3 204804096 205852671 1048576 512M Linux filesystem
> /dev/sdc4 205852672 3907024895 3701172224 1.7T Linux RAID


> Disk /dev/sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
> Disk model: HGST HUS726020AL
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: F79E0A8F-E075-4CD3-9A4A-4449C85ABC07

> Device Start End Sectors Size Type
> /dev/sdb1 2048 4095 2048 1M BIOS boot
> /dev/sdb2 4096 204804095 204800000 97.7G Linux RAID
> /dev/sdb3 204804096 205852671 1048576 512M Linux filesystem
> /dev/sdb4 205852672 3907024895 3701172224 1.7T Linux RAID


> Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
> Disk model: HGST HUS724020AL
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: 89B42B9C-4A7F-4A1D-83B6-3CB70AE10312

> Device Start End Sectors Size Type
> /dev/sda1 2048 4095 2048 1M BIOS boot
> /dev/sda2 4096 204804095 204800000 97.7G Linux RAID
> /dev/sda3 204804096 205852671 1048576 512M Linux filesystem
> /dev/sda4 205852672 3907024895 3701172224 1.7T Linux RAID
> /dev/sda5 3907025072 3907029134 4063 2M Linux filesystem


> Disk /dev/md2: 97.59 GiB, 104789442560 bytes, 204666880 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes


> Disk /dev/md4: 3.45 TiB, 3789729824768 bytes, 7401816064 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
> root@k4:~# cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [ra id10]
> md4 : active raid5 sda4[0] sdb4[1] sdc4[2]
> 3700908032 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
> bitmap: 2/14 pages [8KB], 65536KB chunk

> md2 : active raid1 sdb2[1] sda2[0] sdc2[2]
> 102333440 blocks super 1.2 [3/3] [UUU]

> unused devices:

> root@k4:~# df
> Filesystem 1K-blocks Used Available Use% Mounted on
> udev 16375912 0 16375912 0% /dev
> tmpfs 3279072 928 3278144 1% /run
> /dev/md2 100141136 2203500 92804580 3% /
> tmpfs 16395344 0 16395344 0% /dev/shm
> tmpfs 5120 0 5120 0% /run/lock
> /dev/md4 3641677144 80 3456615280 1% /home
> tmpfs 3279068 0 3279068 0% /run/user/0


> root@k4:~# cat /etc/fstab
> UUID=1e2a98b7-3a1b-4a11-958a-4f0fc550208b / ext4 defaults 0 1
> UUID=04043bee-a6e9-4cbb-b790-a46ccb6b81b3 /home ext4 defaults 0 0
> UUID=5b9a2cec-80a4-46d5-9ebe-7fe7e25f1bf9 swap swap defaults 0 0
> UUID=d005932c-907e-4013-a798-b9e5bb036b71 swap swap defaults 0 0
> UUID=b439d192-506c-465f-a937-3d82720e5d1d swap swap defaults 0 0

Pour l'exercice je vais crasher /dev/sdb
(reboot en rescue)

root@rescue:~# fdisk /dev/sdb
...
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
...
Disklabel type: gpt
Disk identifier: F79E0A8F-E075-4CD3-9A4A-4449C85ABC07

root@rescue:~# dd if=/dev/zero of=/dev/sdb bs=10M
^C
11242+0 records in
11242+0 records out
117880913920 bytes (118 GB) copied, 546.949 s, 216 MB/s

Reboot. Le système reboote correctement.

Impératif. Vérifier que les devices sont restés les mêmes (par les UUID, par les n° de série)
Chez moi c'est toujours bien /dev/sdb qui n'a pas de partition table.

Je duplique la PT de sdc vers sdb et altérant les UUID au passage (cherchez "-CAFE-")


> root@k4:~# sfdisk -d /dev/sdc
> label: gpt
> label-id: 88F04E86-7894-4471-BC64-A01B48AF10FB
> device: /dev/sdc
> unit: sectors
> first-lba: 34
> last-lba: 3907029134
> sector-size: 512

> /dev/sdc1 : start= 2048, size= 2048, type=21686148-6449-6E6F-744E-656564454649, uuid=066E68BE-35AC-477A-B02E-C7795D1B7F6A, name="bios_grub"
> /dev/sdc2 : start= 4096, size= 204800000, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=6362DB5A-2D6D-41CA-A00F-5182804D2FA9, name="primary"
> /dev/sdc3 : start= 204804096, size= 1048576, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=F6E32528-F4CF-4BCE-99CB-89F192C66B70, name="primary"
> /dev/sdc4 : start= 205852672, size= 3701172224, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=809D9D0B-3273-4FF4-8E8D-1F4FDF856DCD, name="primary"


> Avant d'injecter cette partition table, je change tous les UUID pour ne pas créer des doublons (! à 5 endroits, et non 4)


> label: gpt
> label-id: 88F04E86-7894-CAFE-BC64-A01B48AF10FB
> device: /dev/sdc
> unit: sectors
> first-lba: 34
> last-lba: 3907029134
> sector-size: 512

> /dev/sdc1 : start= 2048, size= 2048, type=21686148-6449-6E6F-744E-656564454649, uuid=066E68BE-35AC-CAFE-B02E-C7795D1B7F6A, name="bios_grub"
> /dev/sdc2 : start= 4096, size= 204800000, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=6362DB5A-2D6D-CAFE-A00F-5182804D2FA9, name="primary"
> /dev/sdc3 : start= 204804096, size= 1048576, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=F6E32528-F4CF-CAFE-99CB-89F192C66B70, name="primary"
> /dev/sdc4 : start= 205852672, size= 3701172224, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=809D9D0B-3273-CAFE-8E8D-1F4FDF856DCD, name="primary"


> et je l'injecte avec "cat | sfdisk /dev/sdb"

> root@k4:~# cat | sfdisk /dev/sdb
> Checking that no-one is using this disk right now ... OK

> Disk /dev/sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
> Disk model: HGST HUS726020AL
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes

> label: gpt
> label-id: 88F04E86-7894-CAFE-BC64-A01B48AF10FB
> device: /dev/sdc
> unit: sectors
> first-lba: 34
> >>> Script header accepted.
> >>> Script header accepted.
> >>> Script header accepted.
> >>> Script header accepted.
> >>> Script header accepted.
> last-lba: 3907029134
> sector-size: 512

> /dev/sdc1 : start= 2048, size= 2048, type=21686148-6449-6E6F-744E-656564454649, uuid=066E68BE-35AC-CAFE-B02E-C7795D1B7F6A, name="bios_grub"
> >>> Script header accepted.
> >>> Script header accepted.
> /dev/sdc2 : start= 4096, size= 204800000, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=6362DB5A-2D6D-CAFE-A00F-5182804D2FA9, name="primary"
> /dev/sdc3 : start= 204804096, size= 1048576, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=F6E32528-F4CF-CAFE-99CB-89F192C66B70, name="primary"
> /dev/sdc4 : start= 205852672, size= 3701172224, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=809D9D0B-3273-CAFE-8E8D-1F4FDF856DCD, name="primary"
> >>> Created a new GPT disklabel (GUID: 88F04E86-7894-CAFE-BC64-A01B48AF10FB).
> /dev/sdb1: Created a new partition 1 of type 'BIOS boot' and of size 1 MiB.
> /dev/sdb2: Created a new partition 2 of type 'Linux RAID' and of size 97.7 GiB.
> /dev/sdb3: Created a new partition 3 of type 'Linux filesystem' and of size 512 MiB.
> /dev/sdb4: Created a new partition 4 of type 'Linux RAID' and of size 1.7 TiB.
> /dev/sdb5: Done.

> New situation:
> Disklabel type: gpt
> Disk identifier: 88F04E86-7894-CAFE-BC64-A01B48AF10FB

> Device Start End Sectors Size Type
> /dev/sdb1 2048 4095 2048 1M BIOS boot
> /dev/sdb2 4096 204804095 204800000 97.7G Linux RAID
> /dev/sdb3 204804096 205852671 1048576 512M Linux filesystem
> /dev/sdb4 205852672 3907024895 3701172224 1.7T Linux RAID

> The partition table has been altered.
> Calling ioctl() to re-read partition table.
> Syncing disks.
> root@k4:~#

puis un reboot, et constater que ça ne rebuild pas tout seul, et cette fois-ci les devices ont changé de nom.

> root@k4:~# fdisk -l
> Disk /dev/sdc: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
> Disk model: HGST HUS724020AL
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: 88F04E86-7894-4471-BC64-A01B48AF10FB

> Device Start End Sectors Size Type
> /dev/sdc1 2048 4095 2048 1M BIOS boot
> /dev/sdc2 4096 204804095 204800000 97.7G Linux RAID
> /dev/sdc3 204804096 205852671 1048576 512M Linux filesystem
> /dev/sdc4 205852672 3907024895 3701172224 1.7T Linux RAID


> Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
> Disk model: HGST HUS726020AL
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: 88F04E86-7894-CAFE-BC64-A01B48AF10FB

> Device Start End Sectors Size Type
> /dev/sda1 2048 4095 2048 1M BIOS boot
> /dev/sda2 4096 204804095 204800000 97.7G Linux RAID
> /dev/sda3 204804096 205852671 1048576 512M Linux filesystem
> /dev/sda4 205852672 3907024895 3701172224 1.7T Linux RAID


> Disk /dev/sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
> Disk model: HGST HUS724020AL
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: 89B42B9C-4A7F-4A1D-83B6-3CB70AE10312

> Device Start End Sectors Size Type
> /dev/sdb1 2048 4095 2048 1M BIOS boot
> /dev/sdb2 4096 204804095 204800000 97.7G Linux RAID
> /dev/sdb3 204804096 205852671 1048576 512M Linux filesystem
> /dev/sdb4 205852672 3907024895 3701172224 1.7T Linux RAID
> /dev/sdb5 3907025072 3907029134 4063 2M Linux filesystem


> Disk /dev/md2: 97.59 GiB, 104789442560 bytes, 204666880 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes


> Disk /dev/md4: 3.45 TiB, 3789729824768 bytes, 7401816064 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
> root@k4:~#


Avez-vous vu que mon disque "CAFE" 88F04E86-7894-CAFE-BC64-A01B48AF10FB est maintenant /dev/sda ?

> root@k4:~# mdadm /dev/md2 --add /dev/sda2
> root@k4:~# mdadm --wait /dev/md2 # disque mécanique oblige
> root@k4:~# mdadm /dev/md4 --add /dev/sda4

Enfin, le swap ne s'active plus sur le disque remplacé.

root@k4:~# mkswap /dev/sdb3
Setting up swapspace version 1, size = 512 MiB (536866816 bytes)
no label, UUID=777a230c-e601-4dda-ad45-9b001367ef6c


Modifier /etc/fstab pour mettre UUID=777a230c-e601-4dda-ad45-9b001367ef6c

et

root@k4:~# swapon -a
root@k4:~# swapon -s

== fin du compte-rendu.

Pour être certain que la procédure fonctionne à 100% il faudrait casser chacun des 3 disques à tour de rôle. Je ne l'ai pas fait.

J'ignore si j'ai fait des actions inutiles.

Bon pour le moment j'ai crée ma partition de type EFI, je l'ai formaté en FAT32, j'ai copié le contenu du disque 0 sur le disque 1.
Dans le grub.cfg dans efi c'est bien l'uid du raid qui est appelé.
Dans /etc/fstab le mount pour /boot/efi est appelé via un type de partition
LABEL=EFI_SYSPART /boot/efi vfat defaults 0 1

Donc normalement au boot le système va choisir l'une des 2 partitions, qui contient l'uid du raid pour le root filesystem... En "théorie" tt devrait être ok comme ça...

Il faudra que je programme un reboot avec le client... histoire de m'assurer que ça reboot bien (ça a rebooté avec 1 seul disque, pas vraiment de risque que ça ne reboot pas avec les 2)...
C'est un serveur en prod, je ne peux pas trop jouer à faire sauter les partitions pour "stress test" la config...

Bon pour le moment j'ai crée ma partition de type EFI, je l'ai formaté en FAT32, j'ai copié le contenu du disque 0 sur le disque 1.

Bonjour @Sich, si vous êtes sous Debian, c'est en effet la meilleure chose à faire. Cela correspond à ce que nous faisons lors de l'installation de l'OS.
Je vous invite à bien remettre le label `EFI_SYSPART` sur la nouvelle ESP (EFI system partition) avec `dosfslabel /dev/ EFI_SYSPART`. En effet, comme vous l'avez remarqué, c'est par ce label qu'est montée la partition. Vous pouvez lister toutes les partitions correspondantes avec `blkid -t LABEL=EFI_SYSPART` (ou `lsblk -f` avec du `| grep`).

Sous Ubuntu, il existe un paramètre qui fait que, lors de la phase de configuration du package `grub-efi-amd64`, GRUB est installé sur plusieurs partitions EFI. Si vous êtes sous Ubuntu, vous pouvez lancer `dpkg-reconfigure grub-efi-amd64`.
Vous pourrez alors choisir la nouvelle ESP en plus de l'ancienne :
```text
┌─────────────────────────────────────────────────────────────────────┤ Configuring grub-efi-amd64 ├──────────────────────────────────────────────────────────────────────┐
│ The grub-efi package is being upgraded. This menu allows you to select which EFI system partions you'd like grub-install to be automatically run for, if any. │
│ │
│ Running grub-install automatically is recommended in most situations, to prevent the installed GRUB core image from getting out of sync with GRUB modules or grub.cfg. │
│ │
│ GRUB EFI system partitions: │
│ │
│ [*] /dev/sdb1 (535 MB; /boot/efi) on 2000398 MB HGST_HUS724020AL │
│ [*] /dev/sda1 (535 MB; ) on 2000398 MB HGST_HUS724020AL │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
```
Vous verrez alors que GRUB va être installé sur les deux partitions, le script de postinst va monter chaque ESP tour à tour dans `/var/lib/grub/esp`, puis y installer GRUB :
```
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
Installation finished. No error reported.
Installing grub to /var/lib/grub/esp.
Installing for x86_64-efi platform.
Installation finished. No error reported.
```
Malheureusement, c'est une modification spécifique à Ubuntu, le script `/usr/lib/grub/grub-multi-install` n'est pas standard et n'existera pas sous Debian ou d'autres OS. Vous devrez alors vous contenter de la copie manuelle.

À l'avenir, nous avons pour projet d'essayer de placer la partition ESP sur un RAID 1, ce qui permettrait à toutes les distributions Linux de s'abstraire de la complexité liée à la duplication, mais nous devrons tester cette modification sur tout notre matériel afin de nous assurer que toutes les cartes mères soient capables de la lire.

Merci pour le passage : dosfslabel /dev/ EFI_SYSPART !
Je n'avais pas fait et en effet le label n'était pas présent... Je m'était contenté du "type" de partition à la création de la dite partition.

Je ne me suis pas vraiment penché sur la question EFI avant (je suis un vieux monsieur), mais si cette partition est mise à jour (qd d'aileurs ?), la copie ne l'est pas automatiquement.... Un conseil pour tenir les 2 partitions synchrone ?

Et en effet pas de raid1 sur cette partition, ça simplifierait pas mal les choses... Mais peut être est une limitation que la partition doit pouvoir être lue au tt début de la séquence de boot non ?

En tt cas j'ai bien repassé une couche de grub-install / update-grub sans la moindre erreur... Mon label est bien présent sur les 2 partitions, j'ai copié les datas de la partition EFI, le raid est synchronisé... ça devrait être pas trop mal....
Reste à trouver un moment avec le client pour tester un reboot et surveiller ça va ipmi...

mais si cette partition est mise à jour (qd d'aileurs ?), la copie ne l'est pas automatiquement.... Un conseil pour tenir les 2 partitions synchrone ?

Elle ne sera mise à jour que si GRUB est mis à jour ou si l'UUID de la partition contenant `/boot/grub/grub.cfg` change (ce qui nécessite la mise à jour de `/boot/efi/EFI/debian/grub.cfg`).

Vous pourriez utiliser un script dans ce genre-là pour les garder synchrones, la difficulté étant de savoir quand l'exécuter. L'idéal serait sûrement de jouer avec les triggers dpkg pour ne le faire que lors de la mise à jour du package `grub-efi-amd64`.
```bash
#!/bin/bash
set -euo pipefail

MAIN_PARTITION="$(findmnt -n -o SOURCE /boot/efi)"
MOUNTPOINT="/var/lib/grub/esp"

mkdir -p "${MOUNTPOINT}"

while read -r partition; do
if [[ "${partition}" == "${MAIN_PARTITION}" ]]; then
continue
fi
echo "Working on ${partition}"
mount "${partition}" "${MOUNTPOINT}"
rsync -ax "/boot/efi/" "${MOUNTPOINT}/"
umount "${MOUNTPOINT}"
done < <(blkid -o device -t LABEL=EFI_SYSPART)
```

Mon label est bien présent sur les 2 partitions, j'ai copié les datas de la partition EFI, le raid est synchronisé... ça devrait être pas trop mal....

D'après ce que vous dites, vous ne devriez avoir aucun problème.