Ok herrib, j'ai tout rebranché et retenté grub-install :
#grub-install /dev/sda --recheck
Probing devices to guess BIOS drives. This may take a long time.
The file /boot/grub/stage1 not read correctly
Je te demande de passer la commande: grub-install /dev/hda --recheck
Arffff, désolé herrib, il commence à être tard chez moi!

grub-install /dev/hda --recheck donne le meme resultat : 
#grub-install /dev/hda --recheck
Probing devices to guess BIOS drives. This may take a long time.
The file /boot/grub/stage1 not read correctly
Pourrais tu poster /etc/mtab?
Il me semble que si grub est installe dans le MBR d'un disque (pas d'une partition) le flag actif n'a pas d'importance. C'est le MBR de dos/windows qui le prend en compte. J'essaye apres avoir envoye ce message...
-> Succes. grub s'en fout d'avoir une partition active ou pas
Pour ce qui est du hda, il y a bien une partition étendue contenant trois lecteurs logiques (chose parfaitement inutile puisque je n'ai que 3 partitions ; 3 partitions primaires auraient parfaitement suffi... mais bon j'avais suivi à l'époque des conseils plus ou moins pertinents:-)...)
C'est sur ca? Il me semble que les partitions logiques ont toujours le nombre dans le nom > 4. Tu devrait avoir /dev/hda1 (EXT'd) et /dev/hda5,6,7. C'est pour ca que je dis que tu a l'air d'avoir des partitions primaires dans la partition etendue.
/boot n'a pas disparu (voir le premier message).
Mais /dev/sda1 est vide quand on regarde les autre messages.
Grub-install, comme script, suppose que les stageX sont dans /boot/grub et il ne les modifie pas.
Non grub-install va les chercher dans /usr/share/grub/i386-redhat/stage2 et les met dans /boot/grub. Puis il "incruse" (to embedd) le stage1_5 (ou le stage2) au debut de la partition. Ceux ci comprennent le systeme de fichiers de la partition et sont donc capable de lire le stage2 (ainsi que les kernel etc) dans ce systeme de fichiers.
grub-install /dev/sda --recheck
Comme il y a une partition de boot separe il faut un --root-directory=/boot. Mais grub parvient jusqu'au stage2 donc il fonctionne et je ne vois pas pourquoi tout le monde essai de le reinstaller.

