# 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:** 2
**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, 5:42 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/22 "2017-12-10T17:42:05Z")
> [@](#): > > 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). Le fichier de configuration de mdadm est /etc/mdadm/mdadm.conf. Un MTA comme exim4 doit être installé. Par défaut les mails adressés à root sont envoyés dans la BAL locale de l’utilisateur créé lors de l’installation. Voir dans le fichier /etc/aliases. Si tu veux envoyer ces mails vers une BAL extérieure, il faut configurer le MTA pour, et le cas échéant réécrire l’adresse d’expéditeur pour qu’elle ne soit pas rejetée comme inexistante par le MTA destinataire. Avec exim, cela se fait dans le fichier /etc/email-addresses. > [@](#): > > 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. Je pense qu’il le permet, en bidouillant un peu et en acceptant que l’installation de GRUB finisse en erreur. Mais je peux difficilement tester sur mon seul PC compatible UEFI à cause de plusieurs bugs qui entravent l’utilisation de l’installateur Debian en mode EFI. J’installe donc en mode BIOS et je convertis en EFI ensuite. > [@](#): > > AU fait, quid du RAID matériel, hormis le coût de la carte ? Mieux ou moins bien que le RAID logiciel ? Ça dépend sur quels critères. Déjà on parle de vrai RAID matériel, pas du RAID pseudo-matériel (fakeRAID) des chipsets de cartes mères géré par le BIOS. Je suppose qu’il faut que le firmware de la carte contrôleur RAID soit compatible UEFI, à moins que le firmware UEFI de la carte mère soit capable de faire appel aux fonctions disque BIOS des cartes d’extension. Je n’ai aucune expérience dans ce domaine. Il faut aussi disposer du pilote pour la carte contrôleur et du logiciel de supervision pour avertir d’une défaillance. Si la carte contrôleur tombe en panne et si on n’en a pas une seconde en réserve (ce qui double le coût), on peut dire adieu aux données, alors qu’avec le RAID logiciel il suffit de connecter les disques à n’importe quelle carte mère. Quant aux performances, je n’ai aucune expérience non plus avec le RAID matériel. J’ai juste lu que le RAID logiciel sur un processeur performant et pas trop chargé pouvait être aussi performant que du RAID matériel avec un contrôleur pas top. ---
**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, 6:07 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/23 "2017-12-10T18:07:44Z")
> [@](#): > > Le fichier de configuration de mdadm est /etc/mdadm/mdadm.conf. > Un MTA comme exim4 doit être installé. Par défaut les mails adressés à root sont envoyés dans la BAL locale de l’utilisateur créé lors de l’installation. Voir dans le fichier /etc/aliases. > Si tu veux envoyer ces mails vers une BAL extérieure, il faut configurer le MTA pour, et le cas échéant réécrire l’adresse d’expéditeur pour qu’elle ne soit pas rejetée comme inexistante par le MTA destinataire. Avec exim, cela se fait dans le fichier /etc/email-addresses. OK, je vais regarder tout cela. Au final, pour le RAID matériel, ça n’a franchement pas l’air de valoir le coup et c’est bien ce que pensais. En plus une vraie carte RAID n’est vraiment pas donnée. ---
**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\ **Post date:** [Décembre 10, 2017, 8:02 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/24 "2017-12-10T20:02:06Z")
> [@](#): > > …une vraie carte RAID n’est vraiment pas donnée. Et encore, tu ne calcule qu’en tenant compte du prix d’une seule carte mère permettant le RAID matériel (ou une seule carte contrôleur RAID spécifique), alors qu’il te faudrait prévoir aussi d’en acheter une deuxième. Car si cette carte venait à tomber en panne, tu ne pourrais sans doute récupérer tes données qu’avec une carte du même type, modèle, version de BIOS etc. Bien sûr, tu pourrais remettre à plus tard cet achat, en croisant les doigts pour que, le jour où la panne arrivera, cette carte soit encore disponible dans la même version de BIOS. ---
**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, 8:44 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/25 "2017-12-10T20:44:03Z")
Concrètemenent, le prix minimum aujourd’hui : 300€ la carte RAID premier prix 40€ la CM µ-ATX premier prix supportant le RAID matériel (300+40)x2=680 € TTC, sans compter l’achat des DD et de tout le reste… faut avoir de sacrés besoins de performances !! ---
**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, 11:36 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/26 "2017-12-10T23:36:17Z")
C’est quoi, “une carte mère supportant le RAID matériel” ? ---
**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 11, 2017, 8:35 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/27 "2017-12-11T08:35:07Z")
[Ca](https://www.ldlc.com/fiche/PB00227613.html) par exemple. Mais c’est peut-être plutôt un type de CM qui intègre une gestion pseudo-matérielle du RAID. Car autrement n’importe quelle type de CM qui a les slots adaptés devrait pouvoir le tolérer ? ---
**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\ **Post date:** [Décembre 11, 2017, 9:23 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/28 "2017-12-11T09:23:05Z")
Cela fait bien longtemps que je n’ai pas acheté de carte mère, donc je ne suis plus trop au courant de ce qui se fait actuellement. Mais quand j’en voyais une dont les caractéristiques annoncées affichait RAID, je vérifiais si ce n’était pas, comme la plupart du temps, une fonctionnalité (microcode) qui était implémentée dans le BIOS pour gérer le RAID en utilisant des composants électroniques standards pour la gestion des disques. Ce qui, pour moi, même si elle est implémentée en très bas niveau, est quand même une gestion RAID logicielle (propriétaire). Mais [Certaines cartes mères](https://www.asus.com/fr/Motherboards/P8P67_EVO/specifications/) sont effectivement équipées de [composants électroniques](http://pdf1.alldatasheet.fr/datasheet-pdf/view/317088/MARVELL/88SE9120.html) ([lien vers le datasheet](https://framadrop.org/r/SObNdz5QsT#oqbGjTwcLOLpwuO6ci6ZmRkP6sFvvcggCvdYt9jRcKw=)) qui gèrent (en interne) de façon électronique les calculs de parité et autres calculs nécessaires pour certains modes RAID ---
**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 11, 2017, 7:07 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/29 "2017-12-11T19:07:43Z")
> [@](#): > > Mais c’est peut-être plutôt un type de CM qui intègre une gestion pseudo-matérielle du RAID. Oui, plutôt. > [@](#): > > Car autrement n’importe quelle type de CM qui a les slots adaptés devrait pouvoir le tolérer ? C’est ce qu’il me semblait, d’où ma question. ---
**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 11, 2017, 8:53 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/30 "2017-12-11T20:53:34Z")
> [@](#): > > Mais c’est peut-être plutôt un type de CM qui intègre une gestion pseudo-matérielle du RAID. > > Oui, plutôt. D’après les liens de @anon29980398, ça ne fait pas de doute. Je partais donc d’une idée plus qu’approximative en voyant les mentions “RAID supporté” sur les CM du commerce. J’ai essayé de regarder quelques notices sur des CM Asrock ou Asus qui mentionnent “RAID supporté” mais les infos que j’ai trouvées sont très vagues. ---
**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 11, 2017, 9:27 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/31 "2017-12-11T21:27:21Z")
> [@](#): > > Plusieurs solutions palliatives (aucune n’est parfaite) : Pourquoi ne pourrait-on pas configurer `/etc/fstab` en ajoutant sous la ligne de montage de `/boot/efi` sur `/dev/sda1` (avec son UUID correspondant) la même chose mais avec `/boot/efi2` et `/dev/sdb1` ? ``` # /boot/efi was on /dev/sda1 during installation UUID= /boot/efi vfat umask=0077 0 1 UUID= /boot/efi2 vfat umask=0077 0 1 ``` ---
**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 11, 2017, 10:21 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/32 "2017-12-11T22:21:56Z")
Rien ne l’empêche, mais je ne vois pas trop ce que ça apporte à part introduire un délai d’attente et provoquer une erreur si n’importe lequel des deux disque est en panne. ---
**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 12, 2017, 10:44 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/33 "2017-12-12T22:44:56Z")
En effet, c’est idiot. Dès que j’ai le temps, maintenant que j’ai cloné sda1 sur sdb1, j’essaye de modifier l’UUID de sda1 pour voir comment le serveur réagit au démarrage, et je te fais part de mon retour. ---
**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 17, 2017, 4:47 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/34 "2017-12-17T16:47:40Z")
J’ai donc cloné la partition sda1 sur sdb1 avec : **`cp /dev/sda1 /dev/sdb1`** Vérification : ``` $ sudo df /dev/sda1 /dev/sdb1 Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur /dev/sda1 523248 312 522936 1% /boot/efi /dev/sdb1 523248 312 522936 1% /boot/efi2 $ sudo ls -R /boot/efi/EFI /boot/efi2/EFI /boot/efi2/EFI: boot debian /boot/efi2/EFI/boot: bootx64.efi /boot/efi2/EFI/debian: grubx64.efi /boot/efi/EFI: boot debian /boot/efi/EFI/boot: bootx64.efi /boot/efi/EFI/debian: grubx64.efi ``` J’ai modifié l’UUID de sda1 dans `/etc/fstab`. Je n’ajoute pas `noauto` ni `nofail`. J’ai fait un reboot, qui affiche ceci puis qui démarre en shell d’urgence : ``` WARNING: Failed to connect to lvmetad. Falling back to device scanning. WARNING: Failed to connect to lvmetad. Falling back to device scanning. [DEPEND] Dependency failed for /boot/efi. [DEPEND] Dependency failed for Local File Systems. ``` Via le shell d’urgence, j’exécute **`journalctl -xb`** dans lequel je trouve : ``` déc. 17 17:19:26 crozet kernel: ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20160831/dswload-210) déc. 17 17:19:26 crozet kernel: ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20160831/psobject-227) déc. 17 17:19:26 crozet kernel: ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp08) while loading table (20160831/tbxfload-228) déc. 17 17:19:26 crozet kernel: ACPI Error: 1 table load failures, 5 successful (20160831/tbxfload-246) ``` J’ai testé avec `noauto` et évidemment le démarrage se fait sans problème. Chose étonnante : si à ce stade je refais un **`journalctl -xb`** j’ai exactement la même erreur que précédemment. Cette erreur n’a donc sûrement rien à voir avec l’échec de montage de `/dev/sda1`. Je ne comprends pas pourquoi malgré le clonage, sdb1 ne prend pas le relais de sda1. Il est probable que je cherche mal dans les fichiers log, je n’y suis pas habitué. Je sais que je pinaille et que je peux me contenter de `noauto` ou de `nofail`, mais j’aime bien aller jusqu’au bout des choses… ---
**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 17, 2017, 6:53 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/35 "2017-12-17T18:53:03Z")
> [@](#): > > J’ai modifié l’UUID de sda1 dans /etc/fstab. L’UUID d’une partition ne se modifie pas dans fstab mais dans le système de fichiers lui-même. Tu n’as pas modifié l’UUID du système de fichiers de sda1. Tu as modifié l’UUID du système de fichiers recherché pour être monté sur /boot/efi. Et comme aucune partition présente n’a cet UUID, bien sûr, le montage échoue. Et logiquement, comme tu as cloné sda1 sur sdb1, l’UUID de sdb1 a changé et ne correspond plus non plus à l’UUID recherché pour être monté sur /boot/efi2, donc ce montage devrait aussi échouer. Mais la situation actuelle n’est pas claire, peux-tu fournir le contenu de fstab et la sortie de blkid sans caviardage ? Les messages ACPI n’ont effectivement rien à voir avec les échecs de montage. ---
**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 17, 2017, 11:03 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/36 "2017-12-17T23:03:08Z")
OK. Le contenu de fstab : ``` # /dev/mapper/crozet--vg-root / ext4 noatime,errors=remount-ro 0 1 /dev/mapper/crozet--vg-boot /boot ext2 noatime 0 2 # /boot/efi was on /dev/sda1 during installation # UUID=0EBA-51CC /boot/efi vfat umask=0077 0 1 UUID=0EBA-51CC /boot/efi vfat umask=0077,noauto 0 1 /dev/mapper/crozet--vg-home /home ext4 noatime,usrquota,grpquota 0 2 /dev/mapper/crozet--vg-tmp /tmp ext4 noatime,nosuid 0 2 /dev/mapper/crozet--vg-var /var ext4 noatime 0 2 /dev/mapper/crozet--vg-swap none swap sw 0 0 ``` Sortie de blkid : ``` /dev/sdb1: UUID="0EBA-51CC" TYPE="vfat" PARTUUID="684f1352-e62b-45f0-90ef-ea380a2053d9" /dev/sdb2: UUID="d6233160-5bf8-f1e4-f82d-75bff726e12a" UUID_SUB="78a7116b-589c-b728-2bcb-ed0a46fa5c08" LABEL="crozet:0" TYPE="linux_raid_member" PARTUUID="d80b3128-472c-40be-bfea-9646249a7f8b" /dev/sda1: UUID="0EBA-51CC" TYPE="vfat" PARTUUID="b7d48b3e-f0d7-40b3-bfef-172224c888ae" /dev/sda2: UUID="d6233160-5bf8-f1e4-f82d-75bff726e12a" UUID_SUB="7aa75e90-bd7c-f551-980a-8fb8da358fd4" LABEL="crozet:0" TYPE="linux_raid_member" PARTUUID="53aa1f50-2f78-4f5e-a701-ff655f85a615" /dev/md0: PTUUID="fcf13369-faaf-4dbc-b753-0146c2683867" PTTYPE="gpt" /dev/md0p1: UUID="prRY6Q-2Jtw-BaUg-tiHv-XFnd-ojjH-Z4RbRy" TYPE="LVM2_member" PARTUUID="25a81569-2ad6-4c06-ac3c-191a6397c8c0" /dev/mapper/crozet--vg-var: UUID="e0ab30ee-4b45-47e2-8465-76ee4c13808c" TYPE="ext4" /dev/mapper/crozet--vg-swap: UUID="7a5d3a54-99e4-4fa5-adb2-1bf67b65fc45" TYPE="swap" /dev/mapper/crozet--vg-tmp: UUID="722155b7-1b3f-41ff-a409-2b65bbe52ec9" TYPE="ext4" /dev/mapper/crozet--vg-boot: UUID="376622a1-3996-4fd4-bcd0-e7cb9a39058f" TYPE="ext2" /dev/mapper/crozet--vg-root: UUID="c80bd4b7-6979-48b6-b5f5-8806741026ac" TYPE="ext4" /dev/mapper/crozet--vg-home: UUID="996352f9-33f5-4a4e-93ff-1ec69c2c8b75" TYPE="ext4" ``` ---
**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 18, 2017, 10:22 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/37 "2017-12-18T10:22:59Z")
Tu as remis l’UUID d’origine dans fstab ? Là l’UUID spécifié pour /boot/efi dans fstab est identique à celui des partitions sda1 et sdb1, donc il ne devrait pas y avoir d’erreur. Concernant la modification de l’UUID dans fstab, j’avais écrit : > [@](#): > > 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. C’est juste pour voir comment réagit le système quand l’UUID n’est pas trouvé, pour savoir s’il faut prendre des mesures particulières comme l’option nofail ou noauto. Comme prévu, le système s’interrompt avec le shell d’urgence. Ce test n’avait pas pour objet de simuler la perte d’un disque. Avec ton clonage, si un disque manque il y aura forcément une partition avec cet UUID sur le disque restant. ---
**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 18, 2017, 2:34 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/38 "2017-12-18T14:34:38Z")
> [@](#): > > Tu as remis l’UUID d’origine dans fstab ? Oui. > [@](#): > > Là l’UUID spécifié pour /boot/efi dans fstab est identique à celui des partitions sda1 et sdb1, donc il ne devrait pas y avoir d’erreur. Dans cette configuration, il n’y en a pas. Comme j’ai ajouté `noauto` il n’y en a pas non plus si je modifie l’UUID dans `/etc/fstab`, et bien sûr, la partition n’est pas montée sur `/boot/efi`. > [@](#): > > C’est juste pour voir comment réagit le système quand l’UUID n’est pas trouvé, pour savoir s’il faut prendre des mesures particulières comme l’option nofail ou noauto. Je n’avais pas compris, mais maintenant, c’est clair. > [@](#): > > Avec ton clonage, si un disque manque il y aura forcément une partition avec cet UUID sur le disque restant. Oui, `blkid` confirme que les UUID sda1 et sdb1 sont identiques (même si c’est pas bien). Je ferai l’essai avec `nofail`. Je suis en train de configurer exim4 car j’aimerais reçevoir par mail un message d’alerte en cas de panne. ---
**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 18, 2017, 2:39 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/39 "2017-12-18T14:39:02Z")
Dans cette configuration où l’UUID est présent sur les deux disques, je ne vois pas ce que nofail t’apportera. ---
**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 18, 2017, 4:47 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/40 "2017-12-18T16:47:20Z")
Enlever `noauto`, le remplacer par `nofail`, et configurer un MTA me semble l’idéal, car : - La partition système EFI en cas de reboot est montée, même en cas de panne d’un disque ; - Si un disque est défaillant, mdadm m’envoie un courrier dans ma boîte mail. ---
**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 18, 2017, 5:05 UTC](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275/41 "2017-12-18T17:05:40Z")
Tu auras ce résultat aussi sans nofail. [Page précédente](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275.md?page=1) [Page suivante](https://www.debian-fr.org/t/installation-crash-grub-install-en-raid1/75275.md?page=3)