Grappe redondante non formelle pour partition EFI sur plusieurs disques

[Almtesh]

Bonjour,

J’ai une machine avec trois disques durs de tailles identiques.
J’ai donc installé le système (Debian 10) dans une grappe redondante, de type RAID5.
La machine démarre en EFI, j’ai donc aussi une partition en FAT pour le démarrage qui se trouve sur les trois disques.
Le problème, c’est que les trois partitions ne sont synchronisées que manuellement.

Je souhaiterai les mettre en RAID1, mais je ne connais pas du tout l’EFI et ça pourrait très bien empêcher le système de démarrer.
Je voudrais savoir s’il est possible de mettre un composant logiciel entre les trois copies de la partition pour présenter une seule partition, un peu à la façon du RAID1, mais sans faire une partition de RAID logiciel.

Merci à vous.

[jipete]

@Almtesh

Le problème, c’est que les trois partitions ne sont synchronisées que manuellement.

Qu’est-ce que tu entends par là ?

En te relisant, je résumerais en disant que tu veux casser ton raid5 pour le reconstruire en raid1, c’est ça ?
Sans un grand spécialiste du raid dans le coin, ça va être tendu, et t’as intérêt à avoir de bonnes sauvegardes.
Moi, si je devais faire, je commencerais par jouer avec une machine virtuelle. Oui, ça va prendre du temps mais au moins tu pourras prendre des notes et, si ça casse, c’est pas grave, tu repars de la sauvegarde de la mv, ça ira vite et sans sueurs froides sur le front,

[Clochette]

@Almtesh

Je souhaiterai les mettre en RAID1, mais je ne connais pas du tout l’EFI et ça pourrait très bien empêcher le système de démarrer.

Hautement probable.

Une fois que tu a dupliquer sur ton deuxième disque qu’est-ce qui t’empêche d’ajouter ta seconde partition dans la CHAIN ce ne sera pas automatique et il faudra dupliquer à la main à chaque update.

genre un truc comme ça après avoir fais un dd de la partition sur le deuxième disque :

efibootmgr -c -d /dev/sdX -p 1 -L "Altmesh_system2" -l '\EFI\Ta_Partition\shimx64.efi'

Qu’est-ce que tu as comme retour avec un :

 efibootmgr -v

Maintenant attends peut-être le passage de Pascal il te filera sans doute une solution à ce noeud

[PascalHambourg]

Je ne connais pas de solution idéale à part passer en amorçage BIOS qui permet de gérer la redondance de l’amorçage de façon beaucoup plus simple et fiable. Voici des éléments d’information et de réflexion en vrac.

Mettre les partitions EFI en RAID1 logiciel et monter l’ensemble RAID résultant sur /boot/efi : c’est possible mais le format par défaut (1.2) place le superbloc RAID au début des partitions membres et décale le superbloc FAT, ce qui empêche le firmware EFI de le reconnaître. Il faut donc forcer le format 1.0 qui place le superbloc RAID à la fin des partitions membres et ne décale pas le superbloc FAT, comme l’ancien format obsolète 0.90.

Par contre l’enregistrement automatique de GRUB dans les variables de boot EFI par grub-install ne fonctionne pas dans une telle configuration, car l’ensemble RAID1 ne peut être traduit en informations de partitions compatibles avec les variables de boot EFI. Il y a trois possibilités :

• Créer manuellement une entrée de boot EFI pour chaque partition RAID1 avec efibootmgr.

• Attribuer le même UUID de partition (PARTUUID) aux trois partitions RAID1 et créer manuellement une seule variable de boot EFI pour les trois.

• Installer GRUB dans le « chemin de support amovible » et ne pas créer de variable de boot EFI. C’est automatisable car le paquet grub-efi-amd64 supporte ces options.

Si on ne met pas les partitions EFI en RAID, une seule peut être montée sur /boot/efi et il faut synchroniser son contenu dans les deux autres d’une façon ou d’une autre. Idéalement il faut le faire après chaque mise à jour ou reconfiguration des paquets grub* ou shim*, qui provoque la réinstallation de GRUB. Mais je ne sais pas comment on peut automatiser ça.

Une possibilité consiste à installer manuellement GRUB dans les deux autres partitions EFI avec grub-install et les options qui vont bien. Mais on se heurte potentiellement à une difficulté pour créer les variables de boot EFI : par défaut, la variable est nommée « debian », et d’après mon expérience le firmware UEFI peut réagir de deux façons :

