Re: SSD en Raid 1

Le 15/12/2018 à 04:59, Christophe PEREZ a écrit :

La difficulté que j'ai, vient du fait que cette configuration m'est
inconnue, et que je ne sais pas traiter le cas de l'installation de grub
(legacy) dans le MBR dans ce contexte.

A ma connaissance, GRUB legacy (GRUB 1) ne gère pas le RAID logiciel.
Pourquoi ne pas utiliser GRUB 2 ?

Le 15/12/2018 à 04:59, Christophe PEREZ a écrit :

(redirigé puisque la suite n'a vraiment plus à sa place sur
fr.comp.sys.pc)

Le dimanche 8 juillet 2018 09:15:55 UTC-4, Pascal Hambourg a écrit :

fdisk /dev/mdX
Les partitions seront nommées /dev/mdXpY.

Une difficulté peut apparaître lors de l'installation si l'outil de
partitionnement de l'installateur ne permet pas de partitionner (créer
une table de partition sur) un ensemble RAID.

La difficulté que j'ai, vient du fait que cette configuration m'est
inconnue, et que je ne sais pas traiter le cas de l'installation de grub
(legacy) dans le MBR dans ce contexte.

hd0, hd1, hd2 sont mes 3 HD (dont 2 en raid 1, chacun ayant grub dans le
MBR)
hd3, et hd4 sont mes 2 SSD en raid 1.
md0 est l'ensemble raid, créé par l'association des partitions sdd1 et
sde1 utilisant chacune la totalité du disque.
ma partition /boot est donc sur md0p1
la racine / est sur md0p2

J'ai donc un grub.conf du style :
title Gentoo
root (hd0,0)
kernel /boot/kernel root=/dev/md0p2

J'ai pensé faire (pour chaque SSD, donc hd3 et hd4) :
# grub --no-floppy
grub> root (hd3,0)
Filesystem type unknown, partition type 0xfd

grub> setup (hd3)

Error 17: Cannot mount selected partition

et en faisant

grub> setup (hd3,0) ?



--
François Patte
Université Paris Descartes

Le Sat, 15 Dec 2018 09:08:33 +0100, Pascal Hambourg a écrit :

A ma connaissance, GRUB legacy (GRUB 1) ne gère pas le RAID logiciel.

