Debian Squeeze et GRUB 2 : pas de boot sur le 2ieme disk

Support Debian
#1

Bonjour,

J’ai installé une Debian Squeeze toute neuve comme suit:
RAID 1 pour une partition “/boot” ( sda1 et sdb1)
RAID 1 pour une partition “LVM”, avec dessus 1 volumes logique pour “/” et “/home”.

Un grand classique.

Le RAID fonctionne, si j’en crois “/proc/mdstat”.

Mais comme je suis taquin, je fais un test pour rebooter sur le 2ieme disk.
Et pan: Pas de grub, et reset en boucle.

Alors, je regarde si le 2ieme disk est bien pris en compte par Grub2 … On dirait que non.
Pas grave:

dpkg-reconfigure grub-pc

J’ajoute le 2ieme disl.

grub-install /dev/sda

grub-install /dev/sdb

Pareil: le 2ieme disk (sdb) ne BOOT pas.

Même en inversant les nappes…
Même en ajoutant le 2ieme disk dans “device.map” (obsolete peut etre)

A part cela, les 2 disks fonctionnent :slightly_smiling:

Je pense qu’il y a un bug a l’install de Debian (parce que “grub-pc” n’avait pas le 2ieme disk dans sa conf), et que je ne dois pas appliquer la bonne méthode pour rendre le 2ieme disk bootable.

Merci

A+

#2

Avantage du RAID1 : les partitions le composant sont accessibles en tant qu’unités indépendantes hors RAID.
Prend le disque d’installation debian, démarre en mode rescue et réinstalle grub-pc sur /dev/sdb1 et le MBR de /dev/sdb. Pour ne pas foirer le coup, mieux vaut ne laisser que l’actuel “deuxième disque” seul et installer sur /dev/sda? et le MBR de /dev/sda.
Ne cherche pas à recréer le RAID1 en mode rescue pour ce faire. Dans le cas où tu aurais besoin de démarrer du deuxième disque, tu n’aurais pas de RAID le premier disque étant absent.
Tu aurais en l’occurence besoin de démarrer /dev/sd?? et non pas /dev/md?.

Pour ce qui est de grub-pc alias grub2, il m’est arrivé pareille mésaventure en installant grub-pc sur usb puis test sur une autre machine ; grub2 ne se lance pas ne reconnaissant pas l’UUID de l’ancien disque interne. Je dis bien grub2 ne se lance pas et pas “debain/nulix ne se lance pas”.

Qu’en penser ?
Version “grub2 c’est le progrès” :
Ce n’est pas un défaut, c’est une fonctionnalité de grub2 qui s’attache aux UUID.

Version “grub2 est une plaie” :
grub2 réussit la prouesse de s’installer proprement puis d’être incapable de se lancer par défaut d’UUID attendu.

#3

Salut,

Insiste de ce moment où un bug grave de grub & grub-pc est signalé et tu ne pourras peut-être plus “booter” du tout :laughing:

#4

Marche po !

J’ai essayé beaucoup de méthode et aucune ne me permet de booter sur le 2ieme disk.
J’ai aussi le même problème sur mon poste actuel.
(Je testerai sur un autre poste ASAP où j’ai fait un upgrade Lenny -> Squeeze)

Même un truc brutal comme:

dd if=/dev/sda of=/dev/sdb bs=512 count=2048

ne fonctionne pas.

GRUB apparait juste le temps de faire gratter “fd0”, et puis RESET.

A+

#5

[quote]Même un truc brutal comme:

dd if=/dev/sda of=/dev/sdb bs=512 count=2048

ne fonctionne pas. [/quote]

Il n’y a pas que grub qui risque de ne pas fonctionner en s’y prenant de la sorte . Ce faisant tu forces le MBR (accessoirement pourquoi l’outrepasser par 512x2048 ?).
Le MBR conditionne le partitionnement et la reconnaissance des UUID. Ton RAID sera kaputt et les montages par UUID verront double si tu laisses les deux disques en présence.
Si les deux disques sont exactement partitionnés de la même manière,
chose plausible en matière de RAID, le mal est moindre mais nécessite toutefois réparation de /dev/sdb…

