目的はなく、便利なだけで、好きなコードを使用できます。
以下に、GPT fdisk の作成者である Rod Smith による素晴らしい回答を引用します。この回答は、主題全体を説明しています。
<ブロック引用>kyodakeの答えは正しいですが、MBR中心でもあります。 GPT の下では、同じ原則が適用されます。つまり、パーティション タイプ コードは、パーティションの意図された目的を識別します。違いは、GPT タイプ コードが 128 ビット GUID であるのに対して、MBR で使用される 8 ビット コードであるということです。GUID の性質は、衝突を避けるためにコードを中央機関に登録する必要がないことを意味します。統計的に、2 つの GUID が偶然に同一である可能性は非常に低いです。
知る限り、GPT タイプ コードの公式リポジトリはありませんが、GPT に関するウィキペディアのページに記載されています。 -3D69D8477DE4 (Linux ファイルシステム データの場合)、対 MBR の場合は 0x83。したがって、GPT ディスクを分割するためのほとんどのツールは、ユーザー インターフェイスで何らかの形式の「省略形」または「自然言語変換」を使用します。私は GPT fdisk の作成者であり、執筆の目標は (MBR) 02 に似たものを作成することでした。 可能な限り、MBR コードをベースとして使用するアプローチを取りました。ただし、GPT と MBR のタイプ コードの対応は 1:1 ではないため、MBR のタイプ コードに 0x100 を掛けて GPT と同等のものを取得しました。したがって、MBR の 0x83 は 8300 になりました。これにより、8301、8302 など、MBR に存在しない関連する後続のコードも有効になります。 MBR コードを知らない人にとっては、明らかに任意です。内部的に、GPT fdisk はこれらのコードを GUID に変換します。詳細なパーティション情報を表示することで、実際の GUID を確認できます (16 経由)。 25 のオプション 、 例えば）。必要に応じて、または GPT fdisk がサポートしていないコードを使用する必要がある場合は、GPT fdisk の 4 文字のコードを使用する代わりに、任意の GUID を入力することもできます。
他のツールは他のアプローチを使用します。 libparted ライブラリ (したがって 33 、GParted、および libparted に基づくその他のツール) はsomeを翻訳します コードを入力して「フラグ」を立て、他のコードを完全に非表示にします。これは一部のユーザーにとっては物事を単純化するのに役立ちますが、一部のタスクが不可能になります。たとえば、libparted に基づくもので任意の型コードを設定することはできません。 OS X のディスク ユーティリティは、既知の GUID をプレーンテキストの説明に変換します。 (IIRC、パーティションを作成すると、GParted と同様に、パーティションで作成されたファイルシステムに基づいて適切なタイプ コードが設定されます。)
ほとんどの場合、Linux は、MBR にも GPT にもタイプ コードを使用しません。つまり、標準の Linux ファイルシステムを (GPTfdisk) 8300 パーティションに配置するか、0700 (以前は一般的でした) を使用するか、独自のランダム GUID を割り当てることができます。同様のコメントは、RAID、LVM、スワップ、およびその他のパーティション タイプに適用されます。ただし、この規則にはいくつかの例外があります。 1 つには、ディストリビューションのインストーラーはタイプ コードを参照して設定することが多いため、適切に使用する前に、パーティションに適切なタイプ コードが必要になる場合があります。もう 1 つの例外は、systemd が 45 の場合にフォールバックとして型コードを使用し始めていることです。 正しく構成されていません。 (GPT fdisk の 830x コードのほとんどはここから発生します。これらは、Freedesktop/systemd のイニシアチブである Discoverable PartitionsSpecification の一部です。) 現在、Ubuntu は、ファイルシステムにメインの Linux ファイルシステム タイプ コード (GPT fdisk では 8300) を使用しています。 LVM、RAID、スワップなどに適切なコード。 libparted のフラグ)。このタイプ コードは、GRUB が使用するパーティションを識別し、64 を実行すると 、GRUB はそれ自体の一部をそのパーティションにインストールします。 GPT ディスクを使用して BIOS ブート システムに GRUB をインストールする場合、通常、BIOS ブート パーティションが存在する必要があります。 (ただし、このルールを回避する方法はあります。)さらに重要なのは、このタイプ コードを誤って間違ったパーティションに設定すると、GRUB のインストール時にそのパーティションが破損することです! さまざまなオンライン フォーラムで、かなりの数の人がその間違いを犯しているのを見てきました。
タイプ コードがより重要になるのは、他の OS を扱う場合です。たとえば、Windows と OS X は、認識できないタイプ コードを持つパーティションに触れない傾向があります。タイプ コードのリストには一般的な Linux 固有のタイプ コードが含まれていないため、Linux 固有のタイプ コードを使用すると、Windows または OS X が Ubuntu インストールを破棄するリスクを軽減できます。ただし、これらの OS は、GPT fdisk8300 または fd00 コードを使用するかどうかを気にしません。これらの他の OS によって認識されるコードを使用すると、問題が発生する可能性があります。たとえば、かつて Linux ファイルシステム タイプの GUID (0FC63DAF-8483-4772-8E79-3D69D8477DE4) は存在しませんでした。 「Microsoft BasicData」タイプ コード (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) を使用する一般的な方法が、デュアル ブート セットアップで問題を引き起こしていたため、作成して自分の GPT fdisk と libparted の両方にプッシュしました。具体的には、特定の Windows ツールは、Linux パーティションが破損しているか初期化されていない Windows パーティションであると判断し、準備を提案します。このプロンプトでユーザーがエラーを起こすと、悲惨な結果になります。このテーマの詳細については、私のこのページを参照してください。
Discoverable Partitions Specification で定義されている Linux パーティション タイプ コードの目的は、74 を記述できるようにすることです。 ほとんどのシステムで廃止されました。これは、設定より慣例のケースです。
Systemd が 82 を追加しました 2014 年のバージョン 211 に戻ります。このジェネレーターは 99 を作成します。 ブート ドライブの GPT パーティションからのユニット。
104 に触れずに、GPT でパーティション分割されたドライブでこれらのコードを今すぐ使用できます。 まったく (完全に空である可能性があります)、まだ 118 用に別のパーティションがあります 、 121 、 134 、 140 自動的に検出され、マウントされます。これらのパーティションには、サポートされている任意のファイル システムを含めることができます。また、LUKS で暗号化することもできます。スワップ パーティションも自動的に検出されます。
さらに便利にするために、ジェネレーターは EFI システム パーティションも 153 にマウントします。 ほとんどの場合。
理論的には、161 を検出させることもできます。 (ルート) パーティションですが、これはもう少し複雑です。ほとんどの状況で、まだ initramfs が必要だと思います。それ以外の場合、171 カーネル パラメータは引き続き必要です。
186 のコードの必要性 およびその他のパーティションは、gpt fdisk のコードを作成し、現在 (2020 年) に貢献している Rod Smith によってここに記載されています。これは 2011 年に彼からのものです:
私は最近、Windows が Linux パーティションを含む GPT ディスクを読み取るときに、それらのパーティションにドライブ文字が割り当てられ、フォーマットされていないと表示されることを発見しました。この状況は、リムーバブル ディスクの場合、または UEFI ベースのコンピューターで Linux と Windows のデュアル ブートを行う場合に発生する可能性があります。 UEFI が一般的になっているため、この状況も一般的になっています。これは、起こるのを待っている災害のように私を襲います。遅かれ早かれ、だれかが Windows で Linux パーティションをフォーマットすることを選択して、Linux インストールを破棄するでしょう。
この問題は、Linux パーティション ツール (libparted と私自身の GPT fdisk) が Linux パーティションに、Windows がファイル システム パーティションに使用するのと同じパーティション タイプ コード GUID (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) を与えるために発生します。 Linux には、RAID、LVM、スワップ領域など、他のパーティション タイプ用の独自の GUID タイプ コードがあります。
したがって、Linux には、ファイルシステム用の独自の MBR パーティション タイプ コード (MBR では 0x83) があるのと同じように、GPT ディスク上のファイル システム パーティション用に独自のパーティション タイプ コード GUID が必要なようです。このような変更を自分のプログラムに実装したいのですが、一方的にはしたくありません。パーティション タイプ コード GUID を作成するための異常なプロトコルがないと仮定すると、次のプロトコルを使用することをお勧めします:
0FC63DAF-8483-4772-8E79-3D69D8477DE4
これは、GNU Parted 3.0 を使用してテスト ディスク上に作成したパーティションのパーティション固有の GUID です。
parttypes.cc のコードを見ると、Linux などのすべてのコードに気付くでしょう。
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)