Installation : crash grub-install en RAID1

Support Debian
, ,
Tags: #<Tag:0x00007f63f4559330> #<Tag:0x00007f63f45591a0> #<Tag:0x00007f63f4558f48>
#22

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.

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.

Ç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.

#23

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.

#24

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.

#25

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 !!

#26

C’est quoi, “une carte mère supportant le RAID matériel” ?

#27

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

#28

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 sont effectivement équipées de composants électroniques (lien vers le datasheet) qui gèrent (en interne) de façon électronique les calculs de parité et autres calculs nécessaires pour certains modes RAID

#29

Oui, plutôt.

C’est ce qu’il me semblait, d’où ma question.

#30

D’après les liens de @MicP, ç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.

#31

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=<uuid_sda1>  /boot/efi       vfat    umask=0077      0       1
UUID=<uudi_sdb1>  /boot/efi2       vfat    umask=0077      0       1
#32

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.

#33

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.

#34

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…

#35

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.

#36

OK.
Le contenu de fstab :

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/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"
#37

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 :

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.

#38

Oui.

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.

Je n’avais pas compris, mais maintenant, c’est clair.

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.

#39

Dans cette configuration où l’UUID est présent sur les deux disques, je ne vois pas ce que nofail t’apportera.

#40

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

Tu auras ce résultat aussi sans nofail.