grub2 et raid1
Le
François Boisson
Bonjour,
Je viens de récupérer un serveur (OVH) qui a eu un souci de disque. Celui ci a
été remplacé. Voilà la situation
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
[multipath] [faulty] md1 : active raid1 sdb1[0] sda1[1]
307198912 blocks [2/2] [UU]
md2 : active raid1 sdb2[0] sda2[1]
102398912 blocks [2/2] [UU]
md3 : active raid1 sdb3[0] sda3[1]
271770560 blocks [2/2] [UU]
md5 : active raid1 sdb5[0] sda5[1]
46078848 blocks [2/2] [UU]
La racine est /dev/md1. Le disque mort était (ou est devenu) /dev/sdb. La
machine ne démarrait plus sur le disque dur. En démraant sur un noyau OVH,
1) J'ai refait le RAID1 (en clair repartitionné et reintégré sdb1, sdb2, sdb3
et sdb5 dans les md correspondant). Celui ci est opérationnel comme le montre
ce qui précède.
Le fichier mdadm.co,f a été refait via /usr/share/mdadm/mkconf
2) J'ai fait
grub-mkdevicemap
grub-install "(hd0)"
grub-install "(hd1)"
# cat /boot/grub/device.map donne
(hd0) /dev/disk/by-id/ata-ST3750525AS_5VP7WBDR
(hd1) /dev/disk/by-id/ata-ST3750528AS_6VPDCZQJ
et les deux grub-install renvoient
Installation finished. No error reported.
3) Puis je termine par un
update-grub
qui ne signale aucune erreur.
Dans le grub.cfg, on retrouve bien
insmod diskfilter
insmod mdraid09
ainsi que
set root='mduuid/db60a4b7487d052ba4d2adc226fd5302'
(c'est bien l'UUID de /dev/md1)
et
linux /boot/vmlinuz-3.5.0-34-generic root=/dev/md1
Bref je ne vois pas d'erreurs là dedans.
4) Un update-initramfs -u donne
cryptsetup: WARNING: failed to detect canonical device of /dev/md1
cryptsetup: WARNING: could not determine root device from /etc/fstab
bien que
********* /etc/fstab *************
<file system> <mount point> <type> <options> <dump> <pass>
/dev/md1 / ext3 errors=remount-ro,relatime 0 1
/dev/md2 /home ext3 defaults,relatime 1 2
/dev/md3 /var ext3 defaults,relatime 1 2
/dev/md5 /sauvegarde ext3 defaults,relatime 1 2
/dev/sda6 swap swap defaults 0 0
/dev/sdb6 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
dev /dev devtmpfs rw 0 0
et que rien n'est crypté.
Avec tout ça rien à faire pour bouter la machine elle même. Le système
boute sur le noyau OVH en déclarant la racine sur /dev/md1 mais impossible
de bouter sur le noyau local. Je ne peux évidemment pas voir si ça coince
au niveau de grub (grub2 2.00-7) ou de l'initramfs.
Je n'ai pas beaucoup d'expérience sur les RAID1 logiciels, quelqu'un aurait-il
une indication ou un doc un peu précise sur la configuration
RAID1 sans LVM + grub2 avec racine sur /dev/md1 (pas de
/dev/md0 je ne sais pas pourquoi, oubli à la création je pense).
Merci d'avoir lu
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20131030174321.e4a3a7447c5b66ba50e597ce@maison.homelinux.net
Je viens de récupérer un serveur (OVH) qui a eu un souci de disque. Celui ci a
été remplacé. Voilà la situation
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
[multipath] [faulty] md1 : active raid1 sdb1[0] sda1[1]
307198912 blocks [2/2] [UU]
md2 : active raid1 sdb2[0] sda2[1]
102398912 blocks [2/2] [UU]
md3 : active raid1 sdb3[0] sda3[1]
271770560 blocks [2/2] [UU]
md5 : active raid1 sdb5[0] sda5[1]
46078848 blocks [2/2] [UU]
La racine est /dev/md1. Le disque mort était (ou est devenu) /dev/sdb. La
machine ne démarrait plus sur le disque dur. En démraant sur un noyau OVH,
1) J'ai refait le RAID1 (en clair repartitionné et reintégré sdb1, sdb2, sdb3
et sdb5 dans les md correspondant). Celui ci est opérationnel comme le montre
ce qui précède.
Le fichier mdadm.co,f a été refait via /usr/share/mdadm/mkconf
2) J'ai fait
grub-mkdevicemap
grub-install "(hd0)"
grub-install "(hd1)"
# cat /boot/grub/device.map donne
(hd0) /dev/disk/by-id/ata-ST3750525AS_5VP7WBDR
(hd1) /dev/disk/by-id/ata-ST3750528AS_6VPDCZQJ
et les deux grub-install renvoient
Installation finished. No error reported.
3) Puis je termine par un
update-grub
qui ne signale aucune erreur.
Dans le grub.cfg, on retrouve bien
insmod diskfilter
insmod mdraid09
ainsi que
set root='mduuid/db60a4b7487d052ba4d2adc226fd5302'
(c'est bien l'UUID de /dev/md1)
et
linux /boot/vmlinuz-3.5.0-34-generic root=/dev/md1
Bref je ne vois pas d'erreurs là dedans.
4) Un update-initramfs -u donne
cryptsetup: WARNING: failed to detect canonical device of /dev/md1
cryptsetup: WARNING: could not determine root device from /etc/fstab
bien que
********* /etc/fstab *************
<file system> <mount point> <type> <options> <dump> <pass>
/dev/md1 / ext3 errors=remount-ro,relatime 0 1
/dev/md2 /home ext3 defaults,relatime 1 2
/dev/md3 /var ext3 defaults,relatime 1 2
/dev/md5 /sauvegarde ext3 defaults,relatime 1 2
/dev/sda6 swap swap defaults 0 0
/dev/sdb6 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
dev /dev devtmpfs rw 0 0
et que rien n'est crypté.
Avec tout ça rien à faire pour bouter la machine elle même. Le système
boute sur le noyau OVH en déclarant la racine sur /dev/md1 mais impossible
de bouter sur le noyau local. Je ne peux évidemment pas voir si ça coince
au niveau de grub (grub2 2.00-7) ou de l'initramfs.
Je n'ai pas beaucoup d'expérience sur les RAID1 logiciels, quelqu'un aurait-il
une indication ou un doc un peu précise sur la configuration
RAID1 sans LVM + grub2 avec racine sur /dev/md1 (pas de
/dev/md0 je ne sais pas pourquoi, oubli à la création je pense).
Merci d'avoir lu
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20131030174321.e4a3a7447c5b66ba50e597ce@maison.homelinux.net
Pas dâexpérience avec les VM dâOVH.
Niveau RAID logiciel, « chez moi ça marche⦠ou pres que »⢠donc
que des petits soucis et pas eu besoin de plus de connaissances
que celles de https://raid.wiki.kernel.org/ .
Donc juste pour que tu te sentes moins seul dans ton fil ;o)
Note sur lâabsence de /dev/md0 : sâil existait quand les
autres ont été créés mais a disparu après, les numéros sont
conservés.
Au passage : on peut installer le Grub directement sur le
/dev/md. Sais pas si ça fait une vraie différence avec
lâinstallation sur chacune des partitions (c.-Ã -d. y a-t-i l un
décalage ?) mais ça marche bien.
Le mercredi 30 octobre 2013 17:49:22 François Boisson a écrit :
Es-tu sûr que ça ne coince pas après ?
(P.ex, As-tu essayé dâajouter des écritures dans un f ichier dans
quelques fichiers dâinit pour voir quand ça coince ?)
--
Sylvain Sauvage
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
- Question bete mais as tu pensé a changer le Netboot sur Hd de ton
manager ?
- Un dmesg devrait te sortir toutes les erreurs du boot kernel local
Le 10/30/2013 05:49 PM, François Boisson a écrit :
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Johnny B
Oui
Ben non, le dmesg ne sort que les erreurs du dernier boot donc du boot sur le
noyau OVH.
J'ai cherché dans les logs une trace de boot sur le noyau local, je n'ai rien
vu. Cela signifie que init n'est pas atteint lors du boot local, c'est donc
soit grub, soit l'initramfs.
Merci de ta réponse, ça précise les choses
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
"Sylvain L. Sauvage"
Bon, ça fait une lecture
C'est sur que ça ne spamme pas :-)
J'avais vu, je vais essayé éventuellement. Le pbm est que le serveur est en
production, j'hésite à le couper durant la journée (Il a 400000 hits/jour et
11000 mails par jour en moyenne, j'ignore si c'est considéré comme un gros
serveur ou pas mais ça m'ennuie de le rendre indisponible pendant la journée).
Je n'ai vu aucune entrée relative au noyau local dans le syslog, cela signifie
que la racine n'est pas montée en écriture et que sans doute init n'est pas
lancé ou s'arrête très vite. Comme l'init fonctionne bien avec un noyau
externe, j'en ai déduit le souci au niveau de l'initramfs ou du grub.
J'attends un peu mais si personne n'a d'idée et si les docs que je lis ne
m'apporte rien je vais essayer de reproduire le pbm avec deux clefs USB en
RAID1 (ça aura le mérite de m'amuser), ou éventuellement de modifier
l'initramfs à la main pour tracer le boute si il arrive jusque là.
Merci de ta réponse, je me sens moins seul...
François
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Sachant que tu es chez OVH avec une telle quantité de requêtes tu as
donc un dédié. (GTR/SLA)
Le support peut au moins te fournir les erreurs de boot
Pour info OVH je n'aime pas du tout le raid soft ovh sans LVM2 (j'en ai
un ;), /dev/md0 n'est pas présent car c'est une façon de monter ses
arrays. La plupart du temps on assemble tous les volumes sous /dev/md0.
C'est un choix d'ovh dissocier les volumes raid en /dev/md1 md2 etc..
Le 10/31/2013 09:45 AM, François Boisson a écrit :
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Johnny B
Oui
Ah, ça c'est bon à savoir...
Ça explique pourquoi je n'ai pas de /dev/md0.
Cela dit, j'ai installé deux clefs USB en raid1 (tout sur /dev/md0), grub sur
les deux clefs et ça coince au niveau de l'initramfs, je suis en train de
décortiquer ça. Encore une ou deux journées et je deviendrais béton sur les
raid1 logiciels...
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
François Boisson a écrit :
Ah ? Alors tu m'expliqueras, parce que pour ma part je n'ai strictement
rien compris à ce paragraphe.
Ça coince comment exactement ? Il faut peut-être introduire une option
rootdelay=N.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
mérite de prendre le temps de relire, ou d'appeler l'académie française
(entre Pascal Hambourg est moi il y a un contentieux historique sur la
compréhension des choses :p )
Le 10/31/2013 02:05 PM, Pascal Hambourg a écrit :
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
François Boisson
Bon, avec les deux clefs, je constate deux choses:
1) L'installateur ne met pas à jour /etc/initramfs-tools/modules
Il faut lui rajouter le module nécessaire pour monter le raid (raid1 chez moi
donc)
2) Le montage du raid échoue si on rajoute le module. Mais ici ça n'est qu'une
question de délai, il faut le temps que les clefs USB soient découvertes donc
un délai de 5-10s avant de monter le raid. Cela ne doit pas être le cas sur le
serveur OVH.
Bilan: si je rajoute raid1 dans /etc/initramfs-tools/modules (qui manquait
effectivement) et que je refais l'initrd, ça devrait marcher. Etonnant qu'une
telle erreur subsiste dans l'installateur.
Je fais le test ce soir.
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Pascal Hambourg
Salut Pascal
J'ai compris que l'absence de /dev/md0 (souvent lui même partitionné
apparemment) et l'existence de /dev/md${i} correspondant pour chaque $i à un
RAID1 sur /dev/sda${i} et /dev/sdb${i} venait de la méthode d'installation
d'OVH et non à une bizarrerie de la personne s'occupant précédemment du
serveur.
Mais je sais que tu aimes beaucoup que les choses soient très précisemment
dites (ou écrites plutôt ici, voire même tapées en fait :-) ).
Je pense qu'OVH a une méthode de transformation d'une installation existante
sur un disque en une installation sur un RAID1 avec un disque miroir via un
script, ça ne doit pas être trop dur à faire.
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/