GRUB vs. RAID sur les systèmes Red Hat
Ce matin j'ai fait un peu de maintenance informatique dans mon réseau local, et j'en ai profité pour intégrer la dernière mouture de mes playbooks Ansible. Résultat des courses : deux machines qui ne démarrent plus. Il semble bien que je me suis mis deux coups de douze dans le pied.
Une fois que la petite montée d'adrénaline se dissipe avec un bon café, je comprends ce qui s'est passé. J'ai intégré la gestion de GRUB à mes playbooks en oubliant le fait que sous Red Hat, les assemblages RAID nécessitent une configuration un peu spéciale au démarrage. Vu que c'est une erreur qu'il m'arrive de faire de temps en temps, j'ai décidé de la documenter ici sous forme d'un petit article de blog.
État des lieux
Le problème concerne uniquement mes machines sous Rocky Linux :
-
une station de travail sous Rocky Linux 9 qui utilise deux disques SATA en RAID 0.
-
un serveur de sauvegardes sous Rocky Linux 8 configuré en RAID 1.
Je vais décrire en détail la récupération du PC sous Rocky Linux 9. La procédure sera presque identique sous Rocky Linux 8, à quelques menus détails près.
Lancer le système de secours
Je démarre sur une clé USB de Rocky Linux 9 et je choisis l'option Rescue a
Rocky Linux system au démarrage. J'appuie sur Tab et j'ajoute les options
nomodeset vga=791 pour avoir une console plus lisible.
Une fois que j'ai un shell sur mon système de secours, j'active le réseau :
# nmcli dev
DEVICE TYPE STATE CONNECTION
enp3s0 ethernet disconnected --
lo loopback unmanaged --
# nmcli con up enp3s0
Je lance un serveur SSH pour pouvoir me connecter à distance à la machine et travailler un peu plus confortablement :
Assembler les grappes RAID
J'utilise la commande mdadm pour assembler les grappes RAID :
# mdadm --assemble --scan
mdadm: /dev/md/root has been started with 2 drives.
mdadm: /dev/md/swap has been started with 2 drives.
mdadm: /dev/md/boot has been started with 2 drives.
J'affiche les grappes de disques :
# cat /proc/mdstat
Personalities : [raid0] [raid1] [raid4] [raid5] [raid6] [raid10] [linear]
md125 : active raid0 sda1[0] sdb1[1]
2093056 blocks super 1.2 512k chunks
md126 : active raid0 sda2[0] sdb2[1]
8378368 blocks super 1.2 512k chunks
md127 : active raid0 sda3[0] sdb3[1]
1942772736 blocks super 1.2 512k chunks
unused devices: <none>
J'essaie d'en savoir un peu plus sur tout ce fatras :
# blkid /dev/md125 /dev/md126 /dev/md127
/dev/md125: LABEL="boot" UUID="54920152-f86b-4786-8520-981dafeeead9" TYPE="ext4"
/dev/md126: LABEL="swap" UUID="a54e78e2-81c9-4069-b7bf-e3be532fdfcc" TYPE="swap"
/dev/md127: LABEL="root" UUID="b8d06873-0697-4662-b60e-8cabe4163f02" TYPE="ext4"
# ls -l /dev/md
total 0
lrwxrwxrwx. 1 root root 8 Nov 13 11:47 boot -> ../md125
lrwxrwxrwx. 1 root root 8 Nov 13 11:47 root -> ../md127
lrwxrwxrwx. 1 root root 8 Nov 13 11:47 swap -> ../md126
-
md125: ma partition/bootformatée enext4 -
md126: ma partitionswap -
md127: ma partition principale formatée enext4
Monter le système
Maintenant que je sais qu'est-ce qui fait quoi, je peux commencer à monter les partitions :
# mount -v /dev/md/root /mnt
mount: /dev/md127 mounted on /mnt.
# mount -v /dev/md/boot /mnt/boot
mount: /dev/md125 mounted on /mnt/boot.
Chrooter dans le système monté
À présent, je peux effectuer un chroot dans mon système monté :
# for fs in dev proc sys run; do
> mount -v --rbind /$fs /mnt/$fs
> done
mount: /dev bound on /mnt/dev.
mount: /proc bound on /mnt/proc.
mount: /sys bound on /mnt/sys.
mount: /run bound on /mnt/run.
# mount --make-rslave /mnt/dev /mnt/proc 2> /dev/null
# chroot /mnt
Retrouver les UUID
Le fichier /etc/fstab de mon système va me fournir l'UUID de la partition
principale :
UUID=b8d06873-0697-4662-b60e-8cabe4163f02 / ext4 defaults 1 1
UUID=54920152-f86b-4786-8520-981dafeeead9 /boot ext4 defaults 1 2
UUID=a54e78e2-81c9-4069-b7bf-e3be532fdfcc none swap defaults 0 0
LABEL=SAUVEGARDE-PC /mnt/backup ext4 noauto,user 0 0
Pour en savoir plus sur les UUID respectives des assemblages RAID, il suffit de
jeter un œil dans le fichier /etc/mdadm.conf :
# mdadm.conf written out by anaconda
MAILADDR root
AUTO +imsm +1.x -all
ARRAY /dev/md/boot level=raid0 num-devices=2 UUID=edefe549:114a41a3:dae05668:...
ARRAY /dev/md/root level=raid0 num-devices=2 UUID=afe36c4e:2b0ad5ac:ec9a4443:...
ARRAY /dev/md/swap level=raid0 num-devices=2 UUID=f57f6c96:4fa8fcae:45750044:...
Reconfigurer GRUB avec les UUID
J'ai toutes les infos pour éditer /etc/default/grub en conséquence :
GRUB_TIMEOUT=5
GRUB_CMDLINE_LINUX="rd.md.uuid=edefe549:114a41a3:dae05668:c82fdcea \
rd.md.uuid=afe36c4e:2b0ad5ac:ec9a4443:3c756240 \
rd.md.uuid=f57f6c96:4fa8fcae:45750044:fb1663fd \
root=UUID=b8d06873-0697-4662-b60e-8cabe4163f02 \
quiet video=1024x768 loglevel=3 mitigations=off"
GRUB_GFXMODE=1024x768
GRUB_GFXPAYLOAD_LINUX=1024x768
Je prends en compte la configuration :
# grub2-mkconfig --update-bls-cmdline -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Adding boot menu entry for UEFI Firmware Settings ...
done
Avertissement de grub2-mkconfig
Si jamais vous vous retrouvez confronté à un avertissement du style
grub2-probe: error: cannot find a GRUB drive for /dev/sdc1 vous pouvez
sereinement l'ignorer. GRUB vous informe tout simplement qu'il n'a pas
l'intention d'ajouter la clé USB du système de secours à la configuration,
ce qui est plutôt une bonne idée.
Et maintenant ?
Je quitte l'environnement chroot :
À ce stade je pourrais très bien démonter l'une après l'autre toutes mes partitions dans le bon ordre. Au lieu de cela, je croise les doigts et je redémarre :
Le système redémarre normalement, et je retrouve mon assemblage RAID intact.
La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.
