Voici un petit retour d’install-galère. Le but est de rappeler 2/3 arguments de GRUB bien pratiques et de faire remarquer quelques bizarreries du monde PC, dirons-nous.

Récemment, j’ai installé une Ubuntu sur un PC équipé comme suit :
– disque 1 : SAS (Serial-Attached-SCSI) contenant un windows
– disque 2 : SATA vide prévu pour l’Ubuntu
– disques 3 et 4 : 2 HD SATA de données.

Il n’y avait donc qu’un boot XP normal sur le SAS.

Ordre de boot…

Au départ, le BIOS (d’une marque connue qui ne permet rien ou si peu dans son BIOS) pointait sur le SAS puis SATA dans l’ordre de boot.
J’ai choisi de mettre GRUB sur le disque SATA (et ainsi ne pas flinguer le MBR du Windows). Comme ça les OS ignorent presque que l’autre est là et je peux surtout virer un des 2 disques sans devoir réinstaller le MBR de l’un ou de l’autre.

J’ai donc dû inverser l’ordre de boot dans le BIOS. Rien de surprenant jusque là.
Comme on ne peut pas préciser dans ce BIOS quel SATA ou quel SAS doit booter lorsqu’il y en a plusieurs, c’est donc le premier – pas d’autre possibilité.
Ce premier détail – on s’en rend compte après une première install d’Ubuntu sur le SATA où rien ne boote – force à organiser ses disques (mes SATA en l’occurrence) de sorte que l’Ubuntu soit sur le premier SATA. Au départ, dans mon cas, c’était le dernier (je venais de l’ajouter…)

sda, non, sdd, non (hd3,0) non plus… raaaaaah

J’ai fait plusieurs réinstall de la chose et ça ne s’est pas vraiment passé 2 fois pareil au niveau de la détection des disques durs, donc de l’ordre d’apparition, donc de leurs noms, donc de la conf GRUB. Parfois tout marchait tout seul, parfois après install, plus rien ne bootait (ni Ubuntu, ni Windows).
Un conseil donc, avant de lancer l’installation Ubuntu, lorsque vous êtes en liveOS, vous repérez bien le nom de chaque disque via un petit fdisk. Vous le faites avec le BIOS précablé vers le bon disque (mon SATA dans mon cas) :

ubuntu:~$ sudo fdisk -l
Disque /dev/sda: 146.8 Go, 146815737856 octets
255 heads, 63 sectors/track, 17849 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x12345678

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sda1   *           1       17849   143372061    7  HPFS/NTFS

Disque /dev/sdb: 400.0 Go, 400088457216 octets
255 heads, 63 sectors/track, 48641 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x12345678

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdb1   *           1        2432    19535008+  83  Linux
/dev/sdb2            2433        2681     2000092+  82  Linux swap / Solaris
/dev/sdb3            2682       48641   369173700   83  Linux

Disque /dev/sdc: 400.0 Go, 400088457216 octets
255 heads, 63 sectors/track, 48641 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x12345678

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdc1               1       48641   390708801    7  HPFS/NTFS

Disque /dev/sdd: 400.0 Go, 400088457216 octets
255 heads, 63 sectors/track, 48641 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x12345678

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdd1               1       48641   390708801    7  HPFS/NTFS

Dans le cas ci-dessus, le SAS de 146 Go puis 3 SATA de 400 Go.
Donc Windows = /dev/sda1 et Ubuntu sera = /dev/sdb1

FIXME : Parfois, et je n’arrive pas à l’expliquer, le boot du Live Ubuntu m’a sorti un mode graphique un peu dégradé et l’ordre des disques changeaient…
Au final, je me suis retrouvé avec une conf GRUB mauvaise et pas grand chose ne bootait.

Dans mon cas, la bonne conf est la suivante – je ne prends que la fin du fichier /boot/grub/menu.lst :

## ## End Default Options ##

title           Ubuntu 7.10, kernel 2.6.22-14-generic
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.22-14-generic root=UUID=52f30332-a489-4df5-8305-85c4a1e7dba1 ro quiet splash
initrd          /boot/initrd.img-2.6.22-14-generic
quiet

title           Ubuntu 7.10, kernel 2.6.22-14-generic (recovery mode)
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.22-14-generic root=UUID=52f30332-a489-4df5-8305-85c4a1e7dba1 ro single
initrd          /boot/initrd.img-2.6.22-14-generic

title           Ubuntu 7.10, memtest86+
root            (hd0,0)
kernel          /boot/memtest86+.bin
quiet

### END DEBIAN AUTOMAGIC KERNELS LIST

# This is a divider, added to separate the menu items below from the Debian
# ones.
title           Other operating systems:
root


# This entry automatically added by the Debian installer for a non-linux OS
# on /dev/sda1
title           Windows XP
map             (hd3) (hd0)
map             (hd0) (hd3)
root            (hd3,0)
makeactive
chainloader     +1

Le piège

Si vous avez été attentif, vous avez vu le piège :
Dans GRUB, le linux est vu comme le premier disque : hd0. C’est vrai, à condition de se dire que le BIOS boote (donc détecte ?) d’abord le SATA (donc il compte d’abord les SATA et le SAS est vu alors en 4è).
=> C’est sur cette info que se base GRUB.

Par contre, le disque contenant vraiment l’OS Linux est sdB, donc le deuxième O_o
=> Ce qui veut dire que Ubuntu redétecte l’ordre des disques à sa manière ensuite (disons que je le vois comme ça, tout au moins 🙂

De même pour le Windows, c’est sdA alors qu’il est vu par le BIOS en dernier (4è => hd3 dans GRUB).

Enfin, piège ultime, les lignes « map » qui n’étaient pas là au départ.
Windows ne tolère de booter que s’il est « le premier disque » – ce qui ne veut rien dire et est une limitation complètement débile. Toujours est-il que là, il est vu à un moment donné comme 4è et sans vous le dire, ce con de NTLOADER ne part pas (et ne vous dit rien). GRUB vous dit que ça merdoit puis vous ramène au menu de boot.
La commande « map » sert à modifier virtuellement l’ordre des disques. Ca suffit à blouser Windows. Attention le « root » reste sur hd3 alors qu’on a inversé les disques, c’est pas dynamique à ce niveau là.

=> Le bilan après installation Ubuntu, c’est qu’aucun des menus ne menait à rien…. il a fallu changer la conf GRUB à la volée pour récupérer le linux, tester les paramètres pour booter le windows et enfin écrire la bonne conf dans /boot/grub/menu.lst

Remarque sur les modifs à la volée de GRUB lors du boot

Si GRUB démarre après une install, mais qu’aucun menu ne vous démarre un OS (ils sont simplement listés), n’oubliez pas que vous avez la touche ‘e’ pour éditer une des lignes du menu de choix du boot. Les raccourcis claviers sont expliqués. Vous pourrez donc choisir un root (hdtruc,bidule) qui va bien.
Si vous avez bien en tête la conf en terme de /dev/sdX et l’ordre des disques vu par le BIOS, vous devriez pouvoir faire booter n’importe quoi. Une fois sous le linux qui héberge le fichier de conf de GRUB, vous reportez vos modifs et c’est fini.