• soit il remplace la variable existante de même nom (cas le plus fréquent), ce qui va à l’encontre de la redondance recherchée
• soit il ajoute une nouvelle variable avec le même nom (cas plus rare)

L’option --bootloader-id de grub-install permet de donner un nom différent à la variable de boot EFI, mais détermine aussi le nom du répertoire dans /EFI/ de la partition EFI où GRUB sera installé. Or la variante de GRUB signée pour le secure boot (installée par défaut) a le chemin /EFI/debian codé en dur pour son fichier de configuration grub.cfg initial, donc ne fonctionne pas s’il est installé dans un répertoire différent. Contournements possibles :

• créer un répertoire /EFI/debian et y copier le fichier grub.cfg
• installer la variante non signée de GRUB qui n’a pas besoin de fichier grub.cfg dans la partition EFI

Une autre possibilité consiste à synchroniser le contenu des partitions EFI avec rsync par exemple.

Dans tous les cas, la difficulté revient encore et toujours à la gestion des variables de boot EFI pour assurer la redondance de l’amorçage. Une seule variable de boot EFI pourrait suffire si toutes les partitions EFI ont le même PARTUUID. Sinon il faut créer une variable de boot par partition. Ou bien on n’utilise pas de variables de boot (qui sont fragiles et mal gérées par de nombreux firmwares UEFI) et on utilise seulement le chemin de support amovible. C’est l’option que je choisirais.

[Zargos]

Pour faire du RAID 1, ca ne sera qu’avec deux disques ou deux partitions.
Il suffit d’avoir une partition pour le boot puis la partition système

@Almtesh

Le problème, c’est que les trois partitions ne sont synchronisées que manuellement.

ar contre ça je ne comprends pas non plus ce que tu veux dire. Un RAID 5 sur trois disques ne se synchronise pas. C’est un non sense, car les données s’écrivent sur les trois avec un système de parité. Tu n’as pas trois disques redondé mais un seul ensemble logique réparti sur trois disque qui permettent à ton système de fonctionner si 1 disque defaille (et 1 seul, avec trois disque si 2 disques tombent, c’est foutu, tout est mort).

tu fait un RAID 1 entre les deux premières
tu fait un RAID 1 entre les deux partitions systèmes

sur la première tu montes sur /boot - /boot/efi
sur le deuxième tu peux installer en LVm les autres partitions que tu veux.

le plus simple c’est de créer les RAID sur le premier disque en disant au RAID que le disque numéro 2 est absent.
Tu montes / installe ta machine tranquillement.

puis tu ajoutes/active le disque 2, à ce moment là le RAID va dupliquer les données et voilà.

j’ai déjà pratiqué cette manipulation pour transformer une machine classique en machine en RAID 1.

[PascalHambourg]

@Zargos

Pour faire du RAID 1, ca ne sera qu’avec deux disques ou deux partitions.

Le RAID 1 peut utiliser un nombre quelconque de membres, pas seulement deux.

@Zargos

je ne comprends pas non plus ce que tu veux dire. Un RAID 5 sur trois disques

Le RAID 5 mentionné ne concerne pas les partitions EFI mais seulement le reste du système.

(J’ai complété ma réponse précédente)

[Zargos]

Désolé, vu l’heure tardive et les bieres, je ne suis pas complètement d’accord avec tes modifs.
il faut que je retrouve les infos que j’avais utilisé.
mais javais bien deux RAID 1:

• la partition de boot
• le reste
• le grub

faut que je retrouve.

sinon coté faire du RAID avec plus de deux stockages (disk / partition), c’est rédhibitoire pour les performances et en plus, le RAID c’est Deux. au delà c’est sinon inutile, assurément une usine à gaz;
d’autant que le RAID c’est du mirroring, donc à moins d’aller dans les mathématiques des dimensions, le mirroring par définition c’est deux.

sinon tu n’est plus en raid 1 mais en raid 10

(raid 1+0, le raide 01 ou 0+1 est à évité la perte d’un noeud raid 0 compromet le reste) . et donc toujours pair. mais coté rentabilité c’est pas terrible, en gros il faut 4 fois la capacité nécessaire. Pour 1 disque utile, 3 ne sont pas utilisés.