Je te le répète, lorsque tu devras démarrer le deuxième disque seul, il ne sera pas question de RAID; il faudra ajuster les UUID de grub et de /etc/fstab du “deuxième disque” en l’absence du “premier” , c’est-à-dire sans RAID.
Si tu répliques les réglages du RAID ( etc/fstab et root de grub2) sur le disque seul ça ne pourra pas marcher lorsque le RAID sera aux fraises en l’absence du “premier” disque. Il te faut faire de nouveaux réglages /etc/fstab et root de grub2 en référence au “deuxième” disque en écartant les anciens liés au RAID.

#6

Le UUID est porté par le file system, pas un disque (ni une partition).
Si le raid 1 fait un mirroir du contenu de la partition /dev/sda1 sur /dev/sdb1,
en toute logique les systèmes de fichiers sur /dev/sda1 et /dev/sdb1 devraient avoir le même UUID (ouch !)

Du coup si grub s’appuie sur les UUID,
ce ne serait pas normal s’il n’arrive pas à retrouver ses petits ?

#7

Qui porte le file system ? la partition
Qui porte la partition ? le disque

Un disque au MBR flingué ne reconnaitra pas ses partitions proprement.
En sabotant le MBR tu sabotes le disque, les partitions, le fs et l’UUID.

Pour ce qui est d’avoir la même UUID , ce n’est pas le RAID qui en est la cause mais un abus de dd. On peut tout à fait avoir un RAID1 avec un UUID différent pour chaque périphérique le composant.
Un autre UUID entre en jeu à l’heure de définir le RAID, celui de /dev/md? et pas celui de /dev/sda? et /dev/sdb?.

#8

grub-install --modules=raid /dev/sdb ??

Voir aussi la configuration de grub;cfg

Mais le mieux est d’installer grub sur une clé usb au cas ou.

#9

Je confirme aussi le “bug” sur mon poste de travail: pas de boot sur le 2ieme disk, et Reset/Hang.
J’aurai tendance a généraliser le problème.

J’aime bien les solutions du genre “grub-install /dev/sd?” , mais ca ne fonctionne pas.
Peter mes RAIDs et “resinstaller Grub” : je n’ai pas compris la manip.

Lorsque je suis en mode “Rescue”, ça me demande le disk “racine”.
Donc, je monte le RAID ( /dev/md0 et /dev/md1), et là, apparait la partition LVM “vg0-sys32” , qui est la racine.
Ensuite, je lance le shell avec “vg0-sys32” en racine.
Dans ce shell, je monte “/boot” : mount /dev/md0 /boot
[Esc] (ou exit?), et donc, retour au menu “rescue”.
Et la, un nouveau choix apparait: re-installer “grub”.

J’ai beau péter le RAID ou pas, le choix de re-installatation de “grub” ne répare rien.

Snif.

PS: j’ai la chance d’avoir une bécanne disponible pour faire ce genre de test… :wink:

#10

si tu changes la configuration et que tu fais un grub-install, encore faut-il que grub installé dans le mbr pointe vers un fichier de configuration valable, sinon ça ne fonctionne pas.

#11

Perdu …

Auto-citation

[quote]
Il te faut faire de nouveaux réglages /etc/fstab et root de grub2 en référence au “deuxième” disque en écartant les anciens liés au RAID.[/quote]

#12

Perdu …

Auto-citation

[quote]
Il te faut faire de nouveaux réglages /etc/fstab et root de grub2 en référence au “deuxième” disque en écartant les anciens liés au RAID.[/quote][/quote]

Perdu :wink:

En fait, c’est un bug dans le “graphical terminal” : c’est ça qui plante et fait rebooter le PC.

Donc, pour booter, sur le 2ieme disk, il suffit de forcer le terminal “console” en éditant le fichier : /etc/default/grub
Afin d’avoir:

GRUB_TERMINAL=console

Et puis, bien sur:
update-grub

On perd le superbe écran splash :sunglasses: , mais on y gagne en pouvant booter sur le 1er ou le 2ieme disk.

Merci pour votre aide.
A+

Source: http://www.generation-nt.com/hs-mdadm-grub2-entraide-3918941.html