[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: grub 2 & kernel 2.6.30



FR a écrit :
> Le jeudi 17 septembre 2009 12:26:16, pingouin osmolateur a écrit :
>> Bonjour
>> Bon je ne suis pas plus avancé :-(
>>
>> J'ai fait un ls et j'obtiens
>>  (hd0) (hd0,2) (hd0,1) (fd0)
>>
>> Mais ce que je ne comprends pas c'est qui si mon système est partitionnée
>>  comme suit : /dev/sda1 -> /boot
>> /dev/sda2 -> logical group
>> /dev/hoth/home
>> /dev/hoth/root
>> /dev/hoth/swap1
>> /dev/hoth/tmp
>> /dev/hoth/usr
>> /dev/hoth/var
>>
>> Je devrai avoir
>> prefix=(hd0,1)/grub ça ok
>> root=hd0,2 non ? ou un truc du genre root=/dev/mapper/vg00-lv01 ?

Tu devrais avoir (hd0,2)/dev/mapper/blablabla j'imagine (je n'utilise
pas de lvm).

> 
> Attention, dans grub, le set root est le root de grub (ie l'endroit ou il va 
> chercher ses fichiers) donc rien à voir avec le root du kernel. Tu peux faire 
> "ls /" pour voir le contenu du root grub, ça doit donner la même chose que "ls 
> (hd0,1)". Tu devrait normalement y trouver le repertoire "grub" avec les 
> modules en particulier lvm.mod mais compte-tenu de ce que tu décris, je pense 
> qu'il n'y a même pas le repertoire...

C'est "prefix" qui fixe la cible pour /boot/grub, et "root" pour la
partition racine d'après mon expérience (limitée) de la chose. Par
exemple sur un système sur raid avec /boot séparé j'ai
"prefix=(hd0,1)/grub" et "root=md0", et grub ne s'en plaint pas.

Quoiqu'il en soit c'est grub le problème, et plutôt l'identification de
/boot/grub que de ta partition racine. Durant l'installation de grub,
as-tu bien vérifié si tous les fichiers de grub étaient bien présent
dans ton /boot/grub ? Ton /boot était monté ?

Tu devrais pouvoir démarrer à partir d'un cd genre "SGD"
http://www.supergrubdisk.org/ si tu ne t'en sors pas depuis le shell de
grub, et réinstaller grub proprement depuis ton système.

>  
>> Tom comment je peux faire avec un systemCDrescue pour rattraper le coup et
>>  pouvoir réinstaller grub et executer la commande suivante :
>>  update-initramfs -c -t -k all

Pour le moment ça ne s'impose pas, c'est grub le malade. Pour le
principe, on démarre sur le live-cd (avec sysrescue on passe "rescue64
au boot pour du 64bit), on monte la partition système cible sur un
répertoire créé pour l'occasion (/mnt/chroot), on "cd" sur le point de
montage et on "chroot . bin/sh" .

> 
> A mon avis, ne fait pas de "update-initramfs -c -t -k all" à partir d'un live-
> cd ou rescue-cd. Utilise un cd qui te permette de monter tes systèmes de 
> fichiers (sda1 et usr) et recopie au moins lvm.mod depuis [point de montage de  
> /dev/hoth/usr]/lib/grub/i386-pc/ vers [point de montage de sda1]/grub (si tu 
> as de la place sur sda1, recopie tout  i386-pc).
> 
> Tu pourra charger les modules (en particulier lvm.mod) et donc ton noyau qui 
> est sur un lv. J'ai déja eu un pb similaire en faisant un update-grub alors 
> que ma partition /boot n'était pas montée, update-grub recopie tout dans le 
> dossier /boot du filesystem / donc rien dans la partition de boot...

Avec "grub-mkconfig" (remplaçant de "update-grub" on peut utiliser
l'option "-o" pour déterminer la cible (où se trouve grub.cfg).
Avec "grub-install" c'est "--root-directory=" qui permet de viser juste.
Par défaut grub est sensé deviner...

> 
> PS : quand tu fais 
>> GRUB >linux vmlinuz-2.6.30 root=/dev/sda2 
>> GRUB> boot
> le kernel panic n'est pas du à l'initrd mais à ta commande, tu monte comme 
> rootfs une partition qui ne contient pas un système de fichier (genre ext3) 
> mais un système de volumes logiques donc le noyau ne retrouve pas ses petits.
> A mon avis l'initrd n'a rien à voir avec ton pb.
> 
> 

Donc c'est bien grub le problème, et plus particulièrement le contenu et
la localisation de /boot/grub (où sont les fichiers de configuration de
grub, les modules...).


Tom


Reply to: