Partition de démarrage EFI et partition de biosgrub

Pourquoi en ai-je besoin? J'ai installé Ubuntu sous un UEFI non (master boot record) et j'ai installé Ubuntu sans 'biosgrub' et cela fonctionne très bien, alors que d'autres fois on me demande de faire une partition 'biosgrub'. Je n'ai aucune idée pourquoi parfois j'en ai besoin et d'autres non (ils ont tous deux été sur le même système).

Et la même chose se produit lorsque j'utilise UEFI (GUID Partition Table). La seule différence est qu'on me demande de faire une «partition de démarrage EFI», mais comme pour le «biosgrub», parfois on me demande de le faire et parfois on ne me demande pas de le faire.

Pour mon installation actuelle, on m'a demandé d'en faire une, mais je ne l'ai pas fait et mon système fonctionne bien. Il n'y a aucun changement dans le système, le même matériel, le BIOS, etc.

Il y a quatre conditions (BIOS contre EFI et MBR contre GPT), mais deux d'entre elles ont des besoins identiques (et l'une d'entre elles est extrêmement rare):

• Sur un ordinateur BIOS traditionnel avec une table de partition MBR traditionnelle, le code exécutable de GRUB se répand comme des spaghettis jetés par un bébé. Certains d'entre eux se trouvent dans la section du code de démarrage du MBR, d'autres dans des secteurs post-MBR qui ne sont pas officiellement alloués, et d'autres dans la /bootpartition Linux . C'est un vrai gâchis, et cela ne fonctionne que parce que les développeurs ont eu littéralement des décennies pour créer des hacks intelligents et résoudre (presque) tous les problèmes.
• Sur un ordinateur BIOS traditionnel avec une nouvelle table de partition GUID (GPT), le code GRUB est similaire à celui du cas précédent; cependant, les secteurs immédiatement après le MBR ne sont pas non attribués; ils sont utilisés par le GPT lui-même. GPT n'offre aucun endroit analogue pour GRUB à détourner, donc les développeurs de GRUB se sont installés sur la partition de démarrage du BIOS (qui GParted et partedidentifie par un bios_grubindicateur) pour contenir le code qui irait dans les secteurs post-MBR sur un disque MBR. C'est en fait plus sûr et plus propre que l'approche MBR, car elle sert à protéger le code GRUB d'autres programmes qui pourraient essayer d'utiliser cet espace non alloué.
• Sur un ordinateur équipé d'un EFI plus récent plutôt que d'un BIOS, les chargeurs de démarrage ne sont pas stockés dans le MBR, dans les secteurs post-MBR officiellement non alloués ou dans les partitions de démarrage du BIOS; au lieu de cela, les chargeurs de démarrage résident en tant que fichiers ordinaires sur une partition FAT connue sous le nom de partition système EFI (ESP) . ( Confusément, les installateurs Debian et Ubuntu se réfèrent à l'ESP sous le nom de "partition de démarrage EFI", mais ce nom n'est pas standard. GParted et partedidentifie l'ESP comme ayant son "bootflag ", bien que cette terminologie signifie quelque chose de complètement différent sur les disques MBR.) Un ESP peut exister sur un disque GPT ou un disque MBR, mais le premier est beaucoup plus courant sur les ordinateurs EFI. L'approche EFI est beaucoup plus sûre et beaucoup plus flexible que l'approche BIOS, car elle ne cache pas le code brut dans des endroits étranges; les chargeurs de démarrage résident dans des fichiers, tout comme les programmes de niveau OS. Cela les rend plus faciles à identifier et à manipuler. (OTOH, EFI stocke également des données sur les chargeurs de démarrage en NVRAM, ce qui crée un deuxième point d'échec dans le processus de démarrage. La nouveauté d'EFI signifie également qu'il n'est pas aussi bien testé, ce qui explique une multitude de problèmes spécifiques à EFI.)

GhostMotleyX, votre commentaire sur la réponse de LiveWireBT est d' avis que la "meilleure" façon d'installer est le BIOS / MBR. C'est subjectif, bien sûr, mais je ne suis pas d'accord avec cette évaluation. L'approche BIOS / MBR est la moins sûre et la plusmaladroite des trois approches que je viens de décrire. L'approche EFI est l'approche la plus sûre et la plus flexible. Je soupçonne que vous êtes accroché au fait que des partitions distinctes sont requises pour les approches GRUB / GPT et EFI, mais ce n'est pas un gros problème. Mis à part lors de la configuration du système ou de la maintenance des partitions, ces partitions seront pratiquement invisibles pour vous, et elles vous donneront beaucoup de flexibilité. Contrairement à MBR, GPT n'est pas limité à quatre partitions principales, vous n'avez donc pas besoin de thésauriser vos partitions primaires comme un lutin thésaurisant son or.

Vous devez créer une partition biosgrub sur un disque partitionné GPT lors de la configuration du démarrage hérité ou une partition de démarrage EFI (pour les disques partitionnés GPT ou MBR) lors de la configuration du démarrage UEFI.

• GRUB nécessite une partition de démarrage du BIOS (2 Mio, pas de système de fichiers, EF02tapez le code dans gdisk ou l'indicateur bios_grub dans GNU Parted) dans les systèmes du BIOS pour incorporer son core.imgfichier en raison du manque d' espace d'intégration post-MBR dans les disques GPT . [...]

^{https://wiki.archlinux.org/index.php/GPT#Bootloader_Support}

Je donnerai un point / motif supplémentaire pour avoir les deux, EFI et BIOS grub.

Clé USB pour démarrer une boucle Live SystemRescueCD.iso à partir de Grub2.

Pourquoi? Réponse simple: il démarrera sur de nombreux PC, certains ont UEFI, certains n'ont que 32 BIOS anciens, etc.

Motif vraiment complexe: utilisez si possible du matériel avancé (UEFI).

Échantillon réel d'utilisation en direct:

• Clé USB (formatée en mode GPT) avec quatre partitions
• Première partition (visible depuis Windows 7 et supérieur) sur NTFS avec le reste de la taille de la clé USB
• Deuxième partition pour Grub2 et fichier SystemRescueCD.iso avec au moins 1 Go (mieux si 2 Go pour que vous puissiez transporter deux versions de SystemRescueCD.iso en même temps, juste pour tester la nouvelle version avant de remplacer l'ancienne), j'utilise normalement le système de fichiers Ext4 pour ça
• Troisième partition pour EFI (ce que Windows appelle ESP) formatée en Fat32 avec au moins 512 Mo (j'ai vu certains PC qui, s'ils utilisent moins, ne montrent pas la clé USB comme support de démarrage)
• Quatrième partition pour BIOS_Grub (pas de format, mais effacée lors de la création)

Une chose importante: j'ai vu un LG USB 8GiB strict (un que je possède) qui refuse d'être répertorié sur un démarrage PC UEFI physique si les partitions ne sont pas alignées sur des cylindres, mais être vu sur d'autres PC UEFI et également sur VirtualBOX avec démarrage UEFI mode activé ... lors du partitionnement s'il est aligné sur MiB, il utilise tout l'espace, pas d'espace non partitionné proche de 1 Mo à la fin, mais lorsqu'il est aligné sur des cylindres, le dernier MiB incomplet n'est pas utilisé ... si je fais un partitionnement MiB en gardant cela à l'esprit (en d'autres termes, je fais un alignement manuel des cylindres) cela fonctionne, mais comme je le dis, il est toujours aligné sur les cylindres (je le fais manuellement au lieu de laisser l'outil de partitionnement le faire pour vous).

Comment obtenir une telle clé de récupération USB (elle a deux astuces):

1. Alignez les partitions sur les cylindres (meilleure compatibilité pour simplement l'aligner sur MiB)
2. Faites un grub-install --target = i386-pc, puis faites un autre grub-install --target = x86_64-efi sur la même partition grub, de sorte que vous n'utilisez qu'un seul grub.cfg pour les deux modes de démarrage

Comment ça démarre:

• a) démarrage de l'ancien BIOS, chargera MBR, puis Stage2 de la partition grub de BIOS_grub, puis core.img de la partition Grub2
• b) sous forme de démarrage compatible UEFI, chargera le fichier .efi de la partition ESP
• grub.cfg est lu (s'il existe sur la partition grub2)
• le menu grub2 s'affiche
• puis je choisis de démarrer à partir de la boucle SystemRescueCD.iso (avec le paramètre dochace), j'ai défini deux options définies sur grub.cfg, une pour 32 bits, une pour 64 bits (j'ai vraiment quatre options, car j'ai défini deux sur un paramètre dostartx pour démarrer directement sur l'interface graphique).
• après le démarrage, je peux éjecter la clé USB (l'ensemble du Live Linux est en ramdrive grâce à un tel docache), pas besoin de taper de commande, pendrive n'est pas monté (encore une fois grâce au paramètre docache).

Avec cette clé, je peux démarrer un ancien PC (s'ils permettent de démarrer à partir d'USB) en 32 bits ou également 64 bits (s'ils ont une extension etend sur le processeur), mais en démarrant en mode BIOS.

Avec ce bâton, je peux également démarrer un nouveau PC (s'ils permettent de démarrer à partir d'USB) en 32 bits et 64 bits, mais en démarrant en mode UEFI (ah, oui, il peut démarrer en mode UEFI et ensuite simplement démarrer Linux Live SystemRescueCD en 32 bits en mode 64 bits).

J'ai donc un support de démarrage de récupération de clé USB tout-en-un, capable de démarrer près de tous les PC, modernes ou anciens (ne nécessite qu'un support de démarrage USB), peu importe si 32 bits ou 64 bits, BIOS ou UEFI, etc ... et je peux sélectionnez ce que je veux exécuter 32 bits ou 64 bits.

De plus, j'avais testé sur un PC qui refuse d'installer Windows 64Bits (ancien processeur 32Bits), mais je pouvais exécuter un Linux Live 64 bits (car la capacité PAE existe sur ce processeur).

Note latérale: Une première partition telle que NTFS est destinée à contenir des données qui peuvent être partagées avec Windows 7 et versions ultérieures (XP ne les verra pas car ne prend pas en charge le partitionnement GPT) ... ce doit être la première, pas besoin d'être sur l'initiale une partie du disque, peut être où vous voulez, mais la bouillie réside comme première entrée sur la table de partition, cela est dû au mode windows hachable pour monter les partitions sur amovible, il a un code spécialement programmé pour éviter d'accéder à plus que la première partition, donc vous ne peut pas monter les autres en même temps.

Extra pour les partitions Windows et USB: Si vous échangez des entrées de partitions sur la table partitiong, en d'autres termes, vous mettez la partition à laquelle vous souhaitez accéder en tant que première dans le tableau, Windows vous permettra d'y accéder (si son format est compréhensible, fat32 et NTFS directement, ext2 avec des pilotes spéciaux, etc.), mais ne permettra l'accès qu'à celui qui se trouve à la première entrée de la table de partition ... il existe un outil (appelé BootICEx86.exe) qui peut faire un tel travail sous Windows sans même avoir besoin de débrancher la clé usb.

Super extra: il existe également des clés USB (j'ai beaucoup de chance d'en posséder une, un Sony 16GiB) qui peuvent être modifiées avec des outils spéciaux (les miens avec un outil de Lexar) afin qu'elles apparaissent sous Windows comme un disque dur USB au lieu d'une clé USB , après ce changement, toutes les fenêtres vous permettront de supprimer, de créer et de gérer des partitions sur celui-ci, également plusieurs peuvent être montées en même temps, chacune avec sa propre lettre.

Les utilisateurs de Linux ne s'inquiètent pas de cela, car Linux le considère comme un périphérique bloc partitionnable et n'implémente pas de code spécial pour bloquer les partitions de montage, etc., comme Windows.

Oh, oui, ces derniers paragraphes sont écrits juste au cas où quelqu'un sur M $ les lirait, donc leur visage tombe au sol, j'essaie (je ne l'obtiendrai jamais, je sais que c'est un objectif perdu) de leur retirer un tel code laid de Windows et permettre aux utilisateurs d'avoir des partitions sur clé USB de manière native.