grub avec UEFI

Demande d'aide : c'est ici.
Répondre
marcastro
Membre actif
Membre actif
Messages : 718
Inscription : 22 avr. 2016, 12:05
Localisation : variable
Status : Hors-ligne

en installant en mode UEFI où vont s'écrire le chargeur et la table des partitions; dans les 512 premiers octets du disque comme dans le mode legacy ? ou ailleurs?
sur le forum depuis 2007.
sid et bookworm avec xfce
PascalHambourg
Contributeur
Contributeur
Messages : 876
Inscription : 05 août 2016, 20:25
Status : Hors-ligne

La position de la table de partition n'a rien à voir avec le mode d'amorçage EFI ou legacy (BIOS). L'amorçage EFI peut utiliser indifféremment une table de partition au format DOS, dont les 4 entrées de partitions principales sont inscrites dans le MBR (1e secteur du disque), soit une table de partition au format GPT dont les 128 entrées de partitions sont inscrites dans des secteurs situés après le MBR.

En mode EFI, le MBR ne contient plus de programme d'amorce. Les chargeurs sont installés dans une partition spéciale de type "partition système EFI" formatée en FAT. Avec Debian, cette partition est montée sur /boot/efi et le premier étage de GRUB s'installe en tant que simple fichier /boot/efi/EFI/debian/grubx64.efi (si firmware x86 64 bits). Le reste de GRUB est contenu dans /boot/grub comme d'habitude.
marcastro
Membre actif
Membre actif
Messages : 718
Inscription : 22 avr. 2016, 12:05
Localisation : variable
Status : Hors-ligne

En mode EFI, le MBR ne contient plus de programme d'amorce. Les chargeurs sont installés dans une partition spéciale de type "partition système EFI" formatée en FAT. Avec Debian, cette partition est montée sur /boot/efi et le premier étage de GRUB s'installe en tant que simple fichier /boot/efi/EFI/debian/grubx64.efi
donc si j'ai besoin de recopier le chargeur de boot il faut recopier le contenu de /boot/efi/EFI/debian/grubx64.efi? et la table des partitions je la sauvegarde comment?
sur le forum depuis 2007.
sid et bookworm avec xfce
PascalHambourg
Contributeur
Contributeur
Messages : 876
Inscription : 05 août 2016, 20:25
Status : Hors-ligne

Pour quoi faire, la copie ?
Pour info il y a déjà une copie du premier étage de GRUB EFI dans /boot/grub/x86_64-efi/core.efi.

Pour sauvegarder la table de partition on fait comme d'habitude, avec sfdisk ou sgdisk (du paquet gdisk) pour une table GPT (les versions récentes - depuis stretch - de fdisk et sfdisk permettent aussi de le faire).
Pour quoi faire, et comment faisais-tu ?
marcastro
Membre actif
Membre actif
Messages : 718
Inscription : 22 avr. 2016, 12:05
Localisation : variable
Status : Hors-ligne

jusqu'à maintenant je fonctionne en mode non UEFI et je sauvegarde avec clonezilla; dans la sauvegarde de chaque partition il y a le mbr du disque sur lequel est installé la partition ; donc sur les 512 premiers octets du disque il ya les 446 octets du chargeur et les 66 octets suivants contiennent la table de partitions msdos(je n'utilise pas GPT). Donc, dans le cas où je veux recopier le grub il me suffira de recopier les 446 premiers octets de la sauvegarde du mbr.Idem pour la table des partitions. Mais en mode UEFI ça marche comment vu que le mbr n'existe plus ,comment je pourrais restaurer grub au cas où? Pour moi ces questions restent pour le moment assez nébuleuses vu mon ignorance de UEFI; mais un jour ou l'autre je vais devoir y passer alors j'essaie de comprendre.
sur le forum depuis 2007.
sid et bookworm avec xfce
PascalHambourg
Contributeur
Contributeur
Messages : 876
Inscription : 05 août 2016, 20:25
Status : Hors-ligne

Houla, il faut tordre le cou à quelques idées reçues sur le MBR...

1) La table de partition DOS du MBR ne contient que les 4 entrées de partitions primaires (n° 1 à 4). S'il y a une partition étendue, les entrées de ses partitions logiques (n° 5 et suivantes) ne sont pas dans le MBR. Dans ce cas, sauvegarder le MBR ne suffit pas à sauvegarder la table de partition complète.

