Création RAID 1 sur Debian 11 déjà installée

Support Debian
#1

Bonjour,

J’ai une machine déjà installée, avec des application et tout ça sur deux partitions:

/dev/sda1 => /boot/efi
/dev/sda2 => LVM (avec /, /home, /var, /var/log, /var/log/audit, /var/tmp, /tmp et swap)

J’ai dessus un disque SSD 1To et un disque nvme 1To.
Le système est actuellement sur le SSD.
j’ai copié les partitions du disque /dev/sda vers le disque /dev/nvme0n1 à l’aide de la commande

sfdisk -d /dev/sda | sfdisk --force /dev/nvmen0

j’ai créé deux array /dev/md0 et /dev/md1, dans lesquels je n’ai pas inclus les partitions /dev/sda, mais uniquement les partitions /dev/nvmen0p1 et /dev/nvmen0p2.
j’ai ajouté /dev/nvme0n1p2 dans les volume physique de mon LVM.
j’ai ajouté mon volume physique dans mon volume group existant.
J’ai déplacé le volume physique existant vers le nouveau:

pvmove /dev/sda2 /dev/nvme0n1p2

j’ai ensuite supprime /dev/sda2 du volume group puis du groupe physique.
Enfin, j’ai ajouté /dev/sda2 à l’array correspond /dev/md1.
Depuis il tourne pour synchroniser les deux arrays.
Jusqu’ici tout à l’air d’aller. le système est toujours en train de tourner, les applications aussi.

Toutes les 1,0s: cat /proc/mdstat                                                                                                                                                     dsrvbull01: Fri Sep 24 17:43:24 2021

Personalities : [raid1]
md1 : active raid1 sda2[2] nvme0n1p2[1]
      976336896 blocks super 1.2 [2/1] [_U]
      [==========>..........]  recovery = 53.1% (518732288/976336896) finish=38.3min speed=198791K/sec
      bitmap: 1/8 pages [4KB], 65536KB chunk

md0 : active raid1 nvme0n1p1[1]
      290816 blocks super 1.2 [2/1] [_U]

unused devices: <none>

La partie LVM est la plus facile.

Maintenant, je dois faire l’équivalent pour la partition /dev/sda1, qui elle concerne uniquement /boot/efi.
Et là je sèche un peu.
Je crois qu’il me suffirait de formater la partition /dev/nvme0n1p1 en EFI.
Puis juste à ajouter /dev/sda1 dans /dev/md0 pour que la synchronisation se fasse de /dev/sda1 vers /dev/nvme0n1p1, mais je ne suis pas sur.

sachant qu’ensuite, il me faut modifier le /et/fstab et ne pas oublier un update-grub pour prendre en compte le changement (a moins que je ne doive réinstaller le grub?)

#2

Cette commande n’a pas copié les partitions mais seulement la table de partition.
Dans le cas d’une table au format GPT, il me semble que cela clone les UUID de partition (PARTUUID), ce qui peut avoir un impact sur l’amorçage EFI : l’entrée d’amorçage EFI créée par GRUB fait référence à l’UUID de la partition système EFI, s’il y a deux partitions avec cet UUID le firmware UEFI peut réagir de façon imprévue.

Inconvénient : une double copie des données du PV, et une resynchronisation « aveugle » du RAID qui va copier et marquer comme utilisés tous les blocs des SSD, même ceux qui ne contiennent pas de données. Quand la synchronisation sera terminée, tu pourras passer fstrim sur les systèmes de fichiers montés pour TRIMer les blocs inutilisés. Par contre s’il y a de l’espace libre dans le VG je ne connais pas de commande LVM pour le TRIMer ; le seul moyen que je connais consiste à créer un LV factice occupant tout l’espace libre du VG (100%FREE) et à utiliser blkdiscard dessus, ou bien simplement le supprimer si issue_discards = 1 dans /etc/lvm/lvm.conf.

Bienvenue dans la jungle. Amorçage UEFI et RAID logiciel ne font pas bon ménage.

Ton doute est fondé.
Ces deux actions ne sont pas cohérentes. /dev/nvme0n1p1 est déjà « formatée » comme membre de l’ensemble RAID /dev/md0 ; si tu la reformates en partition système EFI (FAT) elle perdra ses attributs de membre RAID. Quant à la synchronisation, elle se fera du membre actuel /dev/nvme0n1p1 vers le nouveau membre /dev/sda1. Tu perdras donc à la fois le contenu de /dev/sda1 et le membre /dev/nvme0n1p1 dans une telle opération.

Avant de poursuivre, tu dois te poser une question : as-tu besoin de mettre en place un amorçage redondant ?

Concernant la mise en RAID logiciel d’une partition EFI, il y a deux problèmes :

  • le firmware UEFI ne reconnaît pas le format RAID de Linux. Une partition système EFI doit être une partition « simple ». On peut contourner ce problème avec un ensemble RAID 1 au format 1.0 qui place le superblock à la fin de la partition et non au début comme le format par défaut 1.2. Ainsi le firmware pourra reconnaître chaque partition membre comme une partition normale.

  • grub-install ne peut pas enregistrer un ensemble RAID dans les entrées d’amorçage EFI de la NVRAM. On peut contourner le problème en n’enregistrant pas d’entrée d’amorçage (--nvram) et en installant GRUB dans le « chemin de support amovible » de la partition EFI (--force-extra-removable) si le firmware UEFI le supporte, à pérenniser via dpkg-reconfigure grub-efi-amd64. Les partitions doivent avoir le type « EFI » dans la table de partition.

