Peut-on dupliquer la partition d'amorçage sur un 2e disque?

Support Debian
#1

Bonjour,

(Bookworm)
Partition d’amorçage actuelle:

/boot/efi/EFI/debian/grubx64.efi

2 disques LVM mirroir: (données extraites de sudo fdisk -l)
Le premier:

Périphérique       Début        Fin   Secteurs Taille Type
/dev/nvme0n1p1      2048     976895     974848   476M Système EFI
/dev/nvme0n1p2    976896  157222911  156246016  74,5G LVM Linux
/dev/nvme0n1p3 157227008  235352063   78125056  37,3G LVM Linux
/dev/nvme0n1p4 235352064 2188476415 1953124352 931,3G LVM Linux

Le 2e:

Périphérique       Début        Fin   Secteurs Taille Type
/dev/nvme1n1p1      2048  156250111  156248064  74,5G LVM Linux
/dev/nvme1n1p2 156250112  234375167   78125056  37,3G LVM Linux
/dev/nvme1n1p3 234375168 2187499519 1953124352 931,3G LVM Linux

Afin d’avoir une 2e partition d’amorçage, j’envisage de:

1 créer une partition /dev/nvme1n1p0 de 480M
2 la monter sur /mnt/uefi/
3 y copier le fichier /boot/efi/EFI/debian/grubx64.efi
(avec dd ?)

  • est-ce correct?,
  • devrai-je faire quelque-chose avec grub pour que cette partition d’amorçage de secours fonctionne?
  • sinon existe-t-il une méthode pas trop compliquée à comprendre (adaptée à mes limites de plus en plus étroites) pour générer cet amorçage potentiellement à partir du 2nd disque?
#2

Bonjour @josephtux

C’est plus au niveau du BIOS que vous devez intervenir après avoir dupliqué la partition d’amorçage sur un second disque pour faire fonctionner cette partition d’amorçage et la tester. Dans le Bios, vous pouvez choisir le disque de démarrage de votre choix.

1 J'aime
#3

Merci beaucoup vbreton,

j’en déduis que vous validez la méthode proposée?

#4

Oui, cela me semble cohérent.

#5

encore merci

#6

Récemment j’ai monté un Linux sur un premier disque et un Windows sur un second disque. Je peux booter sur Linux ou Windows via Grub sur le premier disque ou démarrer Windows à partir du BIOS. Ainsi si l’un ou l’autre tombe en panne, j’ai au moins un OS bootable. Bien évidemment, j’aurais pu mettre 2 Linux. J’évite de croiser des partitions entre les deux systèmes, ce que je faisais il y a 11 ans en arrière pour des questions de performance, notamment avec la Swap. On peut toutefois envisager d’avoir deux swap, un sur chaque disque et en utiliser qu’une, l’autre servant de secours et qu’à la maintenance en cas de défaillance.

#7

Si seul ce fichier est présent, alors GRUB n’a pas été installé pour le secure boot (soit explicitement avec grub-install --no-uefi-secure-boot, soit parce que le paquet grub-efi-amd64-signed n’est pas installé).

Une partition ne peut pas avoir le numéro 0.

Pas besoin de dd, cp suffit.

Oui, il faudra l’enregistrer dans les variables de boot EFI avec efibootmgr sinon c’est comme si elle n’existait pas. L’amorçage EFI, ce n’est pas aussi simple que l’amorçage BIOS où on sélectionne le disque avec lequel on veut booter.

Oui : réinstaller GRUB dans le chemin de support amovible des deux partitions afin qu’elles soient amorçables ave ou sans sans variables de boot EFI (fragiles).

grub-install --force-extra-removable --efi-directory=/boot/efi
grub-install --force-extra-removable --efi-directory=/mnt/uefi --bootloader-id=debbackup
1 J'aime
#8

Merci PascalHambourg pour toutes ces précisions. Cependant je ne comprends pas ce qu’est le «support amovible des deux partitions». Est ce que ça désigne la partition d’amorçage de chaque disque?
C’est ce que je crois comprendre de man grub-install traduit par deepl en «emplacement de repli secondaire»:

Lors de l’installation de la version UEFI de GRUB, l’option --removable donnée à grub-instal l installera le chargeur de démarrage dans l’emplacement de repli/secondaire. Alternativement, l’utilisation de l’option --force-extra-removable tentera de l’installer à la fois dans l’emplacement standard d’un système d’exploitation installé et dans l’emplacement de repli/secondaire.

Pourquoi ne pas utiliser --removable si --force-extra-removable est fragile?

#9

Mes informations étaient incomplètes, avec votre éclairage je trouve:

#ls -l /boot/efi/EFI/debian/
total 5960
-rwx------ 1 root root     108  3 nov.   2023 BOOTX64.CSV
-rwx------ 1 root root   87328  3 nov.   2023 fbx64.efi
-rwx------ 1 root root     201  3 nov.   2023 grub.cfg
-rwx------ 1 root root 4199872  3 nov.   2023 grubx64.efi
-rwx------ 1 root root  849616  3 nov.   2023 mmx64.efi
-rwx------ 1 root root  948768  3 nov.   2023 shimx64.efi
#10

La différence entre les deux c’est que --removable , et extra-removable c’est que le premier ne prend en charge que les disque USB, DVD etc, et le second la même chose mais en plus le disque local.

#11

Bonjour @josephtux

C’est pour cela qu’il vaut mieux conserver la structure complète, surtout avec l’EFI !
J’en profite pour ajouter un lien sur la documentation GNU de l’outil parted plus puissant que fdisk car traitant de l’EFI et susceptible de vous intéresser. Elle n’est pas très volumineuse (29 pages dans sa version PDF) permettant une prise en main rapide:
https://www.gnu.org/software/parted/manual/

