Neexistuje žádný účel, pouze pohodlí a můžete použít libovolný kód.
Níže cituji skvělou odpověď Roda Smithe, autora GPT fdisk, která vysvětluje celé téma:
odpověď kyodake je správná, ale je také spíše zaměřená na MBR. V rámci GPT platí stejné principy – to znamená, že kód typu oddílu identifikuje zamýšlený účel oddílu. Rozdíl je v tom, že kódy typu GPT jsou 128bitové GUID oproti 8bitovým kódům používaným v rámci MBR. Povaha GUID znamená, že není nutné registrovat kódy u centrálního úřadu, aby se předešlo kolizím; dvě GUID jsou statisticky velmi nepravděpodobné, že by byly náhodou totožné.
AFAIK, neexistuje žádné oficiální úložiště kódů typu GPT, ale jsou zdokumentovány na stránce Wikipedie o GPT. Jednou nevýhodou kódů typu GPT je, že jako GUID jsou dlouhé a nešikovné – například 0FC63DAF-8483-4772-8E79 -3D69D8477DE4 pro data souborového systému Linux, vs. 0x83 pro ekvivalent MBR. Většina nástrojů pro dělení disků GPT tedy používá ve svých uživatelských rozhraních nějakou formu „zkráceného“ nebo „překladu do přirozeného jazyka“. Jsem autorem GPT fdisk a mým cílem při psaní bylo vytvořit něco, co by bylo podobné (MBR)
fdiskpokud to bylo možné, zvolil jsem přístup k použití MBR kódů jako základu; ale protože korespondence mezi kódy typu GPT a MBR není 1:1, vynásobil jsem kódy typu MBR 0x100, abych získal ekvivalenty GPT. MBR's0x83 se tak stal 8300. To také umožňuje související následné kódy, které v MBR neexistují, jako je 8301, 8302 atd. Tyto kódy lze snadno použít pro lidi, kteří již znají ekvivalenty MBR, ale zpětně libovolné pro lidi, kteří neznají kódy MBR. Interně GPT fdisk překládá tyto kódy na GUID. Aktuální GUID můžete zobrazit zobrazením podrobných informací o oddílu (přesimožnost vgdisk, například). Pokud chcete nebo pokud potřebujete použít kód, který GPT fdisk nepodporuje, můžete také zadat libovolné GUID místo použití čtyřznakových kódů GPT fdisk.Jiné nástroje používají jiné přístupy. Knihovna libparted (a tedy
parted, GParted a další nástroje založené na libparted) překládáněkteré zadejte kódy do "příznaků" a zcela skryje ostatní kódy. To pomáhá zjednodušit věci pro některé uživatele, ale některé úkoly to znemožňuje - například nemůžete nastavit libovolný typový kód s čímkoli založeným na libparted. Disková utilita OS X převádí známé GUID na popisy ve formátu prostého textu. (IIRC, když vytvoříte oddíl, nastaví příslušný typový kód na základě souborového systému vytvořeného v oddílu, podobně jako GParted.)Linux z větší části nepoužívá typové kódy ani pro MBR, ani pro GPT. To znamená, že můžete umístit svůj standardní linuxový souborový systém na oddíl (GPTfdisk) 8300, nebo použít 0700 (jak bylo běžné v minulosti), nebo přiřadit své vlastní náhodné GUID. Podobné komentáře platí pro RAID, LVM, swap a další typy oddílů. Existuje však několik výjimek z tohoto pravidla. Za prvé, instalátoři distribuce často prohlížejí a nastavují kódy typu, takže možná budete potřebovat správný typový kód na oddílu, než bude správně použit. Další výjimkou je, že systemd začíná používat typové kódy jako záložní, pokud
/etc/fstabnení správně nakonfigurován. (Tady pochází většina 830x kódů GPT fdisk – jsou součástí Discoverable PartitionsSpecification, což je iniciativa Freedesktop/systemd.) V současné době Ubuntu používá pro souborové systémy hlavní typ souborového systému Linux (8300 v GPT fdisk) plus vhodné kódy pro LVM, RAID, swap atd. Velkou výjimkou z pravidel „Linux nepoužívá kódy typů“ je kód oddílu BIOSBoot (21686148-6449-6E6F-744E-656564454649; ef02 v GPTfdisk nebobios_grubvlajka v libparted). Tento typový kód identifikuje oddíl používaný GRUBem a při spuštěnígrub-install, GRUB nainstaluje část sebe do tohoto oddílu. Pokud instalujete GRUB na spouštěcím systému aBIOS s diskem GPT, musí být za normálních okolností přítomen spouštěcí oddíl systému BIOS. (Existují však způsoby, jak toto pravidlo obejít.) Ještě důležitější je, že pokud omylem nastavíte tento typový kód na nesprávný oddíl, tento oddíl se při instalaci GRUB poškodí! Viděl jsem několik lidí, kteří udělali tuto chybu na různých online fórech.Typové kódy se stávají důležitějšími při jednání s jinými OS. Například Windows a OS X mají tendenci se nedotýkat oddílů s typovými kódy, které nerozpoznají. Jejich seznam typových kódů nezahrnuje běžné typové kódy specifické pro Linux, takže použití kódu specifického pro Linux pomáhá snížit riziko, že Windows nebo OS X zničí vaši instalaci Ubuntu. Těmto operačním systémům je však jedno, zda používáte kód GPT fdisk8300 nebo fd00. Problémy mohou nastat, pokud používáte kódy, které tyto jiné OS rozpoznávají. Například v jednom okamžiku neexistoval souborový systém Linux typu GUID (0FC63DAF-8483-4772-8E79-3D69D8477DE4). Vytvořil jsem jej a vložil do svého vlastního GPT fdisku i libparted, protože běžná praxe používání kódu typu "Microsoft BasicData" (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) způsobovala problémy v nastaveních s duálním spouštěním. Konkrétně by některé nástroje Windows považovaly linuxový oddíl za poškozený nebo neinicializovaný oddíl Windows a nabídly jeho přípravu. Chyba uživatele při této výzvě by byla katastrofální. Více na toto téma naleznete na této mé stránce.
Účelem kódů typů oddílů Linux definovaných ve specifikaci Discoverable Partitions je umožnit psaní /etc/fstab zastaralé pro většinu systémů. Je to případ konvence ohledně konfigurace.
Systemd přidal systemd-gpt-auto-generator zpět v roce 2014 ve verzi 211. Tento generátor vytvoří .mount jednotek z oddílů GPT na spouštěcí jednotce.
Takže dnes můžete tyto kódy používat na disku rozděleném na GPT, nemusíte se dotýkat /etc/fstab vůbec (může být úplně prázdný) a stále mít samostatné oddíly pro /home , /srv , /var , /var/tmp který bude objeven a připojen automaticky. Tyto oddíly mohou mít jakýkoli podporovaný souborový systém. Mohou být také šifrovány LUKS. Odkládací oddíly jsou také rozpoznány automaticky.
Pro další pohodlí generátor také připojuje systémový oddíl EFI na /boot ve většině případů.
Teoreticky můžete také nechat objevit / (kořenový) oddíl, ale to je trochu složitější. Hádám, že to ve většině situací stále vyžaduje initramfs. V opačném případě root=/dev/whatever parametr jádra je stále povinný.
Potřeba kódu pro /home a další oddíly zde uvádí Rod Smith, který vytvořil a až do současnosti (2020) přispívá ke kódu gpt fdisk. Toto je od něj v roce 2011:
Nedávno jsem zjistil, že když systém Windows čte disk GPT s oddíly Linuxu, těmto oddílům jsou přiřazena písmena jednotek a zobrazují se jako nezformátované. Tato situace může nastat u vyměnitelných disků nebo při duálním spouštění systémů Linux a Windows na počítači s UEFI. Vzhledem k tomu, že UEFI je stále běžnější, je tato situace také stále běžnější. Připadá mi to jako katastrofa, která čeká, až se stane; dříve nebo později někdo zničí instalaci Linuxu tím, že zvolí formátování oddílu Linuxu ve Windows.
K tomuto problému dochází, protože linuxové rozdělovací nástroje (libparted a můj vlastní GPT fdisk) dávají linuxovým oddílům stejný kód typu oddílu GUID, jaký používá Windows pro oddíly souborového systému (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7). Linux má vlastní kódy typu GUID pro jiné typy oddílů, jako je RAID, LVM a odkládací prostor.
Zdá se mi tedy, že Linux potřebuje svůj vlastní kód typu oddílu GUID pro oddíly souborového systému na discích GPT, stejně jako má svůj vlastní kód typu oddílu MBR pro souborové systémy (0x83 na MBR). Rád bych takovou změnu provedl ve svém vlastním programu, ale nechci to dělat jednostranně. Za předpokladu, že neexistuje žádný neobvyklý protokol pro vytváření GUID kódu typu oddílu, doporučuji použít následující:
0FC63DAF-8483-4772-8E79-3D69D8477DE4
To je pouze GUID jedinečné pro oddíl pro oddíl, který jsem vytvořil na testovacím disku pomocí GNU Parted 3.0.
Pokud se podíváte na kód parttypes.cc, všimnete si všech kódů pro Linux a další.
Seznam kódů oddílů systému 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)