[Résolu] Erreur montage Raid au démarrage

Support Debian
#1

Bonjour à tous,

J’ai un serveur de fichier avec Debian stable. Un électricien est passé chez moi pour faire des diagnostics, et a coupé/remis plusieurs fois le courant. Comme une andouille, je n’avais pas éteint mon serveur, et il ne redémarre plus correctement.

Voici ma configuration : Debian Stable, avec 4 disques de 3To montés en Raid 1.
Je vais essayer d’être clair dans la configuration des disques.

Les deux premiers disques, sda et sdb, sont partionnés de la sorte :

  • sda1 et sdb1, 1 Mo, flag bios_grub, permet de lancer grub
  • sda2 et sdb2, 100 Mo, ext3, est un Raid 1 sur /dev/md0
  • sda3 et sdb3, environ 3To, est un Raid 1 sur /dev/md1

Les deux derniers disques, sdc et sdd :

  • sdc1 et sdd1, environ 3 To, est un Raid 1 sur /dev/md2

Ensuite, /dev/md0 est monté sur /boot, tandis que /dev/md1 et /dev/md2 constituent deux Physical Volume pour un LVM d’un peu moins de 6 To.

Au démarrage, grub se lance correctement. Lorsque le système démarre, il détecte bien les raids /dev/md0 et /dev/md1, mais ne trouve pas le raid /dev/md2. Du coup, le système se plante avec un message d’erreur :

[mono]Alert! /dev/disk/by-uuid/3411db38-XXXX does not exist. Dropping to a shell![/mono]

Et j’ai la main sur une ligne de commande (initramfs).

L’UUID 3411db38-XXXX correspond au PV du raid /dev/md2.

En bootant avec sysrescuecd, il autodétecte correctement tous les raids, et la LVM se monte correctement. Tous les disques sont intacts, et les données aussi !

Visiblement, il a du se passer quelquechose lors des boots et reboots successifs qu’a fait l’électricien, mais j’avoue ne pas savoir comment faire pour que le raid /dev/md2 soit reconnu au démarrage comme il devrait.

J’ai essayé, en bootant avec un CD de debian en mode de secours de réinstaller grub sur /dev/sda et /dev/sdb, mais sans effets.

Quelqu’un saurait comment reconnaitre tous les raids au démarrage ?

Merci beaucoup

PS : Une fois que tout sera remis en ordre, je vais acheter un onduleur pour ne plus avoir ce genre de problèmes !

#2

En premier, je ferais un état des lieux depuis le shell de l’initramfs (attention clavier qwerty), l’installateur en mode “rescue” ou autre système “live”.

mdadm --examine --scan -v mdadm --examine /dev/sd*
Je suis un poil surpris que le message d’erreur mentionne l’UUID d’un PV LVM, qui est de la cuisine interne à LVM. Habituellement, ce message contient plutôt l’UUID du système de fichiers racine à monter.
Quelle est la valeur de l’option root= passée au noyau par GRUB (sélectionner la ligne du menu et taper ‘e’ pour voir le détail) ?

#3

Bonjour,

Voici les résultats des commandes.

(initramfs) mdadm --examine --scan -v
ARRAY /dev/md/0 level=raid1 metadata=1.2 num-devices=2 UUID=b27ea1b5:24d84ab3:acf20d5f:656695b0 name=sanctuaire:0
  devices=/dev/sdb2,/dev/sda2
ARRAY /dev/md/1 level=raid1 metadata=1.2 num-devices=2 UUID=74fce284:05a8644d:237224c7:de353792 name=sanctuaire:1
  devices=/dev/sdb3,/dev/sda3
ARRAY /dev/md/2 level=raid1 metadata=1.2 num-devices=2 UUID=07b4748a:9e72e17b:0f4acf6c:5900b567 name=sanctuaire:2
  devices=/dev/sdd1,/dev/sdc1

[mono]mdadm --examine /dev/sd*[/mono] donne une sortie trop longue pour être affiché sur un écran, mais en regardant successivement sur /dev/sda2, /dev/sda3 et /dev/sdc1, il y a entre autre chose à chaque fois :

State : Clean
Array state : AA

Voici toute les commandes de grub (je pense que l’option root= correspond à la ligne linux, mais dans le doute, je préfère tout mettre).