Un fsck -f /dev/sda1 pourrait etre interresant.
Verifie dans l'output de dumpe2fs que le label du systeme de fichiers est bien /boot comme le veut ton fstab.
Je remonterai /dev/sda1 sur /mnt/sda1 et cp -a /boot/* /mnt/sda1/.
Tobias
tobi1canobe wrote:Mais /dev/sda1 est vide quand on regarde les autre messages.
Etrange car vivelapluie a pu (voir message #1) lire les répertoires.
Non grub-install va les chercher dans /usr/share/grub/i386-redhat/stage2 et les met dans /boot/grub. Puis il "incruse" (to embedd) le stage1_5 (ou le stage2) au debut de la partition. Ceux ci comprennent le systeme de fichiers de la partition et sont donc capable de lire le stage2 (ainsi que les kernel etc) dans ce systeme de fichiers.
Grub ne supporte pas les LVM; /usr/share/grub/i386-redhat/stage2 est dans un LVM selon l'installation par défaut de Fedora et pourtant, le script grub-install fonctionne relativement systématiquement ... Ce qui laisse penser que la présence de /boot/grub/stageX est testée par le script (je le verifie ce soir ...) et que la copie dans /boot/grub n'est pas / ne serait pas systématique.
Mais grub parvient jusqu'au stage2 donc il fonctionne et je ne vois pas pourquoi tout le monde essai de le reinstaller
. Il n'y a pas volonté de le réinstaller (en tout cas, pas sur /dev/sda!) mais de forcer une nouvelle reconnaissance des périphériques.

Bon, bon, l'étude progresse ...
herrib,
dans ce cas grub-install fonctionne, mais uniquement lorsqu'il est lancé depuis le cd en mode rescue et là, la question des LVM ne se pose pas. Enfin cette machine bootait apparemment depuis toujours sur sda1, même après ajout d'un disque IDE, raison pour laquelle j'ai suggéré de repartir de la même configuration.

Il y a une autre question bizarre : comment arrive-t-on à lire sur une partition /boot sans qu'elle soit montée (cf en effet post #1) ou alors par erreur elle aurait été incluse dans un LVM ? Mais comment, puisque tout fonctionnait bien avant l'arrivée du nouveau disque et que rien d'autre (à priori) n'a été modifié ?
Etrange car vivelapluie a pu (voir message #1) lire les répertoires.
Oui mais /dev/sda1 n'etait aparement pas monte.
Grub ne supporte pas les LVM; /usr/share/grub/i386-redhat/stage2 est dans un LVM selon l'installation par défaut de Fedora et pourtant, le script grub-install fonctionne relativement systématiquement
Oui mais grub-install n'est pas grub. grub-install troune a l'intereur d'un linux qui lui comprend tres bien les LVM. Il peut donc aller chercher dans le LVM ce dont le vrai grub a besoin et le mettre dans une partition accessible par grub. D'ailleurs, de info grub:
GRUB comes with boot images, which are normally put in the directory
`/usr/lib/grub/i386-pc'. If you do not use grub-install, then you need
to copy the files `stage1', `stage2', and `*stage1_5' to the directory
`/boot/grub
Il n'y a pas volonté de le réinstaller (en tout cas, pas sur /dev/sda!) mais de forcer une nouvelle reconnaissance des périphériques.
grub n'utilise pas device.map. Ce fichier ne sert qu'a l'installation de grub depuis un linux par grub-install. Donc si tu veux recreer ce fichier c'est bien pour t'en servir a installer grub.

Tobias
Désolé les gars du silence, je viens de me lever.

@ herrib : contenu de /etc/mtab 
#cat /etc/mtab
/dev/Vol Goup00/Systeme / ext3 rw,defaults 0 0
/dev/Donnees/Espace2 /Donnees ext3 rw,defaults 0 0
/dev/Vol Goup00/Data /home ext3 rw,defaults 0 0
proc /proc proc rw,defaults 0 0
sysfs /sys sysfs rw,defaults 0 0
/dev/sysfs /sys sysfs rw,defaults 0 0
/dev/Vol Goup00/Extensions /usr/local ext3 rw,defaults 0 0
@ tobi1canobe :

- resultat de fsck -f /dev/sda1 
#fsck -f /dev/sda1
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 11/26104 files (9.1% non-contiguous), 8966/104388 blocks
- Concernant le label du système de fichier obtenu avec dumpe2fs -h /dev/sda1, je ne vois pas l'info car il me semble qe je ne vois que la fin de l'output sur mon écran et je ne sais pas comment revenir au début de cet output

- Resultat du montage de /dev/sda1 puis cp -a /boot/* /mnt/sda1 
#mount -t ext3 /dev/sda1 /mnt/sda1
#cp -a /boot/* /mnt/sda1
Le redemarrage de la machine de la machine en mode normal donne : 
    Booting 'Fedora Core 6 (2.6.18-1.2798.fc6)'

root (hd1,0)
 Filesystem type unknown, partition type 0xf
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/Systeme

Error 17: Cannot mount selected partition

Press any key to continue...
Si je tape sur une touche j'arrive dans grub en mode graphique et si je sélectionne fedora core 6 je reviens au message ci-dessus.

@nouvo09 : je confirme bien que mis à part l'ajout du nouveau disque SATA et la création d'un LVM supplémentaire sur ce nouveau disque, rien n'a été modifié par rapport au système qui fonctionnait normalement avant les problèmes de boot.
Mais c'est quoi ce type là ?
Filesystem type unknown, partition type 0xf
tu peux vérifier avec un fdisl -l /dev/sda que le type de la partition sda1 est bien à 83 ?

Si ce n'est pas le cas avec fdisk corrige le type en tapant t et le type 83 etc..
Bon et bien moi je dirais que c'est des bonne nouvelles tout ca. grub trouve son grub.conf depuis la copie de /boot vers /dev/sda1. Reste a ajuster le root (hd1,0) pour qu'il trouve le kernel et initrd.Là il a l'air de croire que (hd1,0) est la premiere partition du disque ide (hda1) (a cause du type 0xf de la partition).
Je reboote pour faire qqe essais dans grub.
Tobias
Au boot quand tu a le compte a rebour appuie sur espace, puis sur c. Tu te retrouve a la ligne de commande de grub (minmal bash like). Fais un find /grub/stage1 qui devrait cette fois marcher et te donner le nom du disque de sda1.
Reboot en rescue, mount /dev/sda1 /mnt/sda1 et edit /mnt/sda1/grub/grub.conf. Change le root (hd1,0) en (hdX,0) ou hdX vient du find d'avant.
Tobias
@nouvo09 :

Résultat de fdisl -l /dev/sda : 
#fdisl -l /dev/sda
sh: fdisl: command not found
J'ai donc ensuite essayé fdisk -l /dev/sda qui me donne ceci : 
#fdisk -l /dev/sda

Disk /dev/sda: 82.3 GB, 82348277760 bytes
255 heads, 63 sectors/track, 10011 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device      Boot       Start            End             Blocks      Id System
/dev/sda1         *           1             13             104391      83 Linux
/dev/sda2                    14          10011           80308935      8e LVM Linux
@ tobi1canobe :

- reboot de la machine en mode mormal --> grub en mode ligne de commandes 
grub> find /grub/stage1
 (hd0,0)
-reboot de la machine en mode rescue 
#mount /dev/sda1 /mnt/sda1
#vi /mnt/sda1/grub/grub.conf

default=0
timeout=5
splashimage=(hd1,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora Core 6 (2.6.18-1.2798.fc6)
         root (hd1,0)
         kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/Systeme
         initrd initrd-2.6.18-1.2798.fc6.img
J'ai donc modifié root(hd1,0) --> root(hd0,0)

-reboot de la machine en mode normal : 
 Booting 'Fedora Core 6 (2.6.18-1.2798.fc6)'

root (hd0,0)
 Filesystem type unknown, partition type 0xf
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/Systeme[

Error 17: Cannot mount selected partition

Press any key to continue...
Et comme précédemment, si je tape sur une touche j'arrive dans grub en mode graphique et si je sélectionne fedora core 6 je reviens au message ci-dessus
L'idée d'obi1canobe était donc la bonne. sda1 est vu comme (hdO,0).

Tu vas donc pouvoir paramétrer grub comme suit:

1- démarrer en mode rescue

2- enchaîner:
# chroot /mnt/sysimage
# mount -t ext3 /dev/sda1 /mnt/sda1
# cd /mnt/sda1/boot/grub
# vi grub.conf (normalement le fichier a été créé, suite au post #29) -> tu passes en mode insert  = appui sur i
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora Core 6 (2.6.18-1.2798.fc6)
         root (hd0,0)
         kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/Systeme
         initrd initrd-2.6.18-1.2798.fc6.img
tu sauvegardes et quittes par la séquence escape :wp
# shutdown -r now (pour rebooter)
Si ça marche, tu remercies obi1canobe ...
@ herrib : j'ai bien suivi la procédure proposée

- Quand j'ai tapé #cd /mnt/sda1/boot/grub puis #vi grub.conf, je me suis retrouvé à créer un nouveau fichier.

- Pour quitter le fichier en sauvegardant, ce nést pas plutôt escape :wq ?

- La commande shutdown -r now me donne un message d'erreur

- si je redémarre la machine en mode normal, j'obtiens le message suivant : 
 Booting 'Fedora Core 6 (2.6.18-1.2798.fc6)'

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/Systeme
 [Linux-bzImage, setup=0x1e00, size=0x1e157e]
initrd initrd-2.6.18-1.2798.fc6.img

Error 1: Filename must be eiter an absolute pathname or blocklist

Press any key to continue...
En pressant une touche, j'arrive sur grub qui me propose le menu graphique pour choisir Fedora Core 6 (2.6.18-1.2798.fc6). Et quand je tape [enter], je reviens au message ci-desus
Je ne suis pas sur de tout comprendre aparement il y un peu de confusion entre /mnt/sda1/boot/grub.conf et /mnt/sda1/grub/grub.conf. D'apres ton dernier message il manque juste un / dans la ligne
initrd initrd-2.6.18-1.2798.fc6.img
qui devrait etre
initrd /initrd-2.6.18-1.2798.fc6.img
Tobias (croise les doigts)
Merdum! une erreur de saisie: il faut que la ligne concernant initrd soit libellée comme suit:
initrd /initrd-2.6.18-1.2798.fc6.img
Enfin pour vi, tu as raison: <esc>:wq (et non p!)

Pour shutdown -r now, on verra plus tard ... (tu peux saisir, si le chroot a bien été passé: /sbin/shutdown -r now)

(edit) le message a mis un peu de temps à s'afficher....
OK, je corrige cela ce soir en rentrant du boulot et je vous tiens au curant dans al foulee.

Merci pour votre disponibilite et votre reactivite!!! 🙂
Bon alors voilà, la situation vient de progresser pas mal!!!

- J'ai commencé par reprendre la procédure proposée par herrib dans le post 34, en corrigeant la ligne initrd /initrd-2.6.18-1.2798.fc6.img : 
# chroot /mnt/sysimage
# mount -t ext3 /dev/sda1 /mnt/sda1
# cd /mnt/sda1/boot/grub
# vi grub.conf
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora Core 6 (2.6.18-1.2798.fc6)
         root (hd0,0)
         kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/Systeme
         initrd /initrd-2.6.18-1.2798.fc6.img
Ca bloquait toujours quand je rebootais en mode normal.

- J'ai donc pris en considération la remarque de tobi1canobe :
Je ne suis pas sur de tout comprendre aparement il y un peu de confusion entre /mnt/sda1/boot/grub.conf et /mnt/sda1/grub/grub.conf.
- J'ai alors repris la procédure ci-dessus mais pour mnt/sda1/grub/grub.conf au lieu de mnt/sda1/boot/grub/grub.conf : 
# chroot /mnt/sysimage
# mount -t ext3 /dev/sda1 /mnt/sda1
# cd /mnt/sda1/grub
# vi grub.conf
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora Core 6 (2.6.18-1.2798.fc6)
         root (hd0,0)
         kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/Systeme
         initrd /initrd-2.6.18-1.2798.fc6.img
-J'ai rebooté la machine en mode normal et alleluia le boot se lance bien!

... mais tout n'est pas résolu pour autant : tout est OK jusqu'à la vérification du système de fichiers qui échoue : 
Vérification des systèmes de fichiers
/dev/VolGroup00/Système: clean, 180396/2560864 files, 1282351/2560000 blocks
fsck.ext3: Unable to resolve 'LABEL=/boot'
/dev/VolGroup00/Extensions: clean, 1013/1280000 files, 82685/1280000 blocks
/dev/VolGroup00/Data: clean, 67472/15975168 files, 14645715/15974912 blocks
/dev/Donnees/Espace2: clean, 11/13107200 files, 459380/26214400 blocks
                                                                                                            [ECHOUE]
*** Une erreur s'est produite pendant la vérification du système de fichiers
*** Vous connecte à un shell ; le système va redémarrer
*** lorsaue vous quittez le shell.
*** Attention -- SELinux est actif
*** Désactivation du niveau de sécurité pour la restauration du système.
*** Lancer 'setenforce 1' pour réactiver.
Give root password for maintenance
(or type Control-D to continue):
Essaie en fixant le LABEL de la partition (en rescue)
tune2fs -L /boot /dev/sda1
Le fichier, c'est bien /mnt/sda1/grub/grub.conf, car le fichier est dans [racine de la parition]/grub/grub.conf, qui devient, après montage : /boot/grub/grub.conf. Cela aurait été /mnt/sda1/boot/grub/grub.conf dans le cas d'une parition / (sans /boot séparé).


A+