Grappe redondante non formelle pour partition EFI sur plusieurs disques

Support Debian
#4

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.

#5

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

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.

#6

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

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)

#7

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
image
(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

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

#8

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.

┌ (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%) (~)
└%

Ouais, c’est pas faux !

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.

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.

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"
#9

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.

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.

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.

Modules disques du noyau passés en dur
#10

3 messages ont été scindés en un nouveau sujet : Module noyau en dur

#11

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

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.

C’est bien ce qu’il me semblait.

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.

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.

#14

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.

#15

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.

#16

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.

#17

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.

#18

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:

#19

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.

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.
#20

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 :

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é ?

#21

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.

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.

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

#22

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

Schéma fonctionnement affichage dynamique

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.

Debian RAID1 Soft: Question
#23

Seulement en RAID matériel. En RAID logiciel, les disques sont vus individuellement par le firmware UEFI qui ne connaît rien au RAID5 de Linux donc il faut une partition EFI sur chacun pour la redondance de l’amorçage.

#24

dans un système normal, tu as un disque système (souvent en RAID 1) et ensuite une grappe RAID5 pour les datas.
C’est tout aussi valable en logiciel.
On utilise pas habituellement du RAID5 pour un système, mais pour des données.

le RAID5 vu du système n’est qu’un seule et même disque (on devrait même quasiment parler de LUN);
les données sont réparti sur l’ensemble.

Toi tu parles de RAID 1 (minimum deux partition/disques ou plus, les performances diminuant avec le nombre)

le RAID 5 est resilient, le raid 1 est redondant

#25

La partition EFI n’est pas pour le système mais pour le firmware UEFI qui ne voit pas le RAID logiciel.

Pour la partition EFI seulement. Celle-ci peut être en RAID pour le système (afin d’être répliquée) mais doit être vue comme une partition normale par le firmware UEFI. Seul le RAID1 avec metadata=1.0 remplit ces deux conditions.
Pour le reste, chacun fait comme il veut chez soi.

Source ? Au contraire les performances en lecture aléatoire augmentent et les performances en écriture restent constantes.

Quelle différence ?