#12

@PascalHambourg

C’est vrai pour un tel fichier mais il vaut mieux connaître aussi dd dès que l’on touche au démarrage et au partitionnement ! Pour @josephtux, voici un lien utile sur dd: https://doc.ubuntu-fr.org/dd; l’article est facilement compréhensible et susceptible d’apporter des informations complémentaires intéressantes.

#13

dans cette ligne, est-ce que l’ id (debbackup dans votre exemple) est le nom de la partition nouvelle d’accueil (nvme1n1p4)?

Encore merci à tous les deux (j’avais oublié le peu que je savais de grub et j’ignorais tout sur UEFI)

PS
je viens de trouver cette page qui m’a également éclairé, et notamment permis d’explorer l’état actuel de mon système (grub;efi).
https://papy-tux.legtux.org/doc1252/index.html#mozTocId805777

#14

L’option --bootloader-id spécifie l’identifiant qui détermine le nom du répertoire de la partition EFI dans lequel GRUB sera installé et le nom sous lequel il est enregistré dans les variables de boot EFI. Si on laisse le nom par défaut (debian), grub-install supprime l’entrée de boot EFI existante créée pour l’autre disque (c’est pourquoi j’ai écrit une version de grub-install qui n’a pas cet inconvénient).

Mais si GRUB a été installé pour le secure boot comme ici, alors cela peut ne pas fonctionner : certaines versions de l’image signée de GRUB ne fonctionnent correctement que si GRUB est installé dans le répertoire « debian ». Contournement : créer le répertoire debian et y copier le fichier grub.cfg. Autre contournement : laisser le nom par défaut et recréer l’entrée de boot manuellement avec efibootmgr.

Toutefois, l’option --force-extra-removable devrait permettre de lancer GRUB même si l’entrée de boot est manquante.

#15

Non, ça désigne un emplacement spécial dans une partition EFI qui peut être amorcé sans entrée dans les variables de boot EFI. C’est notamment utilisé pour l’amorçage des supports amovibles, d’où le nom.

Je n’ai pas dit que --force-extra-removable est fragile mais que les variables de boot EFI sont fragiles.
Il ne faut pas utiliser --removable parce que cette option est incompatible avec certaines versions de l’image signée de GRUB (bug que j’essaie de faire corriger mais les développeurs sont bornés).

Non, c’est indifférent.

#16

Je ne suis pas trop compétent ici, et je vais raconter une évidence, mais mais si l’objectif est d’avoir deux systèmes Linux « parallèles » sur la même machine, ne risque-t-on pas en bootant sur le second d’avoir des problèmes d’user propriétaire sur tous les fichiers? (qui appartiendrait à « l’user habituel » et pas à « l’user du système de secours »)
Evidemment c’est toujours mieux que de ne plus pouvoir booter en cas de panne, mais j’ai l’impression que la situation serait la même que lorsqu’on crée un « user2 » sur le même système, là encore pour résoudre certains problèmes : user2 a intérêt à être sudoer, car sinon il ne peut rien toucher chez user1…
A moins qu’il n’y ait une astuce diabolique pour cloner les userID…

#17

Bonjour,
ma question n’est pas ici d’avoir deux systèmes, mais suivant un conseil donné ici, puisque mon installation est en raid sur 2 SSD internes, (LVM mirror), il serait logique, en cas de panne d’un SSD que la partition d’amorçage (qui est hors du système LVM) soit également dupliquée sur le 2e SSD.

Plutôt que de copier les fichiers de cette partition, j’envisage plutôt de copier la partition elle-même (avec dd), en espérant que cela suffira à rendre la copie opérante. Je n’ai pas encore bien digéré toutes les infos de cette discussion (et surtout j’ai d’autre taches à faire que de l’administration d’un système qui fonctionne)

Merci pour votre contribution

1 J'aime
#18

La copie avec dd a la particularité de copier l’UUID de système de fichiers, qui est utilisé dans /etc/fstab pour identifier la partition à monter. On se retrouve donc avec deux partitions qui ont le même UUID, avec les conséquences suivantes :

  • il n’est pas possible de monter simultanément les deux partitions par UUID sur deux points de montage différents
  • n’importe laquelle des deux partitions est susceptible d’être montée au démarrage
  • si un SSD est HS, la partition EFI de l’autre sera montée sans provoquer d’erreur.

Dans le cas d’un formatage + copie classique du contenu de la partition EFI, les deux partitions auront des UUID différents et pourront être montées simultanément sur deux points de montage différents. Mais avec les options de montage par défaut, si une partition est manquante au démarrage (SSD HS), alors cela provoquera une erreur et l’entrée dans le mode dépannage. Pour éviter cela, il faut ajouter l’option de montage « nofail ». Il y aura toujours une erreur et un délai, mais le démarrage se poursuivra normalement.

Comme dit précédemment, cela suffira seulement si GRUB est installé dans le chemin de support amovible de la partition EFI. Sinon l’amorçage dépend de l’entrée de boot EFI qui ne pointe que sur la partition EFI d’origine.

2 J'aime
#19

C’est bien ce que je cherche

il n’est pas possible de monter simultanément les deux partitions par UUID sur deux points de montage différents

C’est sans intérêt pour moi, mais est-ce que ça peut poser un problème?

Il faudra indiquer un point de montage de secours sur le 2e disque ( dans /etc/fstab ? avec nofail sur le 1er?) pour le cas ou le 1er tomberait en rade.

#20

Non.

Non justement, si le 1e disque tombe en panne la partition EFI du 2e disque sera montée sur /boot/efi puisqu’elle a le même UUID que celle du 1e disque. Quand les deux disques sont opérationnels, la partition de l’un des deux sera montée, pas forcément celle du 1e disque.

1 J'aime