Mise a jour de GRUB

Support Debian
#1

Bonjour à tous,
je réouvre un nouveau sujet concernant mon problème, l’ancien http://www.debian-fr.org/annuler-apt-get-install-et-selectionner-les-paquets-t34328.html n’étant pas assez précis.

J’ai un serveur chez OVH sur lequel je dois mettre à jour grub, pendant l’éxécution de la MAJ j’ai ce message :

[code]The GRUB boot loader was previously installed to a disk that is no longer present, or whose normally unique identifier has changed for some reason. It is important to make sure that the installed GRUB stays in sync with other components such as grub.cfg or with newer Linux images it will have to load, and so you should check again to make sure that GRUB is installed to the appropriate boot devices.
If you’re unsure which drive is designated as boot drive by your BIOS, it is often a good idea to install GRUB to all of them.
Note: It is possible to install GRUB to partition boot records as well, and some appropriate partitions are offered here. However, this forces GRUB to use the blocklist mechanism, which makes it less reliable, and therefore is not recommended.

GRUB install devices:

[ ] /dev/sda (750156 Mo, ST3750525AS) │
[ ] /dev/sdb (750156 Mo, ST3750525AS) │
[ ] /dev/md1 (10737 Mo, ???) [/code]

Voici mon grub.cfg (l’os est Ubuntu, pas de debian proposé par OVH) :

[code]### BEGIN /etc/grub.d/06_OVHkernel ###
menuentry “Ubuntu 10.10, OVH kernel 2.6.34.6-xxxx-grs-ipv6-64” {
insmod raid
insmod mdraid
insmod part_msdos
insmod part_msdos
insmod ext2
set root=’(md1)'
search --no-floppy --fs-uuid --set 3b5d96d0-7f2d-41f7-b472-4fb0d5660c2a
linux /boot/bzImage-2.6.34.6-xxxx-grs-ipv6-64 root=/dev/md1 ro nomodeset debug
}

END /etc/grub.d/06_OVHkernel

[/code]

le résultat du fdisk :

[code]# fdisk -l

Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d944c

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 1306 10485760+ fd Linux raid autodetect
/dev/sdb2 1306 91136 721558528 fd Linux raid autodetect
/dev/sdb3 91136 91201 525696 82 Linux swap / Solaris

Disk /dev/sda: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000aa1b6

Device Boot Start End Blocks Id System
/dev/sda1 * 1 1306 10485760+ fd Linux raid autodetect
/dev/sda2 1306 91136 721558528 fd Linux raid autodetect
/dev/sda3 91136 91201 525696 82 Linux swap / Solaris

Disk /dev/md2: 738.9 GB, 738875867136 bytes
2 heads, 4 sectors/track, 180389616 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md2 doesn’t contain a valid partition table

Disk /dev/md1: 10.7 GB, 10737352704 bytes
2 heads, 4 sectors/track, 2621424 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md1 doesn’t contain a valid partition table[/code]

Fdisk indique un boot sur sda1 et sdb1 mais vu qu’il y a du raid, devrais je choisir md1 (d’ailleur le grub.cfg en fait référence) ?

Merci d’avance pour vos conseils

#2

[quote]If you’re unsure which drive is designated as boot drive by your BIOS, it is often a good idea to install GRUB to all of them.
[/quote]
Serveur distant, tu n’as donc pas accès au BIOS. Pas évident de deviner sans accès au BIOS.

Fais une copie du MBR de chaque disque et détermine si cette copie contient grub

dd if=/de/sda of=MBR-sda bs=512 count=1

file MBR-sda

MBR-sda: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3, stage2 address 0x2000…

Installe sur le ou les disques qui dénotent la présence de grub.
Tous les disques attestent de la présence de grub? Installe donc sur tous les disques …

#3

Salut,
merci pour les infos,
voila le resultat des commandes :

# file MBR-sda MBR-sda: x86 boot sector, LInux i386 boot LOader; partition 1: ID=0xfd, active, ad 254, startsector 1464092673, 1051392 sectors, code offset 0x63

# file MBR-sdb MBR-sdb: x86 boot sector; partition 1: ID=0xfd, active, starthead 65, startsecto 092673, 1051392 sectors, code offset 0x63

# file MBR-md0 MBR-md0: data

# file MBR-md1 MBR-md1: data

# file MBR-md2 MBR-md2: data

#4

file MBR-sda

MBR-sda: x86 boot sector, LInux i386 boot LOader;

Tu es ici en présence de LILO et pas de grub

packages.debian.org/squeeze/lilo

La présence de lilo indiquerait donc que /dev/sda serait le disque à cibler.

Question à trancher : persister avec lilo ou le remplacer par grub2 ?

#5

ok merci de me l’indiquer j’avais absolument pas fait attention à ça…

je préfère basculer vers Grub, à ton avis une install sur /dev/sda me permettra donc de redémarrer sans surprise ?

#6

Regarde les réglages en /etc/lilo.conf pour voir si le disque de démarrage par défaut correspond à ce qui transparait dans le MBR de /dev/sda.
À partir de ce point, tu auras confirmation que /dev/sda est le “bon” disque.

Installer grub2 ne devrait pas poser de problèmes mais on ne sait jamais …

#7

pas de lilo.conf dans /etc/ :017
Le paquet lilo est bien installé

#8

Provoque sa création :

liloconfig

regarde le contenu de /etc/lilo.conf puis efface le.

#9

J’ai lancé liloconfig tout à l’heure mais étant donnée qu’il ma demandé de lui confirmer certain paramètre j’ai killé le processus de peur de faire des erreur.
Quand je le lance j’ai ca :

[code]──────────────────────────┤ Configuration de LILO ├───────────────────────────────

Installer un secteur de démarrage de partition pour démarrer Linux depuis /dev/md1 ?

             <Yes>                           <No>     [/code]
#10

Répond “YES” et pousse plus avant les réglages jusqu’à ce qu’il soit fait mention des MBR.

Créer /etc/lilo.conf n’engage à rien.
Lilo est un chargeur d’amorçage qui demande à être lancé explicitement.
Tant que tu ne lanceras pas :

lilo

il ne se passera rien sur le MBR.
En clair: NE PAS lancer # lilo, il s’applique sans avoir besoin de redémarrer.

#11

j’ai poursuivie la commande :
Il m’a demandé de choisir entre différente configuration bmp

J’ai choisir au hasard /boot/debianlilo.bmp puisi l m’a fais cette erreur :

Searching for installed kernels and updating image entries ... /bin/ls: cannot access /boot/vmlinuz*: No such file or directory Warning: Unable to determine video adapter in use in the present system. Fatal: No images have been defined.

Le lilo.conf existe désormais, il est donc paramétré sur md1, ce qui doit être normal non ? vu que c’est ce qu’il me proposait

As tu besoin d’autre informations ?

Merci pour tes conseils