Clef de secours (seconde partie)

Suivant les indications figurant dans le billet Clef de secours, nous avons rendu une clef usb bootable en installant dans son secteur d'amorce un chargeur grub qui pointe vers un dossier grub situé sur cette même clef.

Dans ce dossier se trouve un fichier de configuration grub.cfg contenant par exemple:

search --no-floppy --label --set=root Ubuntu 
chainloader +1 
boot

Si tout fonctionne bien, booter via la clef est transparent et le menu qui surgit est celui du fichier de configuration utilisé par le chargeur grub dont la partie initiale se trouve sur le VBR (Volume Boot Record) de la première partition trouvée dont le label est "Ubuntu".
Dans le cas contraire, si cela se passe mal, il existe diverses possibilités. L'une d'elles consiste à ce que l'on atterrisse directement dans un shell grub.
Nous sommes alors à la tête d'un mini-système d'exploitation et nous pouvons lancer au niveau de ce shell grub un certain nombre de commandes, dont la commande set qui renvoie la liste de différentes variables d'environnement avec leur valeur.
Examinant l'output de cette commande nous y trouvons quelque chose comme:

prefix=(hd0,msdos1)/grub
root=hd1,msdos3

Cela montre que l'exécution de la commande search a été couronnée de succès car au démarrage la valeur de la variable root est fixée à partir de celle de la valeur prefix.
En fait la variable prefix indique à grub où se trouvent les modules et les fichiers images (*.img) dont il a besoin pour fonctionner: dans le dossier grub de la partition 1 de la clef usb (qui est considérée comme hd0 puisqu'on a booté dessus).
Puisque search a bien fonctionné, la raison de l'échec du lancement du système linux est a chercher ailleurs: le VBR désigné par la commande chainloader ne contient pas de grub, ou celui-ci est inopérant.
Sans doute grub n'a-t-il jamais été installé sur ce VBR?

La commande multiboot.
Mais pas de problèmes: il n'est pas nécessaire de procéder à cette installation. Pour charger le grub du système linux que nous souhaitons démarrer, il suffit de saisir dans notre shell grub les commandes:

grub> multiboot /grub/i386-pc/core.img 
grub> boot

Ceci implique bien sûr que le label Ubuntu désigne une partition qui sera montée en /boot.
Si Ubuntu désigne la partition racine et qu'aucune partition n'est montée en /boot les commandes à saisir sont:

grub> multiboot /boot/grub/i386-pc/core.img 
grub> boot

Dans les deux cas, le chemin vers core.img n'est pas nécessairement celui indiqué ici. Mais comme la complétion fonctionne très bien, il est aisé de vérifier si on est sur la bonne voie où pas.
Une autre possibilité si cela se passe mal dès le départ est que l'on soit finalement renvoyé vers le chargeur principal. Mais normalement si nous utilisons la clef de secours c'est justement parce que le chargeur principal ne nous permet plus d'amorcer notre système linux. Le désastre étant provoqué par la commande boot figurant dans le grub.cfg de la clef, nous la supprimons avant une nouvelle tentative. Nous atterrissons cette fois dans un shell grub.
L'output de la commande set donne:

prefix=(hd0,msdos1)/grub 
root=hd0,msdos0

La variable root est restée inchangée! La commande search n'a rien donné: aucune partition trouvée avec le label indiqué (Ubuntu dans notre exemple). Il importe avant de poursuivre de donner à la variable root la valeur qui convient, soit directement, par exemple:

grub> set root=(hd1,3)

soit en lançant une nouvelle commande search adaptée.
Évidemment pour savoir quelle est la valeur à attribuer à root, il faut avoir un minimum de connaissance sur la structure du système linux que l'on veut amorcer: quelles sont les partitions utilisées?
Si nous fixons nous-même directement la valeur de root, il peut être utile de vérifier que nous sommes au bon endroit  à l'aide de la commande

grub> ls /

Ici nous vérifions que nous sommes bien sur la partition /boot d'un système Fedora 17 avant de saisir les commandes permettant de charger le grub de ce système:

Si la commande ls / retourne des choses du genre etc/ boot/ home/ ..., cela signifie que nous sommes sur la partition racine d'un système.
Il convient alors d'exécuter la commande ls /boot. Si cette dernière commande ne retourne rien, cela signifie que notre système fonctionne avec en plus de la partition racine, une partition à monter en /boot.

Notons que l'emploi de la commande multiboot n'est pas réservé à une utilisation dans un shell grub: elle peut aussi être utilisée dans un fichier grub.cfg.

La commande configfile.
Une alternative à la commande multiboot est l'utilisation de la commande configfile:

grub> configfile /grub/grub.cfg

Cette commande provoque l'affichage du même menu que celui obtenu avec la commande multiboot. La différence est que cette fois le grub du système linux (dont les fichiers img et mod se trouvent sur le disque dur) n'est pas chargé. On reste dans le même grub (celui de la clef), mais on lui demande d'utiliser le fichier de configuration dont le nom absolu est (hd1,3)/boot/grub (si la variable root vaut hd1,3)

Amorçage en ligne de commande.
Supposons maintenant que notre système linux ne comprenne aucun chargeur où que celui-ci est inopérant.
Impossible d'utiliser la commande multiboot (ou configfile).
Mais rien n'est perdu.
Quelques commandes tapées dans notre shell grub (où placées dans le grub.cfg) suffisent à amorcer le système:

grub> set root=(hd1,3) 
grub> linux /vmlinuz-3.5.0-17-generic root=LABEL=u-root ro
grub> initrd /initrd-3.5.0-generic 
grub> boot

Il est important de ne pas confondre la variable root de la ligne 1 qui se rapporte à la partition où se trouve le noyau (ici vmlinuz-3.5.0-17-generic) avec l'option root de la commande linux qui indique au noyau quelle est la partition racine.

Notons que grâce à la complétion il n'est pas nécessaire de connaître de connaître le nom exact des fichiers vmlinuz et initrd.
Il est cependant utile de connaître le label de la partition racine.
Rappelons que la commande blkid exécutée en root (par exemple depuis un live CD)  fournit tous les renseignements nécessaires.
Signalons enfin que si aucune partition n'est à monter dans /boot, la variable root désigne alors la partition racine puisque c'est elle qui contient le noyau. Mais malgré tout il faut encore indiquer au noyau quelle est la partition racine.
Dans ce cas les commandes à saisir seraient par exemple:

grub> set root=(hd1,3)
grub> linux /boot/vmlinuz-3.5.0-17-generic root=LABEL=Ubuntu ro
grub> initrd /boot/initrd-3.5.0-generic
grub> boot

Linux sans angoisse

Au moment de passer à l'acte, une angoisse insoutenable étreint soudain le néophyte.

Comme à chaque tentative, la même question lancinante assaille son esprit, encore et encore:

« Et si je perdais mon accès à windows? »

Mais cette fois, il ne renoncera pas!

Non, il ne renoncera pas à installer linux à côté de windows, sur le même disque dur.

Il ne renoncera pas car il a déjà tout préparé.

Dans windows, il a libéré de l'espace, plus précisément créé de l'espace non alloué pour pouvoir installer linux.

De plus, comme il est super angoissé, il a décidé de ne pas écraser le chargeur de windows. Il a déjà tout prévu pour pouvoir amorcer linux avec ce chargeur.

Il se souvient de chaque étape.

Tout d'abord, ouvrir l'invite de commande windows en mode Administrateur.

Ensuite sauvegarder le fichier bcd d'origine avec la commande:

bcdedit /export C:\bcdorig

De la sorte on peut facilement revenir à la situation antérieure avec:

bcdedit /import C:\bcdorig

L'étape suivante consiste à créer une entrée dans bcd:

bcdedit /create /d "[Linux]" /application BOOTSECTOR

La commande envoie en retour (avec un message de réussite) l'identifiant de l'entrée nouvellement créée.
En effectuer une copie de manière à pouvoir l'utiliser pour la suite.

Étape suivante: indiquer au système sur quelle partition va se trouver le code servant à amorcer linux en donnant comme argument de la commande l'identifiant de l'entrée:

bcdedit /set {299c4c80-0a1b-11e2-ab33-f46d04d5218a} device partition=C:

Ensuite il faut préciser le chemin vers ce code:

bcdedit /set {299c4c80-0a1b-11e2-ab33-f46d04d5218a} path \linux.bin

Ajouter l'entrée au menu qui sera affiché:

bcdedit /displayorder {299c4c80-0a1b-11e2-ab33-f46d04d5218a} /addlast

Préciser le délai d'attente en secondes:

bcdedit /timeout 5

Tout ça a déjà été fait: maintenant quand il démarre son ordinateur, il tombe sur un menu qui ne lui sert à rien puisque linux n'est pas installé.
Ce serait stupide de reculer encore.
D'autant plus qu'il connait exactement ce qui lui reste à faire. Bootant sur le live cd, il a déjà repéré la partition que windows appelle C:

Facile: c'est celle qui contient à la racine le fichier bcdorig.
Il a appris à ouvrir un terminal: appuyer sur la touche windows et taper "te" fait apparaître son icône. Il ne reste plus qu'à cliquer dessus:

Ensuite pour faire passer le terminal en mode Administrateur, il suffit d'y taper la commande

sudo -s

Pour se déplacer dans le terminal vers la partition C de windows, le plus facile consiste à taper la commande cd suivie d'un espace puis de faire un glisser-déposer de l'icône de la partition sur le curseur du terminal.

Ensuite: appuyer sur 'Enter ', et voilà: on y est!

Il sait faire tout cela. Il s'est souvent entraîné: c'est devenu un expert.
Avant même d'avoir installé quoique ce soit!

A la fin de l'installation, avant de quitter le live cd, il pourra facilement refaire toutes ces manipulations. Puis lui restera à créer le fichier linux.bin en exécutant la commande:

dd if=/dev/sda7 of=linux.bin bs=512 count=1

/dev/sda7 désignant la partition sur laquelle le chargeur linux sera installé.

Clef de secours

Ce sujet ne traitera pas de la constitution d'une clef usb permettant de réparer windows.
Pour ceux qui seraient intéressés, ce lien devrait les combler.
Nous allons ici parler ici d'une clef permettant de démarrer linux lorsque cette possibilité a été perdue suite par exemple à l'utilisation d'une clef usb (ou d'un cd) de réparation de windows.
Bien sûr, il y a toujours moyen de s'en sortir via l'utilisation d'un Live cd, mais la procédure est beaucoup plus lourde.
Le mieux est d'être prévoyant.
Donc, supposons que nous pouvons accéder sans problèmes à notre système linux.
Déterminons quelles sont les partitions utilisées par notre système à l'aide la commande df:

La partition racine de notre système est /dev/sda7.
Nous constatons la présence d'une clef usb reconnue en tant que /dev/sdc et dont l'unique partition 1 est montée en /media/KINGSTON.
La première opération, consiste, si ce n'est déjà fait, à installer grub (acronyme de Grand Unified Bootloader) sur le secteur d'amorce (VBR) de la partition racine. En effet, rien n'empêche d'installer grub à la fois sur /dev/sda (donc sur le MBR) et sur le VBR de /dev/sda7. On dispose ainsi de deux portes d'entrée pour lancer notre système linux.
Procédons à l'aide de la commande:

# grub-install --force /dev/sda7

L'option --force n'est tellement appréciée par le système et il nous le fait savoir.
Le grub installé sur /dev/sda7 ne peut être utilisé qu'en tant que chargeur secondaire.
Nous verrons dans un autre billet comment il peut être initié par le chargeur de windows. Dans ce billet nous allons montrer comment procéder en bootant sur une clef usb (ceci a déjà été évoqué dans ce billet).
Tout d'abord, il convient d'installer grub sur le secteur d'amorce de la clef usb et le faire pointer vers des fichiers qui seront enregistrés sur la clef:

# grub-install --boot-directory=/media/KINGSTON /dev/sdc

Il est à remarquer que les données présentes sur la clef (par exemple formatée en FAT32) ne sont absolument pas impactées par l'opération: elle peut donc continuer à être utilisée de manière classique.
Simplement il y a apparition d'un dossier grub contenant tous les fichiers liés à ce chargeur. Il y manque le fichier de configuration grub.cfg.

Afin de pouvoir le constituer, il serait utile d'avoir quelques informations complémentaires sur /dev/sda7:

Constatant que la partition n'avait pas de label, nous lui en avons attribué un (en rapport évidemment avec le système linux installé)
Nous pouvons créer un fichier de configuration utilisant l'UUID de /dev/sda7, et contenant:

search --no-floppy --fs-uuid --set=root 5eba7617-afd6-4480-9b65-fb4e48de3d3c
chainloader +1
boot

On peut aussi fonctionner avec le label:

search --no-floppy --label --set=root Ubuntu
chainloader +1
boot

L'avantage de cette dernière solution est que la clef peut être utilisée sur différentes machines à condition que les partitions utilisées pour booter aient toutes le même label (à savoir Ubuntu dans cet exemple).

Et voilà: pourvu que le bios soit configuré pour booter en priorité sur l'usb, il suffit de démarrer avec une clef insérée pour amorcer linux sans utiliser le MBR

Pour avoir l'opportunité de choisir le système à amorcer, il faut évidemment une étape supplémentaire, à savoir afficher un menu, ce qui s'obtient par exemple avec un fichier de configuration tel que celui-ci:

menuentry "Ubuntu" { 
search --no-floppy --label --set=root Ubuntu 
chainloader +1
} 
menuentry "Linux Mint" { 
search --no-floppy --label --set=root Mint 
chainloader +1
}