# Installation : crash grub-install en RAID1 **URL:** \ **Category:** Support Debian\ **Tags:** boot, raid, grub\ **Created:** [Décembre 2, 2017, 3:49 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275 "2017-12-02T15:49:23Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Xisqu4re](https://www.debian-fr.org/user_avatar/www.debian-fr.org/xisqu4re/32/6278_2.png) [@Xisqu4re](https://www.debian-fr.org/u/Xisqu4re)\ **Post date:** [Décembre 2, 2017, 3:49 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/1 "2017-12-02T15:49:24Z")
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. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 2, 2017, 11:23 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/2 "2017-12-02T23:23:02Z")
> [@](#): > > Mon RAID logiciel est partitionné comme suit 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. > [@](#): > > Je redémarre le serveur en exécutant l’EFI : il est à jour. Qu’entends-tu par “exécuter l’EFI” et “il est à jour” ? > [@](#): > > Mon partitionnement peut-il être responsable ? Comment le saurions-nous ? Tu n’as pas montré clairement ton partitionnement. La sortie de la commande `fdisk -l` aiderait. > [@](#): > > Malgré le formatage, l’ancienne installation sur les DD peut-il causer problème ? Quel formatage ? ---
**Author:** ![Xisqu4re](https://www.debian-fr.org/user_avatar/www.debian-fr.org/xisqu4re/32/6278_2.png) [@Xisqu4re](https://www.debian-fr.org/u/Xisqu4re)\ **Post date:** [Décembre 3, 2017, 7:26 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/3 "2017-12-03T07:26:26Z")
> [@](#): > > Ou bien tu as créé plusieurs ensembles RAID : un pour /, un pour /home, etc. ? 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. > [@](#): > > 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. C’est-à-dire ? Le plus simple n’est pas ne de créer aucune partition, dans ce cas ? > [@](#): > > Qu’entends-tu par “exécuter l’EFI” et “il est à jour” ? 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. > [@](#): > > Comment le saurions-nous ? Tu n’as pas montré clairement ton partitionnement. La sortie de la commande fdisk -l aiderait. 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). > [@](#): > > Quel formatage ? Après avoir défini les partitions, j’ai validé et un formatage de toutes les partitions s’est exécuté. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 3, 2017, 9:12 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/4 "2017-12-03T09:12:54Z")
> [@](#): > > > Ou bien tu as créé plusieurs ensembles RAID : un pour /, un pour /home, etc. ? > > Exactement. 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. > [@](#): > > J’ai créé une partition système EFI sur chaque DD que j’ai montée en RAID, en effet. 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. > [@](#): > > Pour moi, EFI est le “nouveau BIOS”, il n’y a donc plus lieu de l’appeler BIOS. 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”. ---
**Author:** ![Xisqu4re](https://www.debian-fr.org/user_avatar/www.debian-fr.org/xisqu4re/32/6278_2.png) [@Xisqu4re](https://www.debian-fr.org/u/Xisqu4re)\ **Post date:** [Décembre 3, 2017, 8:58 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/5 "2017-12-03T20:58:40Z")
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 : > [@](#): > > 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 ?”. Donc cela colle tout à fait avec ce que tu m’expliques !! > [@](#): > > 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 ce que je fais,ça bugge quand même. > [@](#): > > 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”. 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. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 3, 2017, 10:28 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/6 "2017-12-03T22:28:58Z")
> [@](#): > > Mais alors, comment installer l’EFI ? Sur les deux disques mais sans RAID ? 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. ---
**Author:** ![Xisqu4re](https://www.debian-fr.org/user_avatar/www.debian-fr.org/xisqu4re/32/6278_2.png) [@Xisqu4re](https://www.debian-fr.org/u/Xisqu4re)\ **Post date:** [Décembre 4, 2017, 8:57 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/7 "2017-12-04T20:57:11Z")
Désolé je ne suis pas très rapide pour répondre mais boulot ++ et une famille qui commence à être nombreuse… > [@](#): > > 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. 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. > [@](#): > > 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. 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. > [@](#): > > Il n’est pas nécessaire de mettre /boot hors du RAID et de LVM ; GRUB sait lire le RAID logiciel et LVM. (…) 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. 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 ? > [@](#): > > 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. C’est pourtant ce que j’espérais… 😄 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. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 4, 2017, 10:45 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/8 "2017-12-04T22:45:40Z")
> [@](#): > > Je ne vois pas trop comment faire pour installer GRUB manuellement sur la deuxième partition (faire un dump peut-être ?) 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. > [@](#): > > Sinon il y a peut-être moyen aussi de les chercher via la console accessible depuis le menu d’install ? Oui, ils sont dans un fichier log dans le répertoire /var/log. > [@](#): > > 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 ? 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. ---
**Author:** ![Xisqu4re](https://www.debian-fr.org/user_avatar/www.debian-fr.org/xisqu4re/32/6278_2.png) [@Xisqu4re](https://www.debian-fr.org/u/Xisqu4re)\ **Post date:** [Décembre 5, 2017, 5:45 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/9 "2017-12-05T05:45:16Z")
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. ---
**Author:** ![Xisqu4re](https://www.debian-fr.org/user_avatar/www.debian-fr.org/xisqu4re/32/6278_2.png) [@Xisqu4re](https://www.debian-fr.org/u/Xisqu4re)\ **Post date:** [Décembre 7, 2017, 9:51 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/11 "2017-12-07T21:51:29Z")
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. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 7, 2017, 10:03 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/12 "2017-12-07T22:03:30Z")
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 ``` ---
**Author:** ![Xisqu4re](https://www.debian-fr.org/user_avatar/www.debian-fr.org/xisqu4re/32/6278_2.png) [@Xisqu4re](https://www.debian-fr.org/u/Xisqu4re)\ **Post date:** [Décembre 7, 2017, 10:31 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/13 "2017-12-07T22:31:31Z")
[quote=“PascalHambourg, post:12, topic:75275”]`bootx64.efi` [/quote] C’est pas plutôt `grubx64.efi` ? ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 8, 2017, 8:20 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/14 "2017-12-08T08:20:28Z")
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 ``` ---
**Author:** ![Xisqu4re](https://www.debian-fr.org/user_avatar/www.debian-fr.org/xisqu4re/32/6278_2.png) [@Xisqu4re](https://www.debian-fr.org/u/Xisqu4re)\ **Post date:** [Décembre 8, 2017, 3:44 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/15 "2017-12-08T15:44:28Z")
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 ! > [@](#): > > 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. 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. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 8, 2017, 6:53 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/16 "2017-12-08T18:53:57Z")
> [@](#): > > Justement, je me demandais ce qu’il se passe si /dev/sda1 qui est monté sur /boot/efi est défaillant. 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. > [@](#): > > 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. 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.) ---
**Author:** ![Xisqu4re](https://www.debian-fr.org/user_avatar/www.debian-fr.org/xisqu4re/32/6278_2.png) [@Xisqu4re](https://www.debian-fr.org/u/Xisqu4re)\ **Post date:** [Décembre 8, 2017, 11:55 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/17 "2017-12-08T23:55:49Z")
> [@](#): > > Je ne me souviens plus si ça déclenche le shell d’urgence ou si ça continue le démarrage quand même. 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… > [@](#): > > Plusieurs solutions palliatives (aucune n’est parfaite) : 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 🚒 ! 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 ? > [@](#): > > (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.) Tu me l’avais bien suggéré mais j’ai pas osé, vu que je me galère déjà à installer un RAID stable ! ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 9, 2017, 9:37 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/18 "2017-12-09T09:37:11Z")
> [@](#): > > Il faudrait que j’essaye en débranchant le disque sda. 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. > [@](#): > > Le shell d’urgence permet-il un accès ssh ? 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. > [@](#): > > 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 ? 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. > [@](#): > > cfdisk permet le clonage ? Quels sont les inconvénients d’une telle méthode ? 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. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 10, 2017, 9:48 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/19 "2017-12-10T09:48:34Z")
> [@](#): > > 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. 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. ---
**Author:** ![Xisqu4re](https://www.debian-fr.org/user_avatar/www.debian-fr.org/xisqu4re/32/6278_2.png) [@Xisqu4re](https://www.debian-fr.org/u/Xisqu4re)\ **Post date:** [Décembre 10, 2017, 5:13 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/20 "2017-12-10T17:13:37Z")
> [@](#): > > Le shell d’urgence permet-il un accès ssh ? > > 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. 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. > [@](#): > > Néanmoins mdadm est censé envoyer un mail à root (par défaut) pour l’informer d’une défaillance. 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). > [@](#): > > D’après l’espace occupé des deux partitions, tu l’as déjà fait. `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. ---
**Author:** ![Xisqu4re](https://www.debian-fr.org/user_avatar/www.debian-fr.org/xisqu4re/32/6278_2.png) [@Xisqu4re](https://www.debian-fr.org/u/Xisqu4re)\ **Post date:** [Décembre 10, 2017, 5:16 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/21 "2017-12-10T17:16:48Z")
> [@](#): > > 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. 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 ? [Page suivante](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275.md?page=2)