Migration raid 1 de MBR vers GPT

Support Debian
, ,
Tags: #<Tag:0x00007f50a5265140> #<Tag:0x00007f50a5264df8> #<Tag:0x00007f50a5264970>
#1

Migration raid 1 de MBR vers GTP

Bonjour,

J’ai actuellement 2 disques durs de 2 To, en raid 1 logiciel via mdadm, sur un serveur en production, avec une Debian 8.5 installé dessus.

cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb5[0] sda5[2]
      8379328 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sdb1[0] sda1[2]
      1944995648 blocks super 1.2 [2/2] [UU]

Les disques sont formatés comme cela :

Disque /dev/sdb : 1,8 TiB, 2000397852160 octets, 3907027055 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Type d’étiquette de disque : dos
Identifiant de disque : 0x00056e61

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 3890255871 3890253824 1,8T fd Linux raid autodetect
/dev/sdb2 3890257918 3907024895 16766978 8G 5 Extended
/dev/sdb5 3890257920 3907024895 16766976 8G fd Linux raid autodetect

Jusqu’ici tout va bien. Je souhaite passer à des disques durs de 6 To. Je pensais faire comme pour l’augmentation précédente (remplacement DD1, synchro, remplacement DD2, synchro, grow).
Mais là le problème est que le passage au dessus de 2 To implique de passer de paritions MBR à GTP, et là je suis un peu perdu, surtout pour la gestion du boot. Je cherche une solution qui limite les temps de coupures si possible.

J’ai donc déconnecté un des 2 DD de 2 To, remplacé par un 6 To, et j’ai voulu le formater de la même manière, ce qui n’est pas possible vu sa taille. Je l’ai donc formaté comme ceci :

Disk /dev/sda: 11721045168 sectors, 5.5 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 9BE6E183-22BA-4182-8C9C-07469589B7C8
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 11721045134
Partitions will be aligned on 8-sector boundaries
Total free space is 1167 sectors (583.5 KiB)

Number Start (sector) End (sector) Size Code Name
1 2048 11704268799 5.5 TiB 8300
2 11704268800 11721043967 8.0 GiB 8200
3 34 2047 1007.0 KiB EF02

Puis j’ai ajouté les partitions 1 et 2 au raid et resynchro. Quelques heures après, j’ai bien mon raid 1 à nouveau fonctionnel, et le serveur boot avec les 2 disques durs.

cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb5[0] sda2[2]
8379328 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sdb1[0] sda1[2]
1944995648 blocks super 1.2 [2/2] [UU]

Maintenant si je débranche l’ancien disque dur (sdb), le serveur ne boot plus. J’ai bien fait un grub-install /dev/sda, mais là sur l’install de Grub2 pour booter sur le disque GTP, tout en concervant le raid bootable, je suis perdu. Une idée de la marche à suivre pour faire fonctionner tout ça en attendant de migrer l’autre disque dur ?

Merci !

#2

GPT, pas GTP.

Que se passe-t-il exactement au boot avec le nouveau disque seul ?

Tu as globalement fait ce qu’il fallait : création d’une partition BIOS boot (ef02) pour GRUB au début du disque et exécution de grub-install sur le nouveau disque /dev/sda. Tu peux exécuter la commande bootinfoscript du paquet boot-info-script pour vérifier l’installation de GRUB sur /dev/sda.

Un bémol cependant : si /dev/md1 contient la racine ou /boot, j’aurais aussi mis sa partition membre au début du disque par précaution car certains BIOS sont incapables d’adresser les disques au delà de 2 Gio (c’est clairement un bug, pas une limite spécifiée). Mais si GRUB ne se lance pas du tout, le problème est ailleurs.

J’aurais aussi créé une partition système EFI par anticipation au cas où le système devrait booter en mode UEFI.

Si le BIOS voit le disque mais ne trouve pas de disque de boot, cela peut être soit parce qu’il est configuré pour ne chercher à booter que sur le disque qui a été retiré et pas sur le disque restant.

Un autre bug constaté avec certains BIOS est qu’ils ne peuvet amorcer un disque que si son MBR contient une partition avec le drapeau “boot”. Or par défaut la partition GPT (ee) factice du MBR protecteur d’une table de partition GPT n’a pas cet indicateur. Dans ce cas, il faut l’activer avec parted

parted /dev/sda disk_set pmbr_boot on

ou avec fdisk en forçant l’utilisation de la table de partition MBR/DOS

fdisk -t dos /dev/sda a w

PS : quand tu fais tes tests de boot avec un seul disque et que ça marche, ne va pas au delà de l’initramfs en ajoutant break à la ligne de commande du noyau. Sinon, tu risque de provoquer une desynchronisation puis une reconstruction du RAID qui prend pas mal de temps avec des disques aussi gros.

#3

Merci pour ta réponse détaillée.

Au boot avec uniquement le nouveau disque, grub se lance et me dit qu’il ne trouve pas le disque avec l’UUID : [UUID de md0], et il me propose uniquement de passer en mode grub rescue, je n’ai pas le menu de sélection des options de boot.
Du coup j’imagine que ça doit un problème de configuration de grub. Je vais essayer de trouver des explications là dessus, mais je trouve la config de Grub assez complexe.

J’aurais aussi créé une partition système EFI par anticipation au cas où le système devrait booter en mode UEFI.

Du coup j’aurais 2 partitions de boot (une BIOS et une EFI) sur chaque disque ?

PS : quand tu fais tes tests de boot avec un seul disque et que ça marche, ne va pas au delà de l’initramfs en ajoutant break
à la ligne de commande du noyau. Sinon, tu risque de provoquer une
desynchronisation puis une reconstruction du RAID qui prend pas mal de
temps avec des disques aussi gros.

Je n’ai pas compris cette partie là. Où est-ce que je dois ajouter le break pour que le système ne se lance pas ?

Merci !

#4

C’est bien l’UUID de md0 ? Dans ce cas j’en déduis que md0 est la racine, et md1 doit être le swap.
Est-ce l’UUID de l’ensemble RAID ou l’UUID du système de fichiers qui est dedans ? (cf. sortie de blkid)

Qu’affichent les commandes “ls” et “set” dans le shell grub rescue ?

A la ligne de commande du noyau dans l’entrée de menu de GRUB. “e” pour éditer, déplacer le curseur à la fin de la ligne commençant par “linux” et ajouter “break” (attention QWERTY : a <-> q). Ce n’est pas persistant, donc à refaire à chaque essai.

#5

Voici l’erreur exacte au démarrage avec uniquement le nouveau disque :
error: disk ‘mduuid/84c8f5730e5d69b6638ff30130fa2acb’ not found.
Entering rescue mode…
grub rescue>

Et le résultat de blkid :
/dev/sda1: UUID=“84c8f573-0e5d-69b6-638f-f30130fa2acb” UUID_SUB=“3fe94b95-af10-8a1e-d863-ad7c1264ed95” LABEL=“Citadel:0” TYPE=“linux_raid_member” PARTUUID=“a22825a8-a76e-4ee0-aed5-ec0ae3e63d3c”
/dev/sda2: UUID=“0e158509-12eb-2c40-fc79-117e0f918808” UUID_SUB=“fd7a21e2-dd0d-7e3d-bdb8-d515a0dec559” LABEL=“Citadel:1” TYPE=“linux_raid_member” PARTUUID=“73378983-078f-48de-bbba-8e62e5d8af3e”
/dev/sdb1: UUID=“84c8f573-0e5d-69b6-638f-f30130fa2acb” UUID_SUB=“795804ba-c021-fb60-83c7-4d27b0f18291” LABEL=“Citadel:0” TYPE=“linux_raid_member” PARTUUID=“00056e61-01”
/dev/sdb5: UUID=“0e158509-12eb-2c40-fc79-117e0f918808” UUID_SUB=“5cfed459-6cba-e9b0-76a1-70ee95e58bf4” LABEL=“Citadel:1” TYPE=“linux_raid_member” PARTUUID=“00056e61-05”
/dev/md0: UUID=“ab2626c4-d4f5-4ae4-9a0a-9ab0d116b5d3” TYPE=“ext4”
/dev/md1: UUID=“53481996-6d8c-4724-a5cc-c1a7dd756fd7” TYPE=“swap”
/dev/sda3: PARTUUID=“840e53f0-6dfe-4d4a-a7a7-8f8cd5ca6c17”

Il s’agit donc en fait de l’UUID de sda1 et de sdb1.

Pour les commandes de grub rescue, je ne peux pas les lancer facilement, vu qu’il faut que je coupe le serveur, qui est en production :-/

#6

C’est l’UUID de l’ensemble RAID, qui sert à reconnaître ses membres. Donc soit GRUB n’a pas vu la partition, soit il n’a pas réussi à activer l’ensemble RAID à partir de cette seule partition. La sortie de “ls” permettra d’en savoir plus. La partition RAID de ce disque (sda1) est bien marquée active dans /proc/mdstat ?

GRUB pourrait ne pas voir les partitions si le module pour lire la table de partition au format GPT (part_gpt) n’a pas été inclus dans la core image installée sur ce disque par grub-install. Normalement il devrait être inclus puisque l’un des membres de l’ensemble RAID recherché est sur un disque au format GPT. S’il manque des modules, on peut forcer leur inclusion avec une option de grub-install.

#7

grep part_gpt * dans /etc/grub.d/ ne me renvoie aucune ligne, et il n’est pas présent non plus dans le fichier /etc/default/grub.

J’y ai ajouté :
GRUB_PRELOAD_MODULES=“part_gpt”

Et au cas où j’ai fait un
grub-install --modules=part_gpt /dev/sda

Je teste le boot avec cette nouvelle installation dès que je peux.

#8

Cela ne me choque pas. Le module a plus de chances d’être présent dans /boot/grub/grub.cfg.

#9

Ça a bien fonctionné, il manquait effectivement le module part_gpt.

Merci beaucoup :slight_smile: