Il n'y a aucun but, juste la commodité, et vous pouvez utiliser n'importe quel code que vous aimez.
Je cite ci-dessous une excellente réponse de Rod Smith, l'auteur de GPT fdisk, qui explique tout le sujet :
La réponse de kyodake est correcte, mais elle est également plutôt centrée sur le MBR. Sous GPT, les mêmes principes s'appliquent, c'est-à-dire qu'un code de type de partition identifie l'objectif prévu d'une partition. La différence est que les codes de type GPT sont des GUID 128 bits, par rapport aux codes 8 bits utilisés sous MBR. La nature des GUID signifie qu'il n'est pas nécessaire d'enregistrer des codes auprès d'une autorité centrale pour éviter les collisions; il est statistiquement très peu probable que deux GUID soient identiques par accident.
AFAIK, il n'y a pas de référentiel officiel des codes de type GPT, mais ils sont documentés sur la page Wikipédia à propos de GPT. -3D69D8477DE4 pour les données du système de fichiers Linux, contre 0x83 pour l'équivalent MBR. Ainsi, la plupart des outils de partitionnement des disques GPT utilisent une certaine forme de « sténographie » ou de « traduction en langage naturel » dans leurs interfaces utilisateur. Je suis l'auteur de GPT fdisk, et mon objectif en écrivant était de créer quelque chose d'aussi similaire à (MBR)
fdiskdans la mesure du possible, j'ai adopté l'approche consistant à utiliser les codes MBR comme base ; cependant, comme la correspondance entre les codes de type GPT et MBR n'est pas de 1:1, j'ai multiplié les codes de type MBR par 0x100 pour obtenir les équivalents GPT. Ainsi, le MBR's0x83 est devenu 8300. Cela active également les codes de suivi associés qui n'existent pas dans le MBR, tels que 8301, 8302, etc. Ces codes sont faciles à utiliser pour les personnes qui connaissent déjà les équivalents MBR, mais ils réadmis arbitrairement pour les personnes qui ne connaissent pas les codes MBR. En interne, GPT fdisk traduit ces codes en GUID. Vous pouvez voir les GUID réels en affichant des informations détaillées sur la partition (via leioption dansgdisk, par exemple). Vous pouvez également entrer un GUID arbitraire plutôt que d'utiliser les codes à quatre caractères GPT fdisk, si vous le souhaitez ou si vous avez besoin d'utiliser un code que GPT fdisk ne prend pas en charge.D'autres outils utilisent d'autres approches. La bibliothèque libparted (et donc
parted, GParted et d'autres outils basés sur libparted) traduitcertains tapez les codes en "drapeaux" et masque complètement les autres codes. Cela aide à simplifier les choses pour certains utilisateurs, mais cela rend certaines tâches impossibles - par exemple, vous ne pouvez pas définir un code de type arbitraire avec quoi que ce soit basé sur libparted. L'utilitaire de disque d'OS X traduit les GUID connus en descriptions en texte brut. (IIRC, lorsque vous créez une partition, il définit un code de type approprié basé sur le système de fichiers créé dans partition, similaire à ce que fait GParted.)Pour la plupart, Linux n'utilise pas de codes de type, que ce soit pour MBR ou GPT. Autrement dit, vous pouvez placer votre système de fichiers Linux standard sur une partition (GPTfdisk) 8300, ou utiliser 0700 (comme c'était courant dans le passé), ou attribuer votre propre GUID aléatoire. Des commentaires similaires s'appliquent à RAID, LVM, swap et autres types de partition. Il y a cependant quelques exceptions à cette règle. D'une part, les installateurs de distribution regardent et définissent souvent les codes de type, vous aurez donc peut-être besoin du bon code de type sur une partition avant qu'elle ne soit utilisée correctement. Une autre exception est que systemd commence à utiliser les codes de type comme solution de secours si
/etc/fstabn'est pas correctement configuré. (C'est de là que proviennent la plupart des codes 830x de GPT fdisk - ils font partie de la spécification des partitions détectables, qui est une initiative de Freedesktop/systemd.) codes appropriés pour LVM, RAID, swap, etc. Une grande exception aux règles "Linux n'utilise pas de codes de type" est le code de partition BIOSBoot (21686148-6449-6E6F-744E-656564454649; ef02 dans GPTfdisk ou lebios_grubdrapeau dans libparted). Ce type de code identifie une partition utilisée par GRUB, et lorsque vous exécutezgrub-install, GRUB installera une partie de lui-même sur cette partition. Si vous installez GRUB sur un système de démarrage BIOS avec un disque GPT, une partition de démarrage BIOS doit normalement être présente. (Il existe cependant des moyens de contourner cette règle.) Plus important encore, si vous définissez par erreur ce type de code sur la mauvaise partition, cette partition sera endommagée lors de l'installation de GRUB ! J'ai vu pas mal de personnes faire cette erreur sur divers forums en ligne.Là où les codes de type deviennent plus importants, c'est lorsqu'ils traitent avec d'autres systèmes d'exploitation. Windows et OS X, par exemple, ont tendance à ne pas toucher aux partitions avec des codes de type qu'ils ne reconnaissent pas. Leur liste de codes de type exclut les codes de type communs spécifiques à Linux, donc l'utilisation d'un code de type spécifique à Linux permet de réduire le risque que Windows ou OS X supprime votre installation Ubuntu. Cependant, ces systèmes d'exploitation ne se soucient pas de savoir si vous utilisez le code GPT fdisk8300 ou fd00. Des problèmes peuvent survenir si vous utilisez des codes reconnus par ces autres systèmes d'exploitation. Par exemple, à un moment donné, le GUID de type de système de fichiers Linux (0FC63DAF-8483-4772-8E79-3D69D8477DE4) n'existait pas. Je l'ai créé et poussé à la fois dans mon propre fdisk GPT et libparted parce que la pratique courante consistant à utiliser le code de type "Microsoft BasicData" (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) causait des problèmes dans les configurations à double démarrage. Plus précisément, certains outils Windows pensent que la partition Linux est une partition Windows endommagée ou non initialisée et proposent de la préparer. Une erreur de l'utilisateur à cette invite serait désastreuse. Voir cette page de la mienne pour en savoir plus sur ce sujet.
Le but des codes de type de partition Linux définis dans la spécification des partitions détectables est de rendre l'écriture /etc/fstab obsolète pour la plupart des systèmes. C'est un cas de convention plutôt que de configuration.
Systemd a ajouté systemd-gpt-auto-generator en 2014 dans la version 211. Ce générateur crée .mount unités des partitions GPT sur le lecteur de démarrage.
Vous pouvez donc utiliser ces codes sur votre lecteur partitionné GPT aujourd'hui, sans toucher au /etc/fstab du tout (il peut être totalement vide), et avoir toujours des partitions séparées pour /home , /srv , /var , /var/tmp qui seront découverts et montés automatiquement. Ces partitions peuvent avoir n'importe quel système de fichiers pris en charge. Ils peuvent également être cryptés LUKS. Les partitions d'échange sont également découvertes automatiquement.
Pour plus de commodité, le générateur monte également la partition système EFI à /boot dans la plupart des cas.
Théoriquement vous pouvez aussi lui faire découvrir le / (racine), mais c'est un peu plus compliqué. Je suppose que cela nécessite toujours un initramfs dans la plupart des situations. Sinon, le root=/dev/whatever le paramètre du noyau est toujours requis.
Le besoin d'un code pour /home et d'autres partitions est indiqué ici par Rod Smith qui a créé et jusqu'à présent (2020) contribué au code de gpt fdisk. C'est de lui en 2011 :
J'ai récemment découvert que lorsque Windows lit un disque GPT contenant des partitions Linux, ces partitions reçoivent des lettres de lecteur et s'affichent comme non formatées. Cette situation peut se produire avec des disques amovibles ou lors d'un double démarrage Linux et Windows sur un ordinateur basé sur UEFI. Étant donné que l'UEFI devient de plus en plus courant, cette situation devient également de plus en plus courante. Cela me frappe comme un désastre imminent; tôt ou tard, quelqu'un va détruire une installation Linux en choisissant de formater une partition Linux sous Windows.
Ce problème se produit car les outils de partitionnement Linux (libparted et mon propre fdisk GPT) attribuent aux partitions Linux le même GUID de code de type de partition utilisé par Windows pour ses partitions de système de fichiers (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7). Linux possède ses propres codes de type GUID pour d'autres types de partition, tels que RAID, LVM et l'espace de swap.
Ainsi, il me semble que Linux a besoin de son propre GUID de code de type de partition pour les partitions de système de fichiers sur les disques GPT, tout comme il a son propre code de type de partition MBR pour les systèmes de fichiers (0x83 sur MBR). J'aimerais mettre en œuvre un tel changement dans mon propre programme, mais je ne veux pas le faire unilatéralement. En supposant qu'il n'y ait pas de protocole inhabituel pour créer des GUID de code de type de partition, je suggère d'utiliser ce qui suit :
0FC63DAF-8483-4772-8E79-3D69D8477DE4
C'est juste un GUID unique pour une partition que j'ai créée sur un disque de test à l'aide de GNU Parted 3.0.
Si vous regardez le code de parttypes.cc, vous remarquerez tous les codes pour Linux et autres.
Liste des codes de partitions Linux
0x8200, "0657FD6D-A4AB-43C4-84E5-0933C84B4F4F", "Linux swap"); // Linux swap (or Solaris on MBR) 0x8300, "0FC63DAF-8483-4772-8E79-3D69D8477DE4", "Linux filesystem"; // Linux native 0x8301, "8DA63339-0007-60C0-C436-083AC8230908", "Linux reserved"; 0x8302, "933AC7E1-2EB4-4F13-B844-0E14E2AEF915", "Linux /home"; // Linux /home (auto-mounted by systemd) 0x8303, "44479540-F297-41B2-9AF7-D131D5F0458A", "Linux x86 root (/)"; // Linux / on x86 (auto-mounted by systemd) 0x8304, "4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709", "Linux x86-64 root (/)"; // Linux / on x86-64 (auto-mounted by systemd) 0x8305, "B921B045-1DF0-41C3-AF44-4C6F280D3FAE", "Linux ARM64 root (/)"; // Linux / on 64-bit ARM (auto-mounted by systemd) 0x8306, "3B8F8425-20E0-4F3B-907F-1A25A76F98E8", "Linux /srv"; // Linux /srv (auto-mounted by systemd) 0x8307, "69DAD710-2CE4-4E3C-B16C-21A1D49ABED3", "Linux ARM32 root (/)"; // Linux / on 32-bit ARM (auto-mounted by systemd) 0x8308, "7FFEC5C9-2D00-49B7-8941-3EA10A5586B7", "Linux dm-crypt"; 0x8309, "CA7D7CCB-63ED-4C53-861C-1742536059CC", "Linux LUKS"; 0x830A, "993D8D3D-F80E-4225-855A-9DAF8ED7EA97", "Linux IA-64 root (/)"; // Linux / on Itanium (auto-mounted by systemd) 0x830B, "D13C5D3B-B5D1-422A-B29F-9454FDC89D76", "Linux x86 root verity"; 0x830C, "2C7357ED-EBD2-46D9-AEC1-23D437EC2BF5", "Linux x86-64 root verity"; 0x830D, "7386CDF2-203C-47A9-A498-F2ECCE45A2D6", "Linux ARM32 root verity"; 0x830E, "DF3300CE-D69F-4C92-978C-9BFB0F38D820", "Linux ARM64 root verity"; 0x830F, "86ED10D5-B607-45BB-8957-D350F23D0571", "Linux IA-64 root verity"; 0x8310, "4D21B016-B534-45C2-A9FB-5C16E091FD2D", "Linux /var"; // Linux /var (auto-mounted by systemd) 0x8311, "7EC6F557-3BC5-4ACA-B293-16EF5DF639D1", "Linux /var/tmp"; // Linux /var/tmp (auto-mounted by systemd)