load_video insmod gzio insmod raid insmod mdraid1x insmod part_gpt insmod part_gpt insmod ext2 set root='(mduuid/b27ea1b524d84ab3acf20d5f656695b0)' search --no-floppy --fs-uuid --set=root f3bdc707-8879-456c-456c-bff9-0de739edf319 echo 'Chargement de Linux 3.2.0-4-amd64 ...' linux /vmlinuz-3.2.0-4-amd64 root=UUID=3411db38-eda6-4b17-9b53-602d8080c235 ro quiet echo 'Chargement du disque mémoire initial ...' initrd /initrd.img-3.2.0-4-amd64

Merci beaucoup,

#4

Rien à signaler dans la sortie du --scan, tous les ensembles et membres RAID sont bien détectés correctement (pas de doublon ni manquant).

J’aurais bien voulu avoir la sortie détaillée du --examine pour chaque membre. Il était possible de l’enregistrer dans un fichier (sur clé USB) pour faire quelques vérifications supplémentaires.

Je suis étonné que la racine soit identifiée par son UUID, alors qu’habituellement lorsque c’est un volume logique LVM il est identifié par son nom de volume /dev/mapper/- (c’est ainsi que l’initramfs sait qu’il s’agit d’un volume LVM et quel VG activer). En tout cas je suis formel : cela ne peut pas être l’UUID du PV contenu dans /dev/md2, qui est à l’usage interne de LVM.

Dans le shell de l’initramfs, que contient [mono]/proc/mdstat[/mono] et qu’affiche [mono]blkid[/mono] (de pertinent pour /dev/md2 et les volumes LVM) ?

#5

Voici les sorties de [mono]/proc/mdstat[/mono] et [mono]blkid[/mono] dans le shell de l’initramfs:

(initramfs) cat /proc/mdstat
Personalities : [raid1]
md1 : active (auto-read-only) raid1 sda3[0] sdb3[1]
      2930166749 blocks super 1.2 [2/2] [UU]

md0 : active (auto-read-only) raid1 sda2[0] sdb2[1]
      97644 blocks super 1.2 [2/2] [UU]

unused devices: <none>
(initramfs) blkid
/dev/sdc1: UUID="07b4748a-9e72-e17b-0f4a-cf6c5900b567" UUID_SUB="a287ac8c-02a9-5f42-25a8-55fdc3431a79" LABEL="sanctuaire:2" TYPE="linux_raid_member"
/dev/sdd1: UUID="07b4748a-9e72-e17b-0f4a-cf6c5900b567" UUID_SUB="15256570-8a8d-6c07-38c3-45b7493d3198" LABEL="sanctuaire:2" TYPE="linux_raid_member"
/dev/sdb2: UUID="b27ea1b5-24d8-4ab3-acf2-0d5f656695b0" UUID_SUB="79fec6d3-fa2b-99c2-c2ed-b3f5b7f3b218" LABEL="sanctuaire:0" TYPE="linux_raid_member"
/dev/sdb3: UUID="74fce284-05a8-644d-2372-24c7de353792" UUID_SUB="5e4f5997-2b98-4f41-5457-faa7470da407" LABEL="sanctuaire:1" TYPE="linux_raid_member"
/dev/sda2: UUID="b27ea1b5-24d8-4ab3-acf2-0d5f656695b0" UUID_SUB="9b30fa3c-ef1c-219f-71e2-087a6b668890" LABEL="sanctuaire:0" TYPE="linux_raid_member"
/dev/sda3: UUID="74fce284-05a8-644d-2372-24c7de353792" UUID_SUB="3a6deaba-31eb-0dd4-b669-7eef106ab1d5" LABEL="sanctuaire:1" TYPE="linux_raid_member"
/dev/md0: UUID="f3bdc707-8879-456c-bff9-0de739edf319" SEC_TYPE="ext2" TYPE="ext3"
/dev/md1: UUID="hBqXcB-LCfd-q2e9-6b0Y-vo80-Ejkf-9cBdUg" TYPE="LVM2_member"
/dev/mapper/pitance-swap: UUID="65d0ef2-9623-4c23-8530-a82617f2adc3" TYPE="swap"
/dev/sde1: LABEL="KINGSTON" UUID="3433-3231" TYPE="vfat"