le mieux c’est le RAID 6 (pour des données, car coté système le RAID 1 suffit largement. car un système est simple à refaire, ce qui n’est pas le cas des données.
Le RAID 5 permet 1 disque en panne, le RAID 6 permet 2disques en panne.
En fait le RAID 6 est pratique pour ceux qui ne s’embarrasse pas d’une supervision efficace, et qui dispose d’un disque de spare, ce qui leur permet de remplacer le disque defaillant avant qu’un autre ne le soit.

Bien évidement, le RAID n’est pas là pour se passer de sauvegardes

@PascalHambourg

Le RAID 5 mentionné ne concerne pas les partitions EFI mais seulement le reste du système.

le RAID 5 sert poru les données le RAID 1 pour le système. C’est mieux en terme de ratio performances/tolerance de pannes

[Almtesh]

@jipete

En te relisant, je résumerais en disant que tu veux casser ton raid5 pour le reconstruire en raid1, c’est ça ?

Pas du tout, j’ai juste trois partitions qui doivent être identiques, mais qui ne le sont pas automatiquement. Je voulais automatiser leur réplication à l’instar de ce fait le RAID1, mais sans faire un RAID1 car je ne maîtrise pas le boot EFI et que je ne peux pas tout casser.

@Clochette

Qu’est-ce que tu as comme retour avec un :

 efibootmgr -v

┌ (almtesh@Worm + 0) (07/05/22 - 7:46:03) (0.18 - 0%) (~)
└% efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0003,0004,0001,0002
Boot0000* debian        HD(1,GPT,c11d79b1-4558-47ba-9bef-265321fb250c,0x800,0x20000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0001  UEFI: PXE IP4 Realtek PCIe GBE Family Controller      PciRoot(0x0)/Pci(0x13,0x2)/Pci(0x0,0x0)/MAC(7085c2d121dd,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0002  UEFI: PXE IP6 Realtek PCIe GBE Family Controller      PciRoot(0x0)/Pci(0x13,0x2)/Pci(0x0,0x0)/MAC(7085c2d121dd,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0003* debian        HD(1,GPT,c11d79b1-4558-47ba-9bef-265321fb250c,0x800,0x20000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO
Boot0004* debian        HD(1,GPT,51885f61-c747-5045-8b7c-7f7c68889801,0x800,0x20000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO
┌ (almtesh@Worm + 0) (07/05/22 - 7:46:31) (0.11 - 0%) (~)
└%

@Clochette

Une fois que tu a dupliquer sur ton deuxième disque qu’est-ce qui t’empêche d’ajouter ta seconde partition dans la CHAIN ce ne sera pas automatique et il faudra dupliquer à la main à chaque update.

Ouais, c’est pas faux !

@PascalHambourg

Je ne connais pas de solution idéale à part passer en amorçage BIOS qui permet de gérer la redondance de l’amorçage de façon beaucoup plus simple et fiable.

Effectivement, c’est une très bonne idée, malheureusement, la carte mère ne gère pas le démarrage BIOS. D’ailleurs, je ne le savais pas quand je l’ai achetée, du coup, j’ai dû réinstaller le système de la machine qui était avant à ce poste et qui avait un démarrage en BIOS.

@PascalHambourg

Si on ne met pas les partitions EFI en RAID, une seule peut être montée sur /boot/efi et il faut synchroniser son contenu dans les deux autres d’une façon ou d’une autre.

Actuellement, je lance de temps en temps la commande suivante :

sudo umount /boot/efi ; for i in b c;do sudo dd if=/dev/sda1 of=/dev/sd$i1 bs=16M; done; sudo mount /boot/efi

Éventuellement, ce que je peux faire, c’est de programmer ça dans cron cette partition est montée avec la ligne suivante dans /etc/fstab :

# <file system>         <mount point>                           <type>  <options>                               <dump>  <pass>
/dev/sda1               /boot/efi                               vfat    umask=0077                              0       1

Mais bon, avant de faire ça, j’aimerais quand même savoir s’il n’existe pas un moyen de faire ça à la façon du RAID1.

@PascalHambourg

Une seule variable de boot EFI pourrait suffire si toutes les partitions EFI ont le même PARTUUID.

Comme les partitions sont répliquées avec dd, j’ai innocemment pensé qu’elle avait le même PARTUUID, mais pas du tout :

/dev/sda1: UUID="7CFA-377F" TYPE="vfat" PARTUUID="c11d79b1-4558-47ba-9bef-265321fb250c"
/dev/sdc1: UUID="7CFA-377F" TYPE="vfat" PARTUUID="51885f61-c747-5045-8b7c-7f7c68889801"
/dev/sdb1: UUID="7CFD-0229" TYPE="vfat" PARTUUID="c8f9ceb4-32d4-485b-839b-398271f04982"

[PascalHambourg]

D’après la sortie de efibootmgr ton firmware UEFI fait partie de ceux qui supportent plusleurs variables de boot EFI avec le même nom. Cela peut simplifier la configuration si on tient à utiliser les variables de boot EFI. Mais je maintiens que l’utilisation du chemin de support amovible sans variable de boot EFI est plus simple et plus fiable.

@Almtesh

Actuellement, je lance de temps en temps la commande suivante

Cette commande est défectueuse car sd$i1 est substitué en « sd », $i1 étant interprété comme une variable (non existante donc vide) et non la variable $i suivie de 1. La commande va donc créer un fichier /dev/sd contenant l’image de la partition /dev/sda1. Il faut mettre quelque chose comme ${i}1, $i'1' ou "$i"1 pour isoler la variable. On peut voir dans la sortie de blkid que /dev/sdb1 n’a pas le même UUID que /dev/sda1.

J’allais aussi argumenter que l’utilisation de noms de périphériques /dev/sd* n’est pas fiable car ces noms ne sont pas persistants et peuvent changer d’un démarrage à l’autre selon l’ordre de détection des disques, c’est pourquoi on utilise plutôt des UUID dans /etc/fstab. Mais tu as aussi utilisé /dev/sda1 dans /etc/fstab, donc ta commande est sûre de copier la partition montée sur /boot/efi sur les deux autres. Par contre ce n’est fiable que s’il n’y pas d’autre disque que ces trois.

A ce propos dans ma première réponse j’ai oublié d’évoquer le montage de la partition EFI au démarrage avec un disque défaillant. Si le montage échoue parce que la partition spécifiée n’existe plus, le démarrage s’interrompt et passe en mode dépannage. Avec des partitions EFI en RAID1 , l’ensemble RAID /dev/mdX pourra être assemblé et monté du moment que n’importe lequel des trois disques est opérationnel. En revanche avec des partitions EFI indépendantes, c’est un peu plus délicat. Pour pouvoir monter n’importe laquelle des partitions EFI, on peut utiliser le nom de périphérique /dev/sda1 comme tu l’as fait car sda existe toujours, à condition qu’il soit opérationnel. Sinon si on utilise un UUID ou LABEL, il faut que toutes les partitions EFI aient le même.

@Almtesh

Comme les partitions sont répliquées avec dd , j’ai innocemment pensé qu’elle avait le même PARTUUID, mais pas du tout

Le PARTUUID est contenu dans la table de partition et modifiable avec les outils de partitionnement comme fdisk ou gdisk, pas dans la partition elle-même contrairement à l’UUID.

Pour en revenir à la synchronisation des partitions EFI indépendantes, il n’est pas nécessaire de le faire périodiquement mais seulement après l’exécution de grub-install. Cette exécution se produit après la mise à jour des paquets grub* et shim*. Il doit y avoir moyen d’automatiser ça avec dpkg.

[Almtesh]

@PascalHambourg

Cette commande est défectueuse car sd$i1 est substitué en « sd », $i1 étant interprété comme une variable (non existante donc vide) et non la variable $i suivie de 1 . La commande va donc créer un fichier /dev/sd contenant l’image de la partition /dev/sda1. Il faut mettre quelque chose comme ${i}1 , $i'1' ou "$i"1 pour isoler la variable. On peut voir dans la sortie de blkid que /dev/sdb1 n’a pas le même UUID que /dev/sda1.

Ah oui, effectivement, je viens de relancer la commande en suivant ton conseil, les UUID sont identiques, mais pas les PARTUUID.

@PascalHambourg

J’allais aussi argumenter que l’utilisation de noms de périphériques /dev/sd* n’est pas fiable car ces noms ne sont pas persistants et peuvent changer d’un démarrage à l’autre selon l’ordre de détection des disques, c’est pourquoi on utilise plutôt des UUID dans /etc/fstab. Mais tu as aussi utilisé /dev/sda1 dans /etc/fstab, donc ta commande est sûre de copier la partition montée sur /boot/efi sur les deux autres. Par contre ce n’est fiable que s’il n’y pas d’autre disque que ces trois.

Effectivement, j’ai prévu de mettre un quatrième disque qui serait un disque de spare, mais pour le RAID5, il aurait aussi sa petite copie de la partition EFI comme les autres.

@PascalHambourg

Le PARTUUID est contenu dans la table de partition et modifiable avec les outils de partitionnement comme fdisk ou gdisk, pas dans la partition elle-même contrairement à l’UUID.

C’est bien ce qu’il me semblait.

@PascalHambourg

Pour en revenir à la synchronisation des partitions EFI indépendantes, il n’est pas nécessaire de le faire périodiquement mais seulement après l’exécution de grub-install .

Oui, en effet, je pense que je vais l’ajouter à mon processus de mises à jour des logiciels.
J’ai un système de gestion en masse, avec toutes les machines et les conteneurs que j’ai, ça me fait gagner du temps.

@jipete

Et méfiance car les uuid m’ont parfois claqué entre les doigts, ça aussi ce n’était pas fiable…

J’utilise en général des LABEL, on peut générer de l’homonymie, mais si ça déconne, je ne pourrai m’en prendre qu’à moi-même.
C’est surtout parce que mes partitions ont un contenu qui a une fonction précise, du coup, il arrive assez souvent que je remplace un contenu par un autre sur une fonction en modifiant les LABEL.
C’est moins acrobatique que ça en a l’air.

[PascalHambourg]

@Almtesh

j’ai prévu de mettre un quatrième disque qui serait un disque de spare, mais pour le RAID5, il aurait aussi sa petite copie de la partition EFI comme les autres.

Ce n’est pas un souci s’il contient aussi une copie de la partition EFI.

Mais si tu veux mon avis, ma solution préférée est de mettre les partitions EFI dans un ensemble RAID1 au format 1.0 monté sur /boot/efi et de reconfigurer le paquet grub-efi-amd64 pour installer GRUB dans le chemin de support amovible et ne pas mettre à jour la NVRAM UEFI. Ce n’est pas très orhodoxe mais c’est simple et fiable puisqu’on ne s’embête plus avec la synchronisation des partitions EFI ni la gestion des variables de boot EFI qui est le point faible de l’amorçage UEFI.

[Almtesh]

@PascalHambourg

installer GRUB dans le chemin de support amovible

Pardon, je n’ai pas percuté la première fois, mais c’est la deuxième fois que tu parles de mettre GRUB sur un support amovible, mais je ne veux pas mettre GRUB sur un support amovible, moi, je le veux en trois exemplaires identiques sur les trois disques bien durs.
Soit j’ai bien compris et je passe à la copie, soit je n’ai pas compris et je pense que quelques explications seront plus que nécessaires.

[PascalHambourg]

@Almtesh

tu parles de mettre GRUB sur un support amovible

Non, je parle de mettre GRUB dans le « chemin de support amovible » /EFI/BOOT/BOOTX64.EFI de la partition EFI, qui ne nécessite pas de variable de boot EFI. Cf. les options --removable et --force-extra-removable de grub-install.

[Almtesh]

@PascalHambourg

Cf. les options --removable et --force-extra-removable de grub-install.

@Manuel de grub-install

       --force-extra-removable
              force installation to the removable media path also. This option is only available on EFI.
[…]
       --removable
              the installation device is removable. This option is only available on EFI.

Ah, je dois t’avouer que je m’attendais à quelque chose de clair dans le manuel.

Je pense que, pour le moment, je vais rester sur mon petit bout de code qui réplique manuellement la partition à la mise à jour de GRUB, si j’ai le temps et le courage de me former sur le sujet, je m’en occuperai.
Pour l’instant, la machine démarre en EFI, et le boot est répliqué, ça fera l’affaire pour le moment.
Merci aux personnes qui ont apporté une réponse.

[Zargos]

Juste une question, quel est l’objectif d’avoir la partition en triple?
En raid 1 'avais fait ça, qui marche très bien, la machine tourne en RAID 1 avec un NVME et un SSD, avec EFI:

Création RAID 1 sur Debian 11 déjà installée

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 …

[PascalHambourg]

@Almtesh

Ah, je dois t’avouer que je m’attendais à quelque chose de clair dans le manuel.

Les pages de manuel de GRUB sont succintes et ne décrivent que la syntaxe des commandes et options. Pour la signification de « removable media path », il faut se référer aux spécifications de l’UEFI.

@Almtesh

Je pense que, pour le moment, je vais rester sur mon petit bout de code qui réplique manuellement la partition à la mise à jour de GRUB,

Ok. Deux remarques concernant les trois variables de boot « debian » :

• Deux pointent vers grubx64.efi donc ne fonctionnent pas si le secure boot est activé. Pour le secure boot il faut pointer vers shimx64.efi.
• Deux pointent vers la même partition EFI, donc une des trois partition EFI n’est référencée par aucune variable de boot.

[Almtesh]

@PascalHambourg

Ok. Deux remarques concernant les trois variables de boot « debian » :

• Deux pointent vers grubx64.efi donc ne fonctionnent pas si le secure boot est activé. Pour le secure boot il faut pointer vers shimx64.efi.
• Deux pointent vers la même partition EFI, donc une des trois partition EFI n’est référencée par aucune variable de boot.

Fort heureusement, le secure boot n’est pas activé sur cette carte mère. Quand même, j’ai dû me cogner l’EFI, j’allais pas avoir le secure boot en sus.
Par contre, ta remarque est pertinante concernant les trois entrées de démarrage qu’on voit ici :

@Almtesh

┌ (almtesh@Worm + 0) (07/05/22 - 7:46:03) (0.18 - 0%) (~)
└% efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0003,0004,0001,0002
Boot0000* debian        HD(1,GPT,c11d79b1-4558-47ba-9bef-265321fb250c,0x800,0x20000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0001  UEFI: PXE IP4 Realtek PCIe GBE Family Controller      PciRoot(0x0)/Pci(0x13,0x2)/Pci(0x0,0x0)/MAC(7085c2d121dd,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0002  UEFI: PXE IP6 Realtek PCIe GBE Family Controller      PciRoot(0x0)/Pci(0x13,0x2)/Pci(0x0,0x0)/MAC(7085c2d121dd,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0003* debian        HD(1,GPT,c11d79b1-4558-47ba-9bef-265321fb250c,0x800,0x20000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO
Boot0004* debian        HD(1,GPT,51885f61-c747-5045-8b7c-7f7c68889801,0x800,0x20000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO
┌ (almtesh@Worm + 0) (07/05/22 - 7:46:31) (0.11 - 0%) (~)
└%

la ligne « Boot0004 » est toujours différente de « Boot0000 » et « Boot0003 », est-ce qu’on peut démarrer sur shimx64.efi qui le secure boot n’est pas activé ?

[PascalHambourg]

@Almtesh

Par contre, ta remarque est pertinante concernant les trois entrées de démarrage

Dans la configuration actuelle elle ne l’est pas vraiment puisqu’il faut au moins deux disques pour démarrer le RAID5, donc il y aura forcément un autre disque dont la partition EFI est référencée dans les variables de boot EFI.

@Almtesh

la ligne « Boot0004 » est toujours différente de « Boot0000 » et « Boot0003 »,

Et c’est bien, puisqu’elle référence une partition EFI différente. Ce qui ne va pas, c’est que Boot0003 référence la même partition EFI que Boot0000 au lieu de la troisième partition EFI n’est pas référencée.

@Almtesh

est-ce qu’on peut démarrer sur shimx64.efi qui le secure boot n’est pas activé ?

Bien sûr. Comment crois-tu que le système a démarré ?

@Almtesh

BootCurrent: 0000
Boot0000* debian        ...(\EFI\DEBIAN\SHIMX64.EFI)

[Zargos]

@Grappe redondante non formelle pour partition EFI sur plusieurs disques

J’ai donc installé le système (Debian 10) dans une grappe redondante, de type RAID5. La machine démarre en EFI, j’ai donc aussi une partition en FAT pour le démarrage qui se trouve sur les trois disques.

Bonjour,

Alors non RAID 5 ce n’est pas ca. Pas besoin d’avoir /boot/efi sur chaque disque car en RAID5 c’est comme si tu n’avais qu’un seul disque.

RAID 5
La configuration RAID 5, par un système de parité, répartit une petite partie des données sur chaque disque.
Dans cette configuration, ce n’est pas la performance qu’on recherche mais plutôt la sécurité tout en économisant le volume de stockage.
Soit une donnée A, une donnée B et une donnée C :

• Volumétrie utile = Nombre de disques - 1 X capacité d’un disque
Pour 3 disques de 200 Go, on aurait ainsi 3 -1 X 200 = 400 Go de volumétrie utile.

• Sécurité des données : CORRECTE
Dans cette configuration, on ne peut se permettre de perdre qu’un seul disque.

• Nombre de disques nécessaires : Au moins 3

Donc non il n’y a toujours qu’une seule version d’un fichier accessible. quand un disque est perdu il faut le remplacer et avec les parité celui-ci est reconstruit.