C'est pourtant ce que j'ai actuellement. Grub legacy ET raid logiciel.
Et puis, dans mon cas, il n'a rien de spécial à gérer. Je le mets sur
chacun des disques, et quand un lâche, je boote avec l'autre.
La particularité ici, c'est qu'il ne reconnait pas (si j'ai bien compris)
md0p1, et donc n'y voit pas son stage1, donc le refus du setup.

Le Sat, 15 Dec 2018 10:05:28 +0100, François Patte a écrit :

et en faisant

grub> setup (hd3,0) ?

Pareil :

grub> setup (hd3,0)

Error 17: Cannot mount selected partition

Le 15/12/2018 à 22:59, Christophe PEREZ a écrit :

Le Sat, 15 Dec 2018 09:08:33 +0100, Pascal Hambourg a écrit :

A ma connaissance, GRUB legacy (GRUB 1) ne gère pas le RAID logiciel.

C'est pourtant ce que j'ai actuellement. Grub legacy ET raid logiciel.

Je soupçonne qu'il marche seulement avec du RAID 1 (mirroring) non
partitionné avec superbloc 0.90 ou 1.0 à la fin de la partition, qu'il
traite comme une partition sans RAID.

Le Sun, 16 Dec 2018 00:12:10 +0100, Pascal Hambourg a écrit :

Je soupçonne qu'il marche seulement avec du RAID 1 (mirroring) non
partitionné avec superbloc 0.90 ou 1.0 à la fin de la partition, qu'il
traite comme une partition sans RAID.

Du coup, ce que j'ai fait :
- raid avec les 2 disques non partitionnés
- création des partitions sur /dev/md0
- installation grub (comme je le fais actuellement) par :

# grub --no-floppy

grub> find /grub/stage1
(hd0,0)
(hd1,0)
(hd3,0) <= cette fois-ci il les voit, alors qu'il ne les voyait
(hd4,0) <= pas dans le cas précédent

grub> device (hd0) /dev/sdd
grub> root (hd0,0)
grub> setup (hd0)

grub> device (hd0) /dev/sde
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

tu me diras si tu y vois quelque chose d'anormal/choquant.

Sachant qu'à la création du raid, suite à un warning justement pour le
boot loader, j'avais rajouté -metadata=0.90 à la commande qui devenait :
mdadm --create /dev/md0 --level=1 --raid-devices=2 --metadata=0.90 /dev/
sdd /dev/sde

Note que je l'avais aussi rajouté lorsque j'avais monté le raid avec /dev/
sd[de]1.

Je stopperai tout Lundi pour faire les transferts de données et tester le
reboot sur SSD.

Le 16/12/2018 à 00:51, Christophe PEREZ a écrit :

Le Sun, 16 Dec 2018 00:12:10 +0100, Pascal Hambourg a écrit :

Je soupçonne qu'il marche seulement avec du RAID 1 (mirroring) non
partitionné avec superbloc 0.90 ou 1.0 à la fin de la partition, qu'il
traite comme une partition sans RAID.

Du coup, ce que j'ai fait :
- raid avec les 2 disques non partitionnés
- création des partitions sur /dev/md0
- installation grub (comme je le fais actuellement) par :

# grub --no-floppy

grub> find /grub/stage1
(hd0,0)
(hd1,0)
(hd3,0) <= cette fois-ci il les voit, alors qu'il ne les voyait
(hd4,0) <= pas dans le cas précédent

Qu'est-censée "voir" cette commande exactement ? Il y a si longtemps que
j'ai abandonné GRUB legacy en faveur de GRUB 2 que j'ai un peu oublié.

grub> device (hd0) /dev/sdd
grub> root (hd0,0)
grub> setup (hd0)

grub> device (hd0) /dev/sde
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

tu me diras si tu y vois quelque chose d'anormal/choquant.

Sachant qu'à la création du raid, suite à un warning justement pour le
boot loader, j'avais rajouté -metadata=0.90 à la commande qui devenait :
mdadm --create /dev/md0 --level=1 --raid-devices=2 --metadata=0.90 /dev/
sdd /dev/sde

Ce qui me déplaît, c'est qu'avec cette méthode GRUB traite les deux
disques comme des disques indépendants et non comme membres d'un
ensemble RAID, et donc avec des partitions directement sur les disques
au lieu d'une partition dans le RAID. Et il n'y a pas que GRUB : avec un
superbloc à la fin, le noyau aussi risque de s'y perdre. Si les pilotes
md du noyau ne sont pas compilés en dur ou si l'autodétection RAID
(obsolète) n'est pas activée, au démarrage le noyau commencera pas voir
deux tables de partitions indépendantes et deux partitions avec les
mêmes UUID, ce qui peut passablement perturber la détection des systèmes
de fichiers via libblkid.

D'autre part, le format 0.90 et l'autodétection RAID par le noyau sont
obsolètes. Je ne sais pas ce qu'il en est pour Gentoo, mais dans la
plupart des distributions précompilées "modernes", les pilotes md sont
en modules et sont chargés dans l'initramfs. Il y a donc une phase
initiale où le noyau ne voit que des disques et des partitions
indépendants. En cas de problème avec l'assemblage du RAID, la situation
peut rester ainsi et une des partitions être montée hors RAID, faisant
perdre la redondance et la synchronisation avec l'autre partition.

Le superbloc RAID à la fin laisse toujours planer une triple ambiguïté
entre un disque ou une partition sans RAID, un disque entier RAID ou une
partition RAID. J'ai déjà vu plusieurs cas où le système se trompait. Au
contraire un superbloc au début ne laisse aucune ambiguïté. Je comprends
que GRUB legacy exploite cette ambiguïté pour faire comme s'il n'y avait
pas de RAID.

Au final, tu utilises une grosse bidouille pas propre et d'une fiabilité
douteuse au lieu de remplacer GRUB legacy par GRUB 2. Pourquoi ne
veux-tu pas utiliser GRUB 2 et le format de superbloc 1.x ?

Note que je l'avais aussi rajouté lorsque j'avais monté le raid avec /dev/
sd[de]1.

Mais il y avait une table de partition au début des partitions RAID, ce
que GRUB legacy ne doit pas savoir gérer. Il s'attendait à y trouver
directement un système de fichiers.

[Bizarrement, cet article posté ce matin ne semble pas avoir été diffusé
sur le serveur de news de Free depuis lequel tu postes, donc je le
reposte là avec le même Message-ID]

Le 16/12/2018 à 00:51, Christophe PEREZ a écrit :

Le Sun, 16 Dec 2018 00:12:10 +0100, Pascal Hambourg a écrit :

Je soupçonne qu'il marche seulement avec du RAID 1 (mirroring) non
partitionné avec superbloc 0.90 ou 1.0 à la fin de la partition, qu'il
traite comme une partition sans RAID.

Du coup, ce que j'ai fait :
- raid avec les 2 disques non partitionnés
- création des partitions sur /dev/md0
- installation grub (comme je le fais actuellement) par :

# grub --no-floppy

grub> find /grub/stage1
(hd0,0)
(hd1,0)
(hd3,0) <= cette fois-ci il les voit, alors qu'il ne les voyait
(hd4,0) <= pas dans le cas précédent

Qu'est-censée "voir" cette commande exactement ? Il y a si longtemps que
j'ai abandonné GRUB legacy en faveur de GRUB 2 que j'ai un peu oublié.

grub> device (hd0) /dev/sdd
grub> root (hd0,0)
grub> setup (hd0)

grub> device (hd0) /dev/sde
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

tu me diras si tu y vois quelque chose d'anormal/choquant.

Sachant qu'à la création du raid, suite à un warning justement pour le
boot loader, j'avais rajouté -metadata=0.90 à la commande qui devenait :
mdadm --create /dev/md0 --level=1 --raid-devices=2 --metadata=0.90 /dev/
sdd /dev/sde

Ce qui me déplaît, c'est qu'avec cette méthode GRUB traite les deux
disques comme des disques indépendants et non comme membres d'un
ensemble RAID, et donc avec des partitions directement sur les disques
au lieu d'une partition dans le RAID. Et il n'y a pas que GRUB : avec un
superbloc à la fin, le noyau aussi risque de s'y perdre. Si les pilotes
md du noyau ne sont pas compilés en dur ou si l'autodétection RAID
(obsolète) n'est pas activée, au démarrage le noyau commencera pas voir
deux tables de partitions indépendantes et deux partitions avec les
mêmes UUID, ce qui peut passablement perturber la détection des systèmes
de fichiers via libblkid.

D'autre part, le format 0.90 et l'autodétection RAID par le noyau sont
obsolètes. Je ne sais pas ce qu'il en est pour Gentoo, mais dans la
plupart des distributions précompilées "modernes", les pilotes md sont
en modules et sont chargés dans l'initramfs. Il y a donc une phase
initiale où le noyau ne voit que des disques et des partitions
indépendants. En cas de problème avec l'assemblage du RAID, la situation
peut rester ainsi et une des partitions être montée hors RAID, faisant
perdre la redondance et la synchronisation avec l'autre partition.

Le superbloc RAID à la fin laisse toujours planer une triple ambiguïté
entre un disque ou une partition sans RAID, un disque entier RAID ou une
partition RAID. J'ai déjà vu plusieurs cas où le système se trompait. Au
contraire un superbloc au début ne laisse aucune ambiguïté. Je comprends
que GRUB legacy exploite cette ambiguïté pour faire comme s'il n'y avait
pas de RAID.

Au final, tu utilises une grosse bidouille pas propre et d'une fiabilité
douteuse au lieu de remplacer GRUB legacy par GRUB 2. Pourquoi ne
veux-tu pas utiliser GRUB 2 et le format de superbloc 1.x ?

Note que je l'avais aussi rajouté lorsque j'avais monté le raid avec /dev/
sd[de]1.

Mais il y avait une table de partition au début des partitions RAID, ce
que GRUB legacy ne doit pas savoir gérer. Il s'attendait à y trouver
directement un système de fichiers.

Le Sun, 16 Dec 2018 20:40:09 +0100, Pascal Hambourg a écrit :

[Bizarrement, cet article posté ce matin ne semble pas avoir été diffusé
sur le serveur de news de Free depuis lequel tu postes, donc je le
reposte là avec le même Message-ID]

Ah

Qu'est-censée "voir" cette commande exactement ? Il y a si longtemps que
j'ai abandonné GRUB legacy en faveur de GRUB 2 que j'ai un peu oublié.

A priori, si j'ai bien compris, juste détecter les disques sur lesquels
il repère une partition avec son stage1

Ce qui me déplaît, c'est qu'avec cette méthode GRUB traite les deux
disques comme des disques indépendants et non comme membres d'un
ensemble RAID, et donc avec des partitions directement sur les disques
au lieu d'une partition dans le RAID.

Je comprends très bien tout ça.

Et il n'y a pas que GRUB : avec un
superbloc à la fin, le noyau aussi risque de s'y perdre. Si les pilotes
md du noyau ne sont pas compilés en dur

Ce qui n'est pas le cas chez moi. Tous les modules nécessaires sont en
dur.

ou si l'autodétection RAID
(obsolète) n'est pas activée, au démarrage le noyau commencera pas voir
deux tables de partitions indépendantes et deux partitions avec les
mêmes UUID, ce qui peut passablement perturber la détection des systèmes
de fichiers via libblkid.

Je n'ai jusque là jamais eu de problème avec mon raid actuel. J'ai les 2
disques originels qui ont lâché chacun à leur tour, et à chaque fois,
j'ai pu tourner sur le raid dégradé sans problème, pour ensuite remplacer
le disque HS, et reconstruire mon raid, et pouvoir fonctionner
normalement.
Je sais bien que je ne suis pas le cas général, mais si dans mon cas
particulier ça passe, ça me convient bien.

D'autre part, le format 0.90 et l'autodétection RAID par le noyau sont
obsolètes. Je ne sais pas ce qu'il en est pour Gentoo, mais dans la
plupart des distributions précompilées "modernes", les pilotes md sont
en modules et sont chargés dans l'initramfs.

Sous gentoo, tu peux faire générer générer la compilation de noyau à
partir de choix généraux (genkernel), ou comme moi, compiler à la main,
et donc choisir exactement ce que tu mets dedans et comment. Donc chez
moi, quasiment rien en module, et pas d'initramfs.
# lsmod
Module Size Used by
vboxpci 24576 0
vboxnetadp 28672 0
vboxnetflt 32768 0
vboxdrv 413696 3 vboxpci,vboxnetadp,vboxnetflt
w83627ehf 40960 0
hwmon_vid 16384 1 w83627ehf
i2c_i801 24576 0
coretemp 16384 0
hwmon 20480 2 coretemp,w83627ehf

Juste les modules virtualbox qui sont hors noyau, et les modules à
charger pour sensors, sinon l'initrd gueule.

[...]

Au final, tu utilises une grosse bidouille pas propre et d'une fiabilité
douteuse au lieu de remplacer GRUB legacy par GRUB 2. Pourquoi ne
veux-tu pas utiliser GRUB 2 et le format de superbloc 1.x ?

Tout simplement parce que Grub2, je ne maitrise pas, je ne parviens pas à
faire ce que je veux avec, et que je trouve que c'est une usine à gaz. Je
l'ai mis sur 2 machines, et c'est compliqué à chaque changement de noyau,
alors qu'avec grub legacy, c'est transparent. C'est compliqué pour
rajouter un softlevel, si ce n'est en créant et maintenant soit même un /
etc/grub.d/40_custom et qui rend tout le reste inule et lourd pour rien.

Quand au superbloc 1.x, je n'en sais strictement rien. Je me suis
retrouvé au début de mon raid actuel avec un 0.90, sans savoir pourquoi.
Et là, le warning m'ayant proposé cette option, je l'ai utilisée.

Note que je l'avais aussi rajouté lorsque j'avais monté le raid avec
/dev/
sd[de]1.

Mais il y avait une table de partition au début des partitions RAID, ce
que GRUB legacy ne doit pas savoir gérer. Il s'attendait à y trouver
directement un système de fichiers.

Oui, voilà. Et je n'ai pas trouvé s'il y avait un moyen de contourner.

Le Sun, 16 Dec 2018 21:57:33 +0000, Christophe PEREZ a écrit :

Tout simplement parce que Grub2, je ne maitrise pas, je ne parviens pas
à faire ce que je veux avec, et que je trouve que c'est une usine à gaz.

Ne parvenant à rien dans aucun des types de construction que j'ai tenté,
j'ai installé Grub2, mais malgré tout, je ne parviens pas à booter sur ce
raid SSD.

Avant l'installation de Grub2, j'ai essayé de me mettre dans la même
configuration que j'ai avec mon raid actuel, c'est à dire :
- partionnement de chaque disque
- association d'autant de raids

Et je ne suis jamais parvenu à booter sur ces SSD, depuis le bootloader
installé sur le raid actuel (cad /sd[ab]).
Et comme, à ma grande surprise, je ne trouve aucun moyen dans le bios de
choisir sur quel disque booter (Bios Phoenix Cme Firstbios Pro) ce n'est
même pas encore un problème d'installation du bootloader sur les SSD.

J'ai systématiquement un Kernel Panic - not syncing: VFS: Unable to mount
root fs on unknown-block(0,0).

J'ai donc installé Grub2 en parallèle de grub legacy (pour ne surtout pas
flinguer mon booter loader et ne plus pouvoir booter du tout), et je
tente la manip par un "chainage" comme indiqué ici <https://
wiki.gentoo.org/wiki/GRUB2_Migration/
fr#Charger_en_cha.C3.AEne_GRUB2_depuis_GRUB_Legacy_pour_v.C3.A9rifier_la_configuration>
Et j'ai le même résultat.
Mais ici, c'est peut-être lié, comme je pense l'avoir compris, à la façon
de construire ce raid.

Alors, je voudrais bien repartir sur la base d'une partition totale,
montée en raid, et ce raid partitionné (comme au début) et le faire booter
avec Grub2, mais je maîtrise tellement mal Grub2, que je ne sais pas
comment je vais devoir traiter l'affaire.
Je l'installe où ? /dev/sd[de] ? /dev/md0 ?
Et comment je génère mon grub.cfg vu que le grub-mkconfig ne repère pas
(en tout cas pour l'instant) même pas l'OS sur ce raid.

J'avoue que j'ai complètement tourné en rond toute la journée sans voir
le début d'une piste.