Il me semble qu’il y a un soucis avec [mono]/dev/md2[/mono]. Mais alors, pourquoi il n’est pas monté ?..
J’ai laissé la ligne de la clef USB, car je n’arrive pas à la monter à partir du shell.
J’ai essayé de faire :

(initramfs) mkdir /tmp
(initramfs) cd /dev/disks/by-uuid/
(initramfs) mount 3433-3231 /mnt
mount: mounting 3433-3231 on /mnt failed: No such file or directory

Du coup, je n’arrive pas a récupérer le fichier ou j’ai enregistré la sortie de [mono]mdadm --examine[/mono]

Merci,

#6

Y a-t-il des messages d’erreur concernant /dev/md2 ou /dev/md/2 avant le shell de l’initramfs ?
Toujours dans le shell de l’initramfs, que contient le fichier /etc/mdadm/mdadm.conf ?
As-tu essayé de démarrer manuellement /dev/md2 avec

Il faut spécifier soit le nom de périphérique de la partition sur la clé, [mono]/dev/sde1[/mono], ou l’UUID mais sous la forme [mono]UUID=3433-3231[/mono] (pas juste 3433-3231) ou le label sous la forme [mono]LABEL=KINGSTON[/mono].

#7

Il n’y a pas de messages d’erreurs particuliers concernant /dev/md2 avant le shell.
Il y a ceci qui s’affiche :

Loading, please wait...
mdadm: /dev/md/0 has been started with 2 drives.
mdadm: /dev/md/1 has been started with 2 drives.
  Couldn't find device with uuid Jxg5V8-pJbH-3skW-0ouS-sbUv-cQihzb.

Et ensuite je tombe sur le shell.

La sortie de mdadm.conf :

(initramfs) cat /etc/mdadm/mdadm.conf
DEVICE partitions
HOMEHOST <system>
ARRAY /dev/md/0 metadata=1.2 UUID=b27ea1b5:24d84ab3:acf20d5f:656695b0 name=sanctuaire:0
ARRAY /dev/md/1 metadata=1.2 UUID=74fce284:05a8644d:237224c7:de353792 name=sanctuaire:1

Lorsque j’essaye de monter la clef USB :

(initramfs) mkdir /mnt
(initramfs) mount UUID=3433-3231 /mnt
mount: mounting /dev/sde1 on /mnt failed: No such file or directory

Par contre, la bonne nouvelle, c’est que /dev/md2 se lance correctement avec :

mdadm -v --assemble /dev/md2 /dev/sdc1 /dev/sdd1

A partir de la, [mono]vgchange -ay[/mono] permet d’activer tous les volumes LVM, et [mono]exit[/mono] permet de quitter le shell, et continuer le boot, jusqu’au login. Tout est en ordre, il n’y a aucunes pertes de données (ouf !!).

Par contre, je retombe sur le même problème en redémarrant.
Pourquoi est-ce que /dev/md2 ne s’assemble pas automatiquement ?
Que faut-il faire pour l’assembler au démarrage ?

En tout cas, merci pour tout !

#8

mdadm.conf devrait contenir une ligne pour /dev/md/2. Regarde dans /etc/mdadm.conf du LV racine pour voir si c’est pareil. Dans ce cas, il faut ajouter la ligne, obtenue à partir de la sortie de [mono]mdadm --examine --scan[/mono] et regénérer l’initramfs avec [mono]update-initramfs -u -k all[/mono].

Oublie le montage de la clé USB, cela échoue probablement parce que le module vfat n’est pas présent dans l’initramfs.

Il y a une bizarrerie que je voudrais éclaircir : la façon dont la racine est identifiée dans la ligne de commande du noyau. Une fois tous les ensembles RAID et volumes logiques LVM activés, peux-tu à nouveau fournir la sortie de [mono]blkid[/mono] (dans l’initramfs ou le système final, peu importe), ainsi que le contenu de /etc/fstab ?

#9

Vérifie aussi avec [mono]dpkg-reconfigure mdadm[/mono] quels sont les ensembles RAID activés dans l’initramfs, et ajuste si nécessaire.

#10

Merci pour ta réponse.