2) Les premiers 440 octets du MBR (pas 446 car les octets 440 à 443 contiennent l'identifiant/signature du disque) ne contiennent qu'une toute petite partie de GRUB appelée "boot image". Sur les disques au format DOS, la seconde partie de GRUB, plus volumineuse, appelée "core image", est généralement située dans les secteurs situés entre le MBR et le début de la première partition. Cet espace hors de toute partition, parfois appelé "embedded area" ou "post-MBR gap", n'est pas officiellement alloué et d'autres programmes que GRUB peuvent l'utiliser, notamment des gestionnaires de licence pour y "cacher" des informations. La core image de GRUB ne peut elle-même pas faire grand-chose sans lire le reste de GRUB (modules, configuration du menu, langues, polices, fond d'écran...) qui est composé de fichiers installés dans le répertoire /boot/grub.
J'ignore comment clonezilla gère cette zone, mais sauvegarder le MBR seul ne suffit pas à pouvoir restaurer GRUB.

3) Le MBR existe toujours en EFI, mais il ne contient plus de programme d'amorce (donc plus de boot image pour GRUB). En revanche il contient toujours une table de partition principale au format DOS ou le MBR protecteur d'une table de partition au format GPT.
La core image de GRUB devient un fichier normal dans la partition système EFI (FAT) qui est montée sur /boot/efi, qu'on peut sauvegarder facilement comme n'importe quels fichiers et partitions. Par contre cela ne suffit pas forcément pour cloner le système vers une autre machine, car un chargeur d'amorçage installé ailleurs que dans le chemin de support amovible (chargeur par défaut) de la partition EFI doit être déclaré dans la mémoire non volatile du firmware UEFI de la machine pour être exécuté. Par défaut Debian n'installe pas GRUB à cet emplacement.
marcastro
Membre actif
Membre actif
Messages : 718
Inscription : 22 avr. 2016, 12:05
Localisation : variable
Status : Hors-ligne

houlala! c'est trop compliqué pour moi tout ça; mais je veux d'abord te répondre sur le point de la restauration du chargeur de boot tel que ça fonctionne chez moi pour le moment, càd sans UEFI
Prenons l'exemple du disque /dev/sda; clonezilla sauvegarde entre autre le mbr de sda sous la forme d'un fichier mbr-sda de 512 octets. Partant de là je peux restaurer mon grub, et je l'ai fait bien des fois, en utilisant la commande dans le bon répertoire:

dd if=mbr-sda of=/dev/sda bs=446 count=1

et grub est remis en place tel qu'il fut sauvegardé.

Pour la table de partition je sais que seules les partitions primaires sont prises en compte mais pas la partition étendue si elle est présente.Mais dans la discussion qui nous concerne ne parlons pas de la table de partitions concentrons nous plutôt sur le chargeur de boot. Alors concernant ce chargeur je vais poser une question plus simple à savoir si la méthode de réinstallation de grub2 telle que décrite dans notre wiki reste toujours valable dans le cas de UEFI, particulièrement la méthode du chroot qui est celle que je pratique.

la méthode avec un chroot: https://wiki.debian-fr.xyz/R%C3%A9insta ... _un_chroot
sur le forum depuis 2007.
sid et bookworm avec xfce
PascalHambourg
Contributeur
Contributeur
Messages : 876
Inscription : 05 août 2016, 20:25
Status : Hors-ligne

Mais non, ce n'est pas trop compliqué. Deux formats de table de partition (DOS et GPT), deux modes d'amorçage (BIOS et EFI), 4 combinaisons possibles.
marcastro a écrit :grub est remis en place tel qu'il fut sauvegardé.
Seule la "boot image" de GRUB, qui est dans le MBR, est restaurée. Mais cela ne restaure pas la core image si elle a été endommagée. Cela suffit par exemple si le MBR a été écrasé par Windows (qui n'utilise pas la zone post-MBR), mais pas si GRUB a été écrasé par un autre GRUB qui utilise la zone post-MBR.
marcastro a écrit : je vais poser une question plus simple à savoir si la méthode de réinstallation de grub2 telle que décrite dans notre wiki reste toujours valable dans le cas de UEFI, particulièrement la méthode du chroot qui est celle que je pratique.
Concernant la méthode du chroot, il faut y ajouter le montage de la partition EFI sur /boot/efi (du système chrooté), et on peut préciser que le périphérique spécifié en argument de grub-install est inutile et ignoré puisque le MBR n'est pas utilisé. Et bien sûr, le système à partir duquel on fait le chroot doit avoir été amorcé en mode EFI. A part cela, il me semble que la méthode reste valable.

PS : la gueule de la table de partition en exemple fait quand même un peu peur...
Répondre