Qual é o propósito do código de partição inicial do Linux 8302?

Não há propósito, apenas conveniência, e você pode usar qualquer código que desejar.

Cito abaixo uma ótima resposta do Rod Smith , autor do GPT fdisk, que explica todo o assunto:

A resposta de kyodake está correta, mas também é bastante centrada no MBR. Sob o GPT, os mesmos princípios se aplicam -- isto é, um código de tipo de partição identifica a finalidade pretendida de uma partição. A diferença é que os códigos de tipo GPT são GUIDs de 128 bits, em comparação com os códigos de 8 bits usados ​​no MBR. A natureza dos GUIDs significa que não é necessário registrar códigos com uma autoridade central para evitar colisões; dois GUIDs são estatisticamente muito improváveis ​​de serem idênticos por acidente.

AFAIK, não há repositório oficial de códigos de tipo GPT, mas eles estão documentados na página da Wikipedia sobre GPT. Uma desvantagem dos códigos de tipo GPT é que, como GUIDs, eles são longos e desajeitados - por exemplo, 0FC63DAF-8483-4772-8E79-3D69D8477DE4 para dados do sistema de arquivos Linux, contra 0x83 para o equivalente MBR. Assim, a maioria das ferramentas para particionar discos GPT usa alguma forma de "abreviação" ou "tradução de linguagem natural" em suas interfaces de usuário. Sou o autor do GPT fdisk e, como meu objetivo ao escrevê-lo, era criar algo semelhante a (MBR)fdiskdentro do possível, adotei a abordagem de usar códigos MBR como base; no entanto, como a correspondência entre os códigos de tipo GPT e MBR não é 1:1, multipliquei os códigos de tipo MBR por 0x100 para obter os equivalentes GPT. Assim, o 0x83 do MBR tornou-se 8300. Isso também permite códigos subsequentes relacionados que não existem no MBR, como 8301, 8302, etc. Esses códigos são fáceis de usar para pessoas que já estão familiarizadas com os equivalentes do MBR, mas eles são reconhecidamente arbitrários para pessoas que não conhecem os códigos MBR. Internamente, o GPT fdisk converte esses códigos em GUIDs. Você pode ver os GUIDs reais visualizando informações detalhadas da partição (através da i opção em gdisk, por exemplo). Você também pode inserir um GUID arbitrário em vez de usar os códigos de quatro caracteres GPT fdisk,

Outras ferramentas usam outras abordagens. A biblioteca libparted (e, portanto parted, GParted e outras ferramentas baseadas em libparted) traduz alguns códigos de tipo para "sinalizadores" e oculta completamente outros códigos. Isso ajuda a simplificar as coisas para alguns usuários, mas torna algumas tarefas impossíveis -- por exemplo, você não pode definir um código de tipo arbitrário com qualquer coisa baseada em libparted. O Utilitário de Disco do OS X converte GUIDs conhecidos em descrições de texto simples. (IIRC, quando você cria uma partição, ela define um código de tipo apropriado com base no sistema de arquivos criado em uma partição, semelhante ao que o GParted faz.)

Na maioria das vezes, o Linux não usa códigos de tipo, seja para MBR ou GPT. Ou seja, você pode colocar seu sistema de arquivos Linux padrão em uma partição 8300 (GPT fdisk) ou usar 0700 (como era comum no passado) ou atribuir seu próprio GUID aleatório. Comentários semelhantes se aplicam a RAID, LVM, swap e outros tipos de partição. Existem algumas exceções a esta regra, no entanto. Por um lado, os instaladores de distribuição geralmente examinam e definem códigos de tipo, portanto, você pode precisar do código de tipo correto em uma partição antes de ser usado adequadamente. Outra exceção é que o systemd está começando a usar códigos de tipo como um fallback se /etc/fstabnão estiver configurado corretamente. (É aí que a maioria dos códigos 830x do GPT fdisk se originam - eles fazem parte da especificação de partições detectáveis, que é uma iniciativa do Freedesktop/systemd.) Atualmente, o Ubuntu está usando apenas o código de tipo de sistema de arquivos Linux principal (8300 em GPT fdisk) para sistemas de arquivos, mais os códigos apropriados para LVM, RAID, swap, etc. não usa regras de códigos de tipo" é o código de partição de inicialização do BIOS (21686148-6449-6E6F-744E-656564454649; ef02 em GPT fdisk ou o bios_grubsinalizador em libparted). Esse código de tipo identifica uma partição usada pelo GRUB e, quando você executa grub-install, o GRUB instala parte de si mesmo nessa partição. Se você instalar o GRUB em um sistema de inicialização BIOS com um disco GPT, uma partição de inicialização BIOS normalmente deve estar presente. (Existem maneiras de contornar essa regra, no entanto.) Mais importante, se você definir esse código de tipo por engano na partição errada, essa partição será danificada quando você instalar o GRUB! Já vi muitas pessoas cometerem esse erro em vários fóruns online.

Onde os códigos de tipo se tornam mais importantes é ao lidar com outros sistemas operacionais. Windows e OS X, por exemplo, tendem a não tocar em partições com códigos de tipo que não reconhecem. Sua lista de códigos de tipo exclui códigos de tipo específicos específicos do Linux, portanto, usar um código de tipo específico do Linux ajuda a reduzir o risco de o Windows ou OS X destruir sua instalação do Ubuntu. Esses sistemas operacionais não se importam se você usa o código GPT fdisk 8300 ou fd00. Podem surgir problemas se você usar códigos reconhecidos por esses outros sistemas operacionais. Por exemplo, ao mesmo tempo, o tipo de sistema de arquivos Linux GUID (0FC63DAF-8483-4772-8E79-3D69D8477DE4) não existia. Eu o criei e o enviei para meu próprio fdisk GPT e libparted porque a prática comum de usar o código de tipo "Microsoft Basic Data" (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) estava causando problemas em configurações de inicialização dupla. Especificamente, certas ferramentas do Windows pensariam que a partição do Linux era uma partição do Windows danificada ou não inicializada e se ofereceriam para prepará-la. O erro do usuário neste prompt seria desastroso. Veresta página minha para saber mais sobre este assunto.

A finalidade dos códigos de tipo de partição Linux definidos na Especificação de Partições Detectáveis ​​é tornar a escrita /etc/fstabobsoleta para a maioria dos sistemas. É um caso de convenção sobre configuração.

Systemd adicionado systemd-gpt-auto-generatorem 2014 na versão 211. Este gerador cria .mountunidades de partições GPT na unidade de inicialização.

Portanto, você pode usar esses códigos em sua unidade particionada por GPT hoje, sem tocar /etc/fstabem nada (pode estar totalmente vazio) e ainda ter partições separadas para /home, /srv, /var, /var/tmpque serão descobertas e montadas automaticamente. Essas partições podem ter qualquer sistema de arquivos suportado. Eles também podem ser criptografados com LUKS. As partições de troca também são descobertas automaticamente.

Para maior conveniência, o gerador também monta a partição do sistema EFI /bootna maioria dos casos.

Teoricamente, você também pode descobrir a /partição (raiz), mas isso é um pouco mais complicado. Eu acho que ainda requer um initramfs na maioria das situações. Caso contrário, o root=/dev/whateverparâmetro do kernel ainda é necessário.

A necessidade de um código para /homee outras partições é declarada aqui por Rod Smith, que criou e até agora (2020) contribui para o código do gpt fdisk. Esta é dele em 2011:

Descobri recentemente que, quando o Windows lê um disco GPT com partições do Linux, essas partições recebem letras de unidade e aparecem como não formatadas. Essa situação pode acontecer com discos removíveis ou quando o Linux e o Windows são inicializados em um computador baseado em UEFI. Como o UEFI está se tornando mais comum, essa situação também está se tornando mais comum. Isso me parece um desastre prestes a acontecer; mais cedo ou mais tarde, alguém vai destruir uma instalação Linux optando por formatar uma partição Linux no Windows.

Esse problema ocorre porque as ferramentas de particionamento do Linux (libparted e meu próprio fdisk GPT) fornecem às partições do Linux o mesmo código de tipo de partição GUID usado pelo Windows para suas partições de sistema de arquivos (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7). O Linux tem seus próprios códigos de tipo GUID para outros tipos de partição, como RAID, LVM e espaço de troca.

Portanto, parece-me que o Linux precisa de seu próprio GUID de código de tipo de partição para partições de sistema de arquivos em discos GPT, assim como possui seu próprio código de tipo de partição MBR para sistemas de arquivos (0x83 em MBR). Eu gostaria de implementar tal mudança em meu próprio programa, mas não quero fazer isso unilateralmente. Supondo que não haja protocolo incomum para criar GUIDs de código de tipo de partição, sugiro o seguinte:

0FC63DAF-8483-4772-8E79-3D69D8477DE4

Isso é apenas um GUID exclusivo de partição para uma partição que criei em um disco de teste usando o GNU Parted 3.0.

Se você der uma olhada no código de parttypes.cc , notará todos os códigos para Linux e outros.

Lista de códigos de partições do 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)