J’ai rajouté la ligne obtenue avec [mono]mdadm --examine --scan[/mono] et j’ai régénéré l’initramfs.
J’ai également regardé avec [mono]dpkg-reconfigure mdadm[/mono] (l’option étail [mono]all[/mono], j’ai laissé).

Au démarrage, il trouve tous les raids… avant de retomber sur le même message d’erreur :

Loading, please wait...
mdadm: /dev/md/0 has been started with 2 drives.
mdadm: /dev/md/1 has been started with 2 drives.
mdadm: /dev/md/2 has been started with 2 drives.
Gave up waiting for root devices.
[SNIP]
Alert! /dev/disk/by-uuid/3411db38-eda6-4b17-9b53-602d8080c235 does not exist. Dropping to a shell!

En regardant l’état de la LVM ([mono]lvscan -a[/mono]), le volume ‘/dev/pitance/swap’ est actif tandis que les volumes ‘/dev/pitance/root’ et ‘/dev/pitance/data’ sont inactifs.

Un [mono]vgchange -a[/mono] active le tout et permet de démarrer comme avant.

Je reste perplexe…

Le resultat de [mono]blkid[/mono] :

/dev/sdb2: UUID="b27ea1b5-24d8-4ab3-acf2-0d5f656695b0" LABEL="sanctuaire:0" TYPE="linux_raid_member" UUID_SUB="79fec6d3-fa2b-99c2-c2ed-b3f5b7f3b218" 
/dev/sdb3: UUID="74fce284-05a8-644d-2372-24c7de353792" LABEL="sanctuaire:1" TYPE="linux_raid_member" UUID_SUB="5e4f5997-2b98-4f41-5457-faa7470da407" 
/dev/sda2: UUID="b27ea1b5-24d8-4ab3-acf2-0d5f656695b0" LABEL="sanctuaire:0" TYPE="linux_raid_member" UUID_SUB="9b30fa3c-ef1c-219f-71e2-087a6b668890" 
/dev/sda3: UUID="74fce284-05a8-644d-2372-24c7de353792" LABEL="sanctuaire:1" TYPE="linux_raid_member" UUID_SUB="3a6deaba-31eb-0dd4-b669-7eef106ab1d5" 
/dev/md0: UUID="f3bdc707-8879-456c-bff9-0de739edf319" TYPE="ext3" 
/dev/md1: UUID="hBqXcB-LCfd-q2e9-6b0Y-vo80-Ejkf-9cBdUg" TYPE="LVM2_member" 
/dev/mapper/pitance-root: UUID="3411db38-eda6-4b17-9b53-602d8080c235" TYPE="ext4" 
/dev/mapper/pitance-swap: UUID="65d0e0f2-9623-4c23-8530-a82617f2adc3" TYPE="swap" 
/dev/mapper/pitance-data: UUID="9f24274e-0b60-4202-b7e8-dae52b3b16fe" TYPE="ext4" 
/dev/sdd1: UUID="07b4748a-9e72-e17b-0f4a-cf6c5900b567" UUID_SUB="15256570-8a8d-6c07-38c3-45b7493d3198" LABEL="sanctuaire:2" TYPE="linux_raid_member" 
/dev/sdc1: UUID="07b4748a-9e72-e17b-0f4a-cf6c5900b567" UUID_SUB="a287ac8c-02a9-5f42-25a8-55fdc3431a79" LABEL="sanctuaire:2" TYPE="linux_raid_member" 
/dev/sde1: LABEL="KINGSTON" UUID="3433-3231" TYPE="vfat" 
/dev/md2: UUID="Jxg5V8-pJbH-3skW-wVux-0ouS-sbUv-cQihzb" TYPE="LVM2_member"

et le fichier [mono]/etc/fstab[/mono]:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/mapper/pitance-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/md0 during installation
UUID=f3bdc707-8879-456c-bff9-0de739edf319 /boot           ext3    defaults        0       2
/dev/mapper/pitance-data /home           ext4    defaults        0       2
/dev/mapper/pitance-swap none            swap    sw              0       0
/dev/sda1       /media/usb0     auto    rw,user,noauto  0       0
/dev/sda2       /media/usb1     auto    rw,user,noauto  0       0
# Freebox NAS Server
//192.168.1.254/Disque\040dur/ /media/freebox_nas cifs password=,iocharset=utf8,uid=1000,gid=1000,umask=000,user,auto 0 4
# Montages pour NFSv4
/home/partage	/export/partage	none	bind	0	0
#11

Je m’en doutais, car j’ai obtenu le même résultat en testant sur une de mes machines.
Je pense que le problème vient de ce que la racine est spécifiée par son UUID dans la ligne de commande du noyau (paramètre root=) au lieu de son nom de volume LVM [mono]/dev/mapper/pitance-root[/mono], ce qui fait que l’initramfs ne comprend pas qu’il s’agit d’un volume LVM et ne l’active pas.

Ce que je ne comprends pas en revanche, c’est pourquoi la racine est spécifiée de cette façon dans /boot/grub/grub.cfg. Pourrais-tu régénérer ce fichier avec [mono]update-grub[/mono] et voir si cela change ?

Update-grub invoque le script [mono]grub-mkconfig[/mono] qui utilise la commande [mono]grub-probe[/mono] pour déterminer les périphériques contenant la racine, /boot… et chez moi lorsque c’est un volume LVM le résultat est le nom de la forme /dev/mapper/$VG-$LV. Le script lvm de l’initramfs utilise cette forme pour retrouver le VG et le LV à activer.

#12

OK, alors voici ce qu’il se passe avec [mono]update-grub[/mono] :

root@sanctuaire:~# update-grub
Generating grub.cfg
/usr/sbin/grub-probe : erreur : Couldn't find PV pv1. Check your device.map.
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
/usr/sbin/grub-probe : erreur : Couldn't find PV pv1. Check your device.map.
done

Au redémarrage, il y a a nouveau le même message d’erreur.

#13

[quote=“PascalHambourg”]Je m’en doutais, car j’ai obtenu le même résultat en testant sur une de mes machines.
Je pense que le problème vient de ce que la racine est spécifiée par son UUID dans la ligne de commande du noyau (paramètre root=) au lieu de son nom de volume LVM [mono]/dev/mapper/pitance-root[/mono], ce qui fait que l’initramfs ne comprend pas qu’il s’agit d’un volume LVM et ne l’active pas.[/quote]

Je viens de tester en passant [mono]root=/dev/mapper/pitance-root[/mono] au noyau au démarrage, le système démarre correctement. Il faut que je modifie grub.cfg ?

Merci

#14

OK ! J’ai résolu le problème !

En fait, l’erreur venait du fichier [mono]/boot/grub/device.map[/mono]

Il y avait :

(hd0)	/dev/disk/by-id/usb-USB2.0_Flash_Disk_AA04012700028496-0:0
(hd1)	/dev/disk/by-id/ata-ST3000DM001-9YN166_S1F08HDK
(hd2)	/dev/disk/by-id/ata-ST3000DM001-9YN166_S1F07VHD

Je l’ai remplacé par :

(hd0)	/dev/disk/by-id/ata-ST3000DM001-9YN166_S1F08HDK
(hd1)	/dev/disk/by-id/ata-ST3000DM001-1E6166_W1F42GJD
(hd2)	/dev/disk/by-id/ata-ST3000DM001-9YN166_S1F07VHD
(hd3)	/dev/disk/by-id/ata-ST3000DM001-1CH166_W1F1PSA9

Et [mono]update-grub[/mono] fonctionne correctement, et génère la bonne entrée.

En fait, le serveur avait été installé avec deux disques durs depuis une clef USB, et j’ai rajouté les deux disques supplémentaires après coup.
Pourquoi les coupures de courant ont modifiés le grub reste un mystère, mais bon… tout marche maintenant.
Et je vais investir dans un bon onduleur ! :smiley:

Merci pour ton aide !

Darckense

#15

J’avoue que je ne comprends pas trop l’influence du fichier device.map dans cette histoire. D’ailleurs il n’est plus forcément utile car grub comprend les UUID. Une chose est sûre : ce ne sont pas les coupures de courant qui ont modifié la configuration de démarrage.

PS : modifier le fichier grub.cfg n’aurait pas été une bonne idée dans la durée car ce fichier et regénéré à chaque exécution d’update-grub (notamment lors de l’installation ou de la mise à jour d’un noyau).