L'image d'installation de Fedora, stockée sur une clé USB ou un DVD-RW, est toujours utile pour les bricoleurs. Elle permet notament de dépanner un système Fedora qui ne peut plus démarrer, à condition d'être à l'aise avec la ligne de commandes. Une fois le système démarré, on pourra traiter la panne...

Booter sur le DVD ou la clé USB

Dans le BIOS/UEFI, il faut sélectionner la clé USB ou le DVD pour démarrer la machine dessus.

Après avoir sélectionné l'entrée GRUB « Réparer un système installé », une fenêtre contextuelle demande si vous désirez que le DVD recherche, monte, puis chroote la partition racine de votre système. Personnellement, ça n'a jamais marché ici, du coup je choisis de passer cette étape en sélectionnant « Skip ». Une autre fenêtre contextuelle que je ne détaillerais pas apparait ensuite. À l'arrivée, vous êtes censé avoir un invite de commandes. Petite exclusivité de Fedora 18, notre invite de commande est lancé dans le Tmux (multiplexeur de terminal) dans lequel est exécuté le programme d'installation Anaconda. Dans les autres fenêtres de Tmux, on peut voir tous les logs générés par le programme en temps réél (c'est pas utile dans l'immédiat, mais c'est toujours bon à savoir).

Nous avons donc une invite de commande mettant à notre disposition l'intégralité des outils GNU/Linux. On a également à disposition tous les moyens pour contrôler le bon fonctionnement du programme Anaconda, mais dans cet invite, on a toujours pas accès à notre système Fedora. Celui qui est installé sur le disque dur de la machine...

La première chose à faire est de changer l'agencement de clavier, car comme vous l'aurez constaté, il est en qwerty :

# loadkeys -u fr-latin9

Déchiffrer le disque dur

Ensuite, si vous avez un ou plusieurs volumes chiffrés LUKS, il faut d'abord déverrouiller ces volumes :

# cryptsetup luksOpen /dev/sda2 luks-pv1
# cryptsetup luksOpen /dev/sda3 luks-pv2
# cryptsetup luksOpen /dev/sda4 luks-pv3

Il est toujours possible de tester si une partition /dev/sdxY est un container LUKS ou pas, avec une commande d'information :

# cryptsetup luksUUID /dev/sdxY

Accèder aux données dans LVM

Puis, si vous avez un ou plusieurs groupe de volumes LVM, il faut les activer. Si vous n'avez pas LVM, alors vous utilisez le système obsolète des partitions primaires (passez directement à la phase suivante, du coup) :

# vgchange -ay <nom_du_VG>

Alors évidemment, pas la peine de devoir retenir par coeur le nom de son groupe de volumes (VG). On peut retrouver les VG présents sur son disque dur à l'aide de la commande suivante :

# vgs

L'avantage d'activer directement le groupe de volumes est que tous les volumes logiques (LV) sont activés d'un seul coup. Maintenant que les LV sont accessibles, nous pouvons les monter de la façon la plus naturelle qui soit :

# mount /dev/mapper/<nom_du_VG>-<nom_du_LV> /mnt/lv1

Par exemple, dans mon cas :

# mount /dev/mapper/vg_blackbird-LogVol01 /mnt/lv1

N'hésitez pas à appuyer sur [Tab] pour bénéficier de l'autocomplétion. Une fois le volume logique de la racine / monté, on peut désormais intervenir sur notre système endommagé.

Chrooter sur la racine

Avant de chrooter sur votre système, il faut rendre accessible les périphèriques /dev dans votre chroot, notament pour réparer le chargeur de démarrage GRUB par exemple :

# mount -o bind /dev /mnt/lv1/dev

Et enfin, on peut lancer le chroot :

# chroot /mnt/lv1

Selon la panne, vous ne serez pas toujours obligé de faire un chroot. Il se peut que vous ayez juste besoin de monter le volume racine, pour modifier un fichier de configuration, par exemple. Bien sûr, tout ça dépend de la panne que vous rencontrez.