Vous n'êtes pas identifié(e).
Hors ligne
Cela devrait afficher le menu de GRUB.
Si tu arrives à démarrer le système, compare l'UUID LVM avec ceux affichés par
Dernière modification par raleur (10-07-2020 13:54:18)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par theuma (10-07-2020 13:57:21)
Hors ligne
Dernière modification par theuma (10-07-2020 14:09:35)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Tu peux installer le paquet bootinfoscript, exécuter la commande boot-info-script (ou vice versa)
Je te confirme le vice versa
Hors ligne
Hors ligne
Hors ligne
En tout cas tu peux réinstaller GRUB dans le MBR des trois disques avec
et comparer à nouveau le résultat de bootinfoscript, vgdisplay et lvdisplay.
Edit : je ne sais pas si on peut utiliser
je n'ai jamais essayé.
Dernière modification par raleur (10-07-2020 15:23:05)
Il vaut mieux montrer que raconter.
Hors ligne
sinon j'ai ça:
Dans le rapport de bootinfoscript ? Et c'est la seule mention du SSD ? Donc il ne semble pas prendre en compte les SSD NVMe, dommage...
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
j'ai effectivement deja fait les réinstallations de grub sur les 3 disques
Avant l'exécution de boot-info-script ? Donc c'est normal que les UUID correspondent.
Si tu redémarres maintenant, est-ce que le menu de GRUB s'affiche directement ? Sinon, quelle est la valeur de la variable $prefix ? Toujours la même qu'avant (lvmid/w5...) ?
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par raleur (10-07-2020 21:27:08)
Il vaut mieux montrer que raconter.
Hors ligne
puis je débranche le SSD
et je reboot ?
et je vois si le grub fonctionne toujours ?
Une fois ca fait
je rebranche le SSD
et le raid va faire ça reconstruction sur le ssd c'et bien ca ?
Dernière modification par theuma (10-07-2020 21:29:13)
Hors ligne
Hors ligne
la reconstruction ne me derange pas pour le moment
Mais ça use le SSD. 1 To d'écritures, ce n'est pas rien. En fait si tu voulais juste tester, il aurait été préférable de créer un ensemble RAID de petite taille afin d'accélérer la reconstruction et de limiter l'usure du SSD.
Pour les commandes, je pense qu'il vaudrait mieux faire le --remove juste après le --fail et avant de débrancher physiquement, ce serait plus propre.
Mais à ta place je commencerais par tester l'amorçage de GRUB avec chacun des disques manquant tour à tour, pour vérifier si l'amorçage est bien redondant.
Car si le BIOS n'expose qu'un seul des trois disques à GRUB, je crains que l'amorçage échoue si ce disque est déclaré défaillant.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par theuma (12-07-2020 12:19:37)
Hors ligne
Comment je peux tester le grub un à un sur les disques ? J'éteins le serveur, Je débranche un disque j'allume et je fais ca pour les 3 ?
Oui. Mais tu ne vas pas plus loin que le menu de GRUB s'il s'affiche, pour éviter la désynchronisation du disque manquant.
Si tu veux tester jusqu'au bout sans t'arrêter à GRUB, il vaudrait mieux le faire avec un RAID de petite taille pour éviter des resynchronisations gigantesques.
Petite précision sur la resynchronisation : si l'ensemble RAID a un "bitmap" et si la désynchronisation n'est pas trop importante, alors la reconstruction ne va écrire que les blocs qui ont changé au lieu de réécrire tous les blocs du membre retiré et ré-ajouté. Par défaut, seuls les ensembles RAID de plus de 100 Gio ont le bitmap activé à la création, mais il est possible de l'activer a posteriori sur un ensemble RAID plus petit avec
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par raleur (12-07-2020 16:01:53)
Il vaut mieux montrer que raconter.
Hors ligne
et là normalement votre Debian démarre, une fois que votre Debian a démarré, réinstaller les grub sur les 3 disques durs histoire d'être sur:
Mettre les 2 HDD en écriture uniquement
dans le terminal on va mettre en défaut les 2 HDD puis les enlever puis les remettre en écriture uniquement
On contrôle que ca fonctionne comme on veut avec la commande :
Et normalement on devrait voir quelque chose comme
Number. Major. Minor. RaidDevice. State
0. 259. 1. 0. active sync /dev/nvme0n1p1
1. 8 1 1 writemostly spare rebuilding /dev/sda1
2 8 17 2 writemostly spare rebuilding /dev/sdb1
et on voit bien que sda1 et sdb1 sont en writemosly
On peut également voir si la reconstruction du raid se met en place avec la commande
Ensuite pour être sur on contrôle la vitesse d'écriture:
la vitesse du nvme0n1 doit être identique à la vitesse de md0, si c'est le cas c'est que votre système (donc le raid md0) utilise bien la puissance du SSD (nvme0n1)
voilà je pense avoir résumé l'ensemble des choses qu'on a vu avec @Raleur (sachant que tout vient de lui, je ne fais que résumer)
Dernière modification par theuma (16-07-2020 14:06:38)
Hors ligne
Mettre les 3 disques dur en RAID 1 pour la redondance mais utiliser la puissance d'écriture lecture du SSD
En lecture seulement. En écriture, c'est le disque le plus lent qui limite la vitesse.
dans le terminal on va mettre en défaut les 2 HDD puis les enlever puis les remettre en écriture uniquement
Les deux premières commandes me semblent inutile : la première ne va retirer aucun disque puisqu'on ne les a pas encore déclarées faulty, et la seconde ne va pas les ajouter puisqu'ils font encore partie de l'ensemble.
Et normalement on devrais voir quelques choses comme
C'est la sortie de mdadm --detail, pas le contenu de /proc/mdstat.
PS : tu as testé l'amorçage avec chaque disque en moins ?
Il vaut mieux montrer que raconter.
Hors ligne