Une autre méthode consiste à créer deux partitions EFI indépendants (non RAID), à en monter une sur /boot/efi et synchroniser l’autre manuellement avec grub-install --efi-directory=xx après chaque mise à jour de grub-efi-amd64. Inconvénient : avec certains firmwares UEFI, cela ne crée qu’une seule entrée d’amorçage « debian » et remplace la précédente au lieu d’en ajouter une seconde, donc pas de redondance (sauf peut-être si les deux partitions ont le même PARTUUID mais je n’ai pas testé). Contournement : installer GRUB dans le chemin de support amovible comme précédemment.

Dernière possibilité si le firmware UEF I le supporte : basculer l’amorçage en mode BIOS/legacy. Le paquet grub-pc supporte de base l’installation de GRUB dans les MBR de plusieurs disques, il suffit de les spécifier à l’installation. On peut préparer les disques pour les deux modes d’amorçage.

1 J'aime
Grappe redondante non formelle pour partition EFI sur plusieurs disques
#3

Et bien en résumé, cela s’est avéré très facile:

j’ai créé un /dev/md0 pour /boot/efi, utilisant la partition /dev/vnmen1p1 et /dev/sda1 missing
j’ai créé un /dev/md1 pour LVM utilisation la partition /dev/nvme0n1P2 et /dev/sda2 missing.
j’ai ajouté /dev/md1 en physical volume, puis le physical volume dans le volume group.
j’ai ensuite ajouté /dev/sda2 dans le raid /dev/md1.
Les données on été dupliquées de /dev/sda2 vers /dev/nvme0n1p2.
Ensuite retrait de /dev/sda2 (volume group ET physical group)
j’ai umount /boot/efi
puis créé /dev/md0, avec mkfs.vfat /dev/md0

mdadm -C /dev/md0 --level=1 -n 2 --metadata=1.0 /dev/sda1 /dev/nvme0n1p1
mkfs.vfat /dev/md0

le level est important pour pouvoir y mettre le /boot/efi

j’ai modifié l’entrée de /etc/fstab avec l’uuid de /dev/md0
j’ai utilisé la commande suivante pour la reinstallation de grub:

dpkg-reconfigure -p low grub-efi-amd64

Lors de la reconfiguration, j’ai dit non au chemin de support amovible.
puis un simple

grub-install

Et c’est terminé.
j’ai redemérré le système, et tout fonctionne corectement, avec un RAID qui prend en compte le /boot/efi et un autre tout le système en LVM.

Oui mauvaise expression de ma part, on parle bien effectivement de la table des partitions.
je n’ai pas utilisé cette commande sur la partie /boot/efi mais uniquement sur le LVM.

je n’ai pas eu de marquage des blocs utilisé sur la totalité semble-t-il, je n’ai pas un taux d’utilisation à 100% mais celui normal de l’utilisation de mes données.

C’est clair, il y aurait là d’ailleurs un effort à faire sur ce point par les développeurs concernés.

en fait, j’ai créé le RAID 1, j’ai formaté celuici en VFAT, re reinstallé le grub et c’est plus simple.

C’est exactement( ce que j’ai fait, dans la commande avec level=1, et dans le dpkg-reconfigure.
et j’ai zappé le NVRAM et le support amovible.
Après redémarrage tou va bien :slight_smile:

OS............: Debian GNU/Linux 11 (bullseye) x86_64
 ,$$P'              `$$$.     Host..........: 4X4 BOX
',$$P       ,ggs.     `$$b:   Kernel........: Linux 5.10.0-8-amd64
`d$$'     ,$P"'   .    $$$    Uptime........: 22 mins
 $$P      d$'     ,    $$P    Packages......: 1726 (dpkg)
 $$:      $$.   -    ,d$$'    Shell.........: bash 5.1.4
 $$;      Y$b._   _,d$P'      Resolution....: 1280x1024
 Y$$.    `.`"Y$$$$P"'         Terminal......: run-parts
 `$$b      "-.__              -------------------------
  `Y$$                        CPU...........: AMD Ryzen 3 4300U with Radeon Graphics (4) @ 2.700GHz [49.6°C]
   `Y$$.                      GPU...........: AMD ATI 05:00.0 Renoir
     `$$b.                    GPU Driver....: amdgpu
       `Y$$b.                 ----------------------
          `"Y$b._             Memory........: [===============] 740MiB / 31526MiB (2%)
              `"""            CPU Usage.....: [===============] 0%
                              Disk.......... (/).............: [-----==========] 7.3G / 23G (34%)
                              Disk.......... (/home).........: [-==============] 390M / 4.6G (9%)
                              Disk.......... (/tmp)..........: [===============] 76K / 1.8G (1%)
                              Disk.......... (/var)..........: [-==============] 2.0G / 23G (9%)
                              Disk.......... (/var/log)......: [-==============] 640M / 9.1G (8%)
                              Disk.......... (/var/log/audit): [===============] 13M / 4.6G (1%)
                              Disk.......... (/var/tmp)......: [===============] 72K / 1.8G (1%)
                              ------------------------------------------------------------