Installation : crash grub-install en RAID1

Support Debian
, ,
Tags: #<Tag:0x00007f63f3af5178> #<Tag:0x00007f63f3af50b0> #<Tag:0x00007f63f3af4fe8>
#1

Bonjour à tous,
J’essaye de monter un serveur maison sous Debian 9.2.1 en RAID1.
Le but est de l’utiliser pour du stockage de données, accessible en SFTP, donc avec serveur SSH seulement (pas de serveur web).

Mon matériel :

  • CM Asrock H110M, chipset 1151 (sans ajout de carte graphique)
  • CPU Intel Pentium G4500
  • 2 HDD 3,5’’ WD red 2 To
  • RAM Corsair 4 GB

J’ai fait de la récup des 2 DD sur lesquels étaient installés Ubuntu Server 14.04 sur une machine BIOS également en RAID1.

Mon RAID logiciel est partitionné comme suit :

  • bootable EFI (540 MB) en ESP (?? Je ne connais pas)
  • / (25 GB) en ext4
  • /home (2 To) en ext4
  • /var (10 GB) en ext4
  • /tmp (2 GB) en ext4
  • swap (4 GB) en ext4

Tout se passe bien jusqu’à 50% de l’installation de Grub. J’ai un message d’erreur m’indiquant : “impossible d’installer GRUB dans dummy. L’exécution de grub-install dummy a échoué. Cette erreur est fatale”.

J’ai essayé de relancer l’install de Grub, et il m’affiche ceci : "Il semble que cette machine soit configurée pour démarrer avec EFI mais il est possible que cette configuration ne fonctionne pas pour démarrer depuis le disque dur. Certains micro-codes qui gèrent EFI ne respectent pas le standard EFI (en d’autres termes, ils sont bogués) et ne gèrent pas correctement la configuration des options de démarrage pour les disques durs système. Une façon de contourner ce problème consiste à installer une copie supplémentation de la version EFI du chargeur d’amorçage GRUB à un emplacement de secours, le “chemin des supports amovibles (“removable media path”). Cela permet à tous les systèmes EFI, même bogués, de pouvoir lancer GRUB. Faut-il forcer l’installation sur le chemin des supports amovibles EFI ?”.

Je redémarre le serveur en exécutant l’EFI : il est à jour.
J’essaye de forcer l’installation EFI via Debian : de nouveau"échec de l’installation grub-install".

Je n’ai pas osé essayé de démarrer le système tel quel, j’ai peur de tout planter.

Mes questions :

  • Mon partitionnement peut-il être responsable ?
  • Malgré le formatage, l’ancienne installation sur les DD peut-il causer problème ?

Sinon il y a peut-être une manip à faire via le shell grub, mais je ne maîtrise pas ce mode de gestion.

Merci pour votre aide.

#2

Peux-tu préciser ce que tu entends par là ?
Tu as créé un ensemble RAID partitionné ? Le partitionneur de l’installateur Debian ne permet pas de partitionner un ensemble RAID, sauf si on y a créé une table de partition par un autre moyen.
Ou bien tu as créé plusieurs ensembles RAID : un pour /, un pour /home, etc. ?

Dans tous les cas, la partition système EFI (ESP) ne peut pas être dans un ensemble RAID logiciel ; c’est une partition formatée en FAT qui doit être lisible par le firmware UEFI qui ne sait pas lire le format du RAID logiciel de Linux (en fait c’est peut-être possible en RAID 1 mais pas dans un ensemble RAID partitionné et pas dans un ensemble RAID créé par le partitionneur de l’installateur Debian - il faut créer un type d’ensemble RAID particulier qui soit compatible avec un firmware UEFI). Pour l’installation de GRUB, elle doit être montée sur /boot/efi.

Qu’entends-tu par “exécuter l’EFI” et “il est à jour” ?

Comment le saurions-nous ? Tu n’as pas montré clairement ton partitionnement. La sortie de la commande fdisk -l aiderait.

Quel formatage ?

#3

Exactement.

[quote=“PascalHambourg, post:2, topic:75275”]
Dans tous les cas, la partition système EFI (ESP) ne peut pas être dans un ensemble RAID logiciel ; c’est une partition formatée en FAT qui doit être lisible par le firmware UEFI qui ne sait pas lire le format du RAID logiciel de Linux (en fait c’est peut-être possible en RAID 1 mais pas dans un ensemble RAID partitionné et pas dans un ensemble RAID créé par le partitionneur de l’installateur Debian[/quote]

J’ai créé une partition système EFI sur chaque DD que j’ai montée en RAID, en effet.

C’est-à-dire ? Le plus simple n’est pas ne de créer aucune partition, dans ce cas ?

Je dois confondre BIOS et EFI. Pour moi, EFI est le “nouveau BIOS”, il n’y a donc plus lieu de l’appeler BIOS. Je fais peut-être une erreur sémantique. Je veux parler de l’exécution des fonctions contenues dans la ROM de la CM.

Je voulais plutot dire : est-il correct de définir un tel partitionnement pour du RAID1 ?
D’accord, je vais le faire dès que j’ai accès au poste (ce soir normalement).

Après avoir défini les partitions, j’ai validé et un formatage de toutes les partitions s’est exécuté.

#4

A mon avis ce n’est pas la méthode la plus pratique si on n’utilise qu’un seul type de RAID, et il est plus avantageux de créer un seul ensemble RAID puis d’utiliser LVM pour créer des volumes logiques à l’intérieur. Inconvénients de ta méthode :

  • il est beaucoup plus compliqué de manipuler (créer, supprimer, redimensionner) un ensemble RAID qu’un volume logique LVM ;

  • en cas de défaillance et de remplacement d’un disque (après tout le RAID sert à ça), il faudra reconstruire chaque ensemble RAID séparément sur le nouveau disque.

Avec le format de superbloc RAID par défaut (1.2 = superbloc à 4 Kio après le début de la partition), le début des données est décalé par rapport au début des partitions RAID et il n’y a aucune chance que ces partitions soient reconnues comme des partitions système EFI valides par le firmware EFI. Pour avoir une chance il faudrait utiliser le format 1.0 qui place le superbloc à la fin, sans décaler le début des données. Mais le partitionneur de l’installateur ne permet pas de choisir le format de superbloc. Il faudrait donc créer l’ensemble RAID 1 manuellement avec la commande mdadm en spécifiant l’option --metadata=1.0. Il faut aussi s’assurer que le type de partition défini dans la table de partitition est bien “système EFI” et non “RAID”.

Ce n’est pas le seul problème avec l’utilisation d’un ensemble RAID pour la partition système EFI. Lors de l’installation de GRUB, grub-install doit enregistrer une entrée d’amorçage dans le firmware EFI contenant les coordonnées de la partition système EFI correspondante montée sur /boot/efi. J’ignore comment cela se passe si /boot/efi n’est pas une partition classique mais un ensemble RAID qui n’a par définition pas directement de coordonnées sur un disque. Je n’ai jamais essayé. Je doute que ce cas soit prévu.

Si le firmware EFI n’est pas trop buggé, il est possible de se passer d’enregistrer une entrée d’amorçage. Lors de l’installation de GRUB EFI, l’installateur doit demander s’il faut aussi l’installer dans le chemin de support amovible. Il faut répondre oui. C’est un emplacement spécial sur la partition système EFI qui est utilisé par défaut en absence d’entrée d’amorçage, qui est notamment utilisé pour amorcer les supports amovibles en mode EFI.

En effet, l’UEFI est le remplaçant du BIOS. Mais les fabricants et les utilisateurs continuent d 'entretenir la confusion en parlant même de “BIOS UEFI”.

#5

Merci beaucou pH pour ta réponse très complète.
C’est un peu (beaucoup) technique pour moi mais je pense avoir compris cela :

  • Je paramètre d’abord la gestion logicielle RAID1 puis j’utilise LVM pour créer les partitions logiques que je répartis comme je le veux ;
  • Sauf la partition système EFI ne doit pas se trouver sur un ensemble RAID.

Mais alors, comment installer l’EFI ? Sur les deux disques mais sans RAID ? Ou bien est-il possible d’installer le système EFI et /boot sur un 3ème DD physique ?

Je viens de relancer mon serveur pour voir quel est le message exact, et je me suis permis de modifier mon post initial sinon c’est difficile à suivre pour celui qui prend la discussion en marche :

Donc cela colle tout à fait avec ce que tu m’expliques !!

C’est ce que je fais,ça bugge quand même.

D’accord. C’est pour cela que je n’ai jamais trop compris. On voit en effet des BIOS qui sont des UEFI et qui affichent “BIOS” à leur démarrage.

#6

Oui. Dans des partitions normales sur les deux disques, utilisées comme partition d’amorçage EFI (partition système EFI, ESP en abrégé). L’installateur n’utilisera qu’une seule des deux pour installer GRUB, mais ensuite tu pourras installer GRUB sur l’autre manuellement afin d’assurer la redondance de l’amorçage.
Il n’est pas nécessaire de mettre /boot hors du RAID et de LVM ; GRUB sait lire le RAID logiciel et LVM.

Lors de la tentative d’installation de GRUB par l’installateur et l’affichage du message d’échec, tu peux basculer dans la console des logs avec Ctrl+Alt+F4 pour voir les messages plus détaillés. Je soupçonne que grub-install ou efibootmgr (plutôt ce dernier) qui sert à enregistrer GRUB dans les variables de boot EFI n’aime pas que /boot/efi ne soit pas une partition normale.

Il est normal que l’erreur se produise aussi en répondant oui à l’installation sur le chemin de support amovible, car cette installation se fait en plus de l’installation normale qui déclenche l’erreur, pas à la place. Mais cela ne veut pas dire que l’installation dans le chemin de support amovible a échoué. Par contre, si /boot/efi est dans un ensemble RAID au format 1.2, l’amorçage ne peut pas fonctionner. Il faut au minimum supprimer cet ensemble RAID et le remplacer par deux partitions EFI indépendantes.

#7

Désolé je ne suis pas très rapide pour répondre mais boulot ++ et une famille qui commence à être nombreuse…

OK. Je ne vois pas trop comment faire pour installer GRUB manuellement sur la deuxième partition (faire un dump peut-être ?) mais je creuserai la question le moment venu.

Super, c’est une commande intéressante à connaître ! Sinon il y a peut-être moyen aussi de les chercher via la console accessible depuis le menu d’install ? Je l’ai bien un peu essayée, mais comme elle ne tourne pas sur bash et que les commandes sont succintes, je me suis perdu.

Quelque chose doit m’échapper car je trouve cela contradictoire. Si /boot/efi ne tolère que les partitions normales, comment /boot peut-il être dans le RAID ? Ou alors ./efi est monté automatiquement dans l’ESP, au même titre que l’on peut mettre / et /home dans deux partitions ?

C’est pourtant ce que j’espérais… :smile:

D’ailleurs, j’ai remarqué qu’en utilisant LVM sur un disque entier, il laissait 1 Mo en début et 75 Ko en fin de disque. Tandis qu’en simulant un montage RAID logiciel qui occuperait tout le disque, ça ne le fait pas.

#8

Il y a plusieurs méthodes possibles. Copie des fichiers, exécution de grub-install avec des paramètres particuliers… Le clonage de la partition est une possibilité qui a ses avantages et ses inconvénients.

Oui, ils sont dans un fichier log dans le répertoire /var/log.

Oui, mais c’est plutôt l’inverse : la partition EFI est montée sur /boot/efi. Elle ne fait pas partie du RAID qui contient le reste de /boot.[quote=“Xisqu4re, post:7, topic:75275”]
D’ailleurs, j’ai remarqué qu’en utilisant LVM sur un disque entier, il laissait 1 Mo en début et 75 Ko en fin de disque. Tandis qu’en simulant un montage RAID logiciel qui occuperait tout le disque, ça ne le fait pas.
[/quote]
Il devrait le faire dans tous les cas. C’est pour aligner le début et la fin des partitions sur des multiples entiers de 1 Mio.

#9

Bien, maintenant que tout cela est plus clair, dès que j’ai le temps j’essaye (normalement dans 2 ou 3 jours) et je vous tiens au courant.

#11

J’ai enfin trouvé le temps pour faire des tests.
J’ai suivi les conseils de pH.
J’ai donc tout réinstallé en faisant, dans l’ordre :

  1. une partition bootable ESP de 538MB par disque
  2. une configuration RAID logicielle sur le reste de l’espace disque
  3. une configuration logique avec LVM avec comme partitions :
    /boot
    /
    /home
    /var
    /tmp
    swap

Le tout en ext4 sauf /boot en ext2 (LVM le configure comme ça automatiquement, il y a sûrement une bonne raison ?)

L’installation s’est passée sans problème, tout fonctionne.
Le seul point qui me reste à éclaircir c’est pour installer GRUB manuellement sur la 2ème partition.

Merci pH pour aide précieuse.

#12

La partition EFI d’un des disques est montée sur /boot/efi
Créer un répertoire /boot/efi2.
Monter la partition système EFI de l’autre disque sur /boot/efi2. Par exemple si c’est /dev/sdb1 :

mount /dev/sdb1 /boot/efi2

Créer un répertoire /boot/efi2/EFI/BOOT :

mkdir -p /boot/efi2/EFI/boot

Copier l’image EFI de GRUB dans le chemin de support amovible :

cp /boot/efi/EFI/debian/grubx64.efi /boot/efi2/EFI/boot/bootx64.efi
#13

[quote=“PascalHambourg, post:12, topic:75275”]bootx64.efi
[/quote]
C’est pas plutôt grubx64.efi ?

#14

Non, à cet emplacement le fichier doit être nommé bootx64.efi pour être utilisé comme chargeur d’amorçage par défaut sans entrée d’amorçage EFI enregistrée. D’ailleurs tu peux aussi le copier au même emplacement dans la partition EFI montée sur /boot/efi.

 cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx64.efi
#15

D’accord.
Au final cela crée des répliques de l’image EFI avec des chemins et des nom différents.
C’est subtil !

Justement, je me demandais ce qu’il se passe si /dev/sda1 qui est monté sur /boot/efi est défaillant. Lorsque je fais ta manip de copie de /dev/sdb1 sur /boot/efi2, si je reboote mon serveur, la partition n’est plus montée. D’après ce que je comprends de ton explication, ton montage résoud ce problème.

#16

Ah oui, j’oubliais ça…
GRUB devrait quand même démarrer grâce à la copie faite dans le chemin de support amovible de l’autre disque. Par contre le système va chercher à monter la partition EFI d’origine (identifiée par son UUID) sur /boot/efi comme indiqué dans /etc/fstab. Le disque étant manquant, il y aura un délai de 90 secondes avant abandon et erreur. Je ne me souviens plus si ça déclenche le shell d’urgence ou si ça continue le démarrage quand même. L’avantage est que si on n’avait pas remarqué la défaillance d’un disque, au moins cette fois c’est clair.

Plusieurs solutions palliatives (aucune n’est parfaite) :

  • Ajouter l’option “nofail” dans le 4e champ de la ligne de /etc/fstab. Je pense qu’il y aura toujours le délai, mais pas d’erreur.

  • Remplacer UUID=xxx par /dev/sda1. Si le premier disque est défaillant, c’est le second qui deviendra /dev/sda. Mais on évite d’utiliser les noms de périphériques dans /etc/fstab car ils ne sont pas forcément persistants.

  • Ajouter l’option “noauto” dans le 4e champ de la ligne de /etc/fstab pour que la partition ne soit pas montée automatiquement au démarrage. Après tout, celle-ci n’est utilisée que lors de l’installation du chargeur GRUB ou d’une mise à jour des paquets grub*. Il faudra donc penser à la monter manuellement quand c’est nécessaire.

  • Modifier l’UUID du système de fichiers FAT de /dev/sdb1 pour qu’il soit identique à celui de /dev/sda1, mentionné dans /etc/fstab. Ainsi n’importe laquelle des deux pourra être montée (et pas seulement quand un disque est défaillant). Mais c’est mal car les UUID sont censés être uniques (le second “U” dans UUID). Par contre je ne connais pas de commande pour modifier l’identifiant de volume (servant d’UUID) d’un système de fichiers FAT existant, je sais seulement définir l’identifiant de volume à la création (formatage) avec l’option -i de mkdosfs.

  • Une alternative à la solution précédente consiste à cloner la partition /dev/sda1 (après l’avoir démontée) sur /dev/sdb1, si elles ont la même taille.

C’est normal : le montage n’a pas été enregistré dans /etc/fstab. Si tu veux qu’elle soit systématiquement montée, il faut ajouter une ligne dans le fichier. Mais cela présente le même inconvénient que pour l’autre partition EFI si le disque est défaillant, et comme elle on n’en a pas souvent besoin.

(Il faudrait vraiment que je teste le montage d’un ensemble RAID 1 au format 1.0 sur /boot/efi pour voir comment grub-install se comporte.)

#17

Il faudrait que j’essaye en débranchant le disque sda.
Le shell d’urgence permet-il un accès ssh ? Dans mon cas l’accès direct machine est compliqué, puis on n’est pas à l’abri d’avoir à redémarrer la bécane loin de chez soi, il suffit que ça arrive un jour où un disque crame…

La 1 ne semble pas la mieux car comme tu le dis plus tôt on peut passer à côté d’une défaillance de disque.
La 2 et la 4… je n’ai pas envie de jouer avec le feu :fire_engine: !
OK pour la 3, et je présume que grub se met à jour en même temps que le reste lors d’un apt-get upgrade par exemple ? Après, il faut juste se souvenir du point de montage, mais le chemin n’est pas trop sorcier.
Pour la 5, sudo df /dev/sda1 /dev/sdb1 me sort :

Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
/dev/sda1             523248     312     522936   1% /boot/efi
/dev/sdb1             523248     160     523088   1% /boot/efi2

donc à l’octet près, c’est bon. cfdisk permet le clonage ? Quels sont les inconvénients d’une telle méthode ?

Tu me l’avais bien suggéré mais j’ai pas osé, vu que je me galère déjà à installer un RAID stable !

#18

Attention, il y a un petit risque. Je n’en ai pas la certitude car je n’avais pas accès directement à la machine pour faire des tests exhaustifs lorsque cela s’est produit, mais je soupçonne certains firmwares UEFI de supprimer les entrées d’amorçages EFI des disques manquants, probablement dans la bonne intention de faire du nettoyage car la mémoire non volatile qui stocke ces entrées n’est pas infinie. Le retrait temporaire d’un disque peut donc le rendre impossible à booter.

Pour que le disque soit bootable même sans entrée d’amorçage, on doit copier GRUB dans le chemin de support amovible EFI/boot/bootx64.efi de la partition EFI comme je l’ai montré plus haut.

Et pour tester l’échec du montage de la partition EFI sans débrancher le disque, il suffit de modifier temporairement l’UUID dans /etc/fstab (par exemple en ajoutant un caractère qu’on pourra effacer ensuite), ainsi elle ne sera pas reconnue.

Je ne pense pas. Il me semble qu’en cas d’échec d’un montage obligatoire (sans “nofail”), les services ne sont pas démarrés car il peut manquer une partie importante de l’arborescence comme /home, /srv, /var… indispensable au fonctionnement des services. S’il est important que le système puisse redémarrer avec un disque défaillant sans intervention physique, je te recommande d’utiliser l’option nofail ou noauto dans /etc/fstab.

Oui. Mais noauto a le même inconvénient que nofail : la défaillance peut passer inaperçue au démarrage puisqu’il n’y a pas de délai ni d’arrêt dans le shell d’urgence. Néanmoins mdadm est censé envoyer un mail à root (par défaut) pour l’informer d’une défaillance.

J’ignore si cfdisk permet le clonage, je ne l’ai jamais employé dans ce but. Pour moi c’est juste un gestionnaire de table de partition. Je clone les partitions et les disques avec dd. On peut même utiliser cp avec les noms de périphériques source et destination.

Les inconvénients sont les mêmes que la duplication de l’UUID, car c’est l’effet que cela va avoir au final. Si tu choisis cette solution, il est préférable de copier GRUB dans le chemin de support amovible de la partition source avant de la cloner, cela évitera de devoir le faire sur la partition cible après le clonage. D’après l’espace occupé des deux partitions, tu l’as déjà fait.

#19

J’ai testé sur un système déjà installé.
Comme je m’y attendais, la première étape de l’exécution de grub-install consistant à écrire le ou les fichiers .efi dans /boot/efi se passe sans encombre. Par contre la seconde étape consistant à invoquer efibootmgr pour enregistrer EFI/debian/grubx64.efi (relativement à la racine de la partition EFI) dans les variables d’amorçage du firmware EFI échoue car un ensemble RAID n’est pas une partition.

Néanmoins l’exécution avec l’option --removable qui écrit GRUB dans le chemin de support amovible /boot/efi/EFI/boot/bootx64.efi sans invoquer efibootmgr se termine sans erreur, et l’amorçage fonctionne. Le firmware a bien détecté un chargeur par défaut dans les deux partitions EFI mises en RAID 1.

Je n’ai pas testé avec l’installateur Debian, mais si on répond oui lorsqu’il est demandé s’il faut forcer l’installation de GRUB dans le chemin de support amovible, alors GRUB est installé à la fois dans son emplacement normal /boot/efi/EFI/debian/grubx64.efi et dans le chemin de support amovible /boot/efi/EFI/boot/bootx64.efi. La tentative d’enregistrement de l’emplacement normal dans les variables de boot EFI échouera et provoquera une erreur, mais la présence de GRUB dans le chemin de support amovible devrait permettre de démarrer.

#20

J’ai mémoire d’avoir testé une modif de points de montages obligatoires sur un Raspberry Pi dans /etc/fstab, c’était pour tenter de monter au démarrage 2 disques durs non auto-alimentés, mais le RPi3 n’est pas assez puissant pour ça. Du coup le montage échouait, un shell (accessible qu’en root me semble-t-il) démarrait mais sans accès réseau.

Tiens, j’avais oublié cet élément important.
sudo mdadm --monitor /dev/md0p1 retourne :

mdadm: Monitor using email address "root" from config file
mdadm: Warning: One autorebuild process already running.

Mais je ne crois pas avoir entré d’adresse mail pour root à l’install, aussi dois-je configurer un client SMTP peut-être ? Et je ne vois pas quel est ce “config file” de root (en général je n’aime pas toucher à tout ce qui touche à root).

sudo ls -R /boot/efi /boot/efi2 renvoit ceci :

/boot/efi:
EFI

/boot/efi/EFI:
boot  debian

/boot/efi/EFI/boot:
bootx64.efi

/boot/efi/EFI/debian:
grubx64.efi

/boot/efi2:
EFI

/boot/efi2/EFI:
boot

/boot/efi2/EFI/boot:
bootx64.efi

Donc hormis le clonage que je n’ai pas encore fait, mon installation a l’air assez robuste.

#21

Au final, cette solution semble la préférable si elle fonctionne car elle permet d’éviter les manipulations ci-dessus. Dommage que l’installateur RAID logiciel de Debian ne permette pas cela.

AU fait, quid du RAID matériel, hormis le coût de la carte ? Mieux ou moins bien que le RAID logiciel ?