Muitas vezes, especialmente ao mexer com carregadores de inicialização, vejo números numéricos de unidade e partição usados. Por exemplo, no meu /boot/grub/grub.cfgI see set root='hd0,gpt2', minhas entradas de inicialização UEFI geralmente fazem referência a números de unidade/partição e parece surgir em quase qualquer contexto em que os carregadores de inicialização estejam envolvidos.
Agora que temos UUID e PARTUUID, endereçar partições dessa maneira parece incrivelmente instável (afaik, não é garantido que as unidades sejam montadas sempre na mesma ordem, um usuário pode mover a ordem das unidades conectadas em sua mobo, etc.)
Minhas perguntas, portanto, são duas:
Esse esquema de endereçamento é tão instável quanto descrevi acima? Estou faltando algo no padrão que significa que esse esquema é muito mais confiável do que eu esperava, ou esse esquema de endereçamento realmente tornará seu sistema não inicializável (até que você corrija suas entradas de inicialização pelo menos) como resultado de suas unidades simplesmente serem reconhecidas em um ordem diferente ou conectá-los em slots diferentes na sua placa-mãe?
Se a resposta para a pergunta acima for sim, então por que esse esquema de endereçamento continua a ser usado? Usar UUID ou PARTUUID para tudo não seria muito mais estável e consistente?
Estritamente falando, o UUID não está endereçando .
O endereçamento é muito, muito simples: leia a unidade X setor Y - ou então. Leia o endereço de memória Z - ou então. O endereçamento é simples, rápido, não deixa muito espaço para interpretação e está em toda parte.
UUID não está endereçando. Em vez disso, está procurando, encontrando, às vezes esperando que os dispositivos apareçam e também entendendo os sistemas de arquivos (★). E dependendo de quantos dispositivos existem, pode levar muito tempo. E uma vez encontrado, volta ao endereçamento regular.
No GRUB, isso é chamado de
search(★★) e só está disponível quando o GRUB já tem asas (a pesquisa é um módulo, assim como todo sistema de arquivos que ele suporta, portanto, disponível apenas após o carregamento do núcleo). No Linux, é (por exemplo) chamadofindfs, findfs pesquisará os dispositivos de bloco no sistema procurando por um sistema de arquivos ou partição .Ele passa por todos os dispositivos de bloco, acorda-os do modo de espera, lê dados e o resultado ainda pode ser aleatório se o UUID não for único como deveria ser (após
ddacidente ou algo parecido), ou você não obtiver resultado se o UUID for alterado - Os UUIDs também são propensos a erros de configuração.Em geral, os UUIDs são ótimos e, claro, você deve usá-los em todos os lugares, se disponíveis, especialmente quando o endereçamento tradicional está fadado a falhar porque a ordem das unidades é aleatória no Linux; mas entenda que a complexidade está acima e além do que o endereçamento simples deve fazer. E especialmente nos estágios iniciais dos bootloaders, simplesmente pode não ser uma opção ainda. O endereçamento vem primeiro, o crescimento das asas vem depois.
Para o bootloader, pode simplesmente não ser necessário fazer o esforço (nem todo bootloader suporta uma ampla variedade de sistemas de arquivos como o GRUB). Se
hd0for garantido ser "o disco do qual inicializamos" devido às circunstâncias (o BIOS fornece) e, portanto, se você puder descartar problemas de ordem de unidade aleatória, pode não haver necessidade de passar por uma lista potencialmente enorme de outras partições em procure por UUIDs.Se você está confiante o suficiente em sua configuração para dizer que
hd0,gpt2é a que você quer, e tem que ser, e não pode ser de outra forma, então não há nada de errado em usá-la assim. Às vezes, o endereçamento simples e simples funciona bem.(★) Eu expliquei isso anteriormente para LABELs aqui ...
...e é o mesmo para UUIDs.
(★★) Na verdade, o GRUB's
searchtem uma--hintopção, e... agora eu não verifiquei o código-fonte, e nem está documentado em seu manual, mas essa opção faria sentido para lhe dar o melhor dos dois mundos: a dica deve informarsearchpara verificar essa partição primeiro e, se o UUID corresponder conforme o esperado, ele identificou o dispositivo com esforço mínimo e, se não corresponder, ainda voltará à pesquisa completa para manter as coisas funcionando de alguma forma .Além disso, os UUIDs encontrados anteriormente tendem a ser armazenados em cache, portanto, não precisa passar por todos os dispositivos repetidamente - e isso também funciona muito bem, desde que o UUID que você está procurando realmente exista em algum lugar para fazê-lo no cache em primeiro lugar.
O esquema de numeração simples não é realmente usado em sistemas recentes (com o "recente" sendo o Ubuntu 9 e posterior, outras distribuições também podem ter se adaptado nessa época).
Você está correto ao observar que a partição raiz é definida com o esquema de numeração simples. Mas isso é apenas uma configuração padrão ou de retorno que geralmente é substituída pelo próximo comando, como:
Isso seleciona a partição raiz com base no UUID do sistema de arquivos.
Na prática, o esquema de numeração simples geralmente é estável (desde que não haja alterações de hardware). A única instância em que observei a numeração não previsível foi o sistema com muitas unidades USB que foram enumeradas com base em um padrão de atendimento por ordem de chegada e depois emuladas como unidades IDE. Nenhum desses processos é inerentemente caótico, então presumo um problema na implementação do BIOS desse sistema específico.
Nota: "partição raiz" neste contexto significa a partição a partir da qual inicializar, pode ser diferente da partição que contém o "raiz aka. / sistema de arquivos".
Também não se esqueça dos rótulos. Eles não são tão exclusivos quanto os UUIDs, mas muito mais informativos e tornam seu fstab legível por humanos. Se for o seu desktop ou uma pequena empresa - em outras palavras, você está gerenciando algumas dezenas de unidades, você pode preferir rótulos a UUIDs.
Refletindo sobre a excelente resposta do @frostschutz à sua pergunta, um cenário em que você provavelmente preferiria o endereçamento de link de dispositivo "clássico" é a configuração da VM, especialmente nas nuvens VM-for-hire (abreviada, confusamente, "IaaS"). Suponha que você queira personalizar uma imagem do Ubunzima 04.18 . Você cria uma VM (descartável) com 2 discos: uma será a unidade do sistema (descartável) e a segunda, a que você monta e personaliza. Presumivelmente, você também monta sua partição de inicialização UEFI, se quiser grub um grub mais recente em seu novo disco. Supondo que você tenha escolhido pontos de montagem para as partições de destino em
/mnt, sua tabela de montagem desejada se parece comAssim, você cria 2 unidades idênticas a partir da imagem existente, fornecida pelo provedor e pronta para a nuvem, conecta-as a uma nova VM e inicializa-a. Naturalmente,
Você já vê para onde tudo isso está indo.
A primeira vez que este frankencontraption inicializou, ele escolheu
sda9como a partição de inicialização EFI, mas o Linux decidiu remontarsdb1como o FS raiz:E como meu script de lançamento estava bastante despreparado para isso, eu tenho uma imagem inválida no final, sem uma única ferramenta reclamando no log durante o frankenbuild!
Claro que imprimi a tabela de montagem nos logs. E é claro que a confusão é muito difícil de detectar, já que mount(8) imprime montagens na ordem entre o aleatório e aquele em que os dispositivos foram montados, então não foi surpresa que eu não o tenha visto imediatamente. E imagine, o mesmo script (mas com discos de imagens diferentes) funcionou anteriormente tão bem quanto Glenfiddich de 15 anos. Adivinha quantas horas passei puxando meu cabelo¹ sobre o tronco tentando descobrir o problema?
Não há regras rígidas e rápidas boas para qualquer situação, de um PC de mesa a um Linux embutido em um roteador, de seu telefone Android a um data center na nuvem. Uma resposta SO deve ser objetiva, e minhas experiências ou preferências, é claro, não são. Então, prefiro mostrar exemplos de raciocínio lógico ao selecionar entre diferentes métodos de identificação de partições:
Deixe-o em paz se não tiver motivos para não fazê-lo. Os UUIDs são o padrão para a maioria das distribuições modernas. Se se trata de adicionar uma segunda unidade, tente e decida. As chances são de que você nunca precisará saber. Se o seu sistema ainda inicializar e você puder ver e particionar o novo dispositivo, formate e adicione-o ao fstab (por UUID, por LABEL ou por um
/devlink, as mesmas considerações se aplicam). É somente quando o seu sistema se recusa a inicializar após conectar a unidade extra, então você tem um problema (e talvez alterar a ordem de inicialização no UEFI BIOS seja a saída mais rápida).Pragmaticamente, rotular qual conector SATA vai para qual unidade em sua própria área de trabalho pode ser a solução mais rápida e fácil, enquanto alterar a maneira como o sistema inicializa e se recupera de uma falha de inicialização bastante provável é, sem dúvida, o pior devorador de tempo. Mas se você gerenciar isso para 50 programadores que pensam que colocar uma unidade extra não é um problema que valha a pena incomodá-lo, pelo menos não teste os limites de sua sorte e certifique-se de que suas unidades de inicialização iniciais sejam todas vistas pelo grub como
hd0e o sistema comosda.Rótulos para gerenciar suas próprias unidades e partições em sua área de trabalho ou três, ou um pequeno ambiente (uma sala de estar de uma casa cheia de engenheiros de software que curiosamente chamam o local de “escritório de inicialização”). Se você puxar uma unidade física da máquina de alguém, saberá de onde ela veio se usar rótulos de forma consistente.
Se lsblk(8) diz
LABEL=bubba-boot, você sabe que ele foi puxado da máquina chamada bubba ; além disso, bubba-boot rola na minha língua muito mais fácil do que 6864c4ea-f9b9-46db-b875-4d7fc2981007 , que, para meu gosto estragado, é francamente um quebra-queixo. Garantir que os rótulos sejam únicos agora muda para você, mas o que você recebe em troca é o significado do rótulo./dev-link baseado na nomenclatura ao comandar um batalhão de VMs de vida relativamente curta e de baixa manutenção que são a geração da mesma imagem, e você não apostaria seu salário semanal que todos os UUIDs cumprem a promessa UU. Qualquer serviço de VM sensato , seja Vyper-H em seu próprio servidor físico ou Kugel Cloud ou qualquer coisa, nunca deve chamar sua unidade de inicializaçãosde, e a segunda e única outrasdc². Em uma máquina física, por outro lado, você pode facilmente obter o mesmo arranjo conectando cabos SATA de forma criativa.Eu discordo agora, mas neste cenário, eu sigo o mesmo caminho com a chamada nomenclatura da interface Ethernet “consistente”: desabilite-a nas VMs. Não me entenda mal, a nomenclatura é realmente consistente, desde que a NIC que você colocar no slot PCI 4 não salte de repente para o slot 5 por sua própria vontade enquanto você não estiver olhando (ou talvez até mesmo enquanto estiver; NICs não tem vergonha nenhuma). Infelizmente, no meio do “batalhão de VMs”, eles de fato o fazem. Neste caso, contra-intuitivamente,
eth0é mais consistente do queenp0s4f6. O provedor de VM não prometeu sempre colocar sua NIC virtual número 1 no slot 4 do barramento PCI 0 (e nenhuma das 3 entidades mencionadas são fisicamente reais), e que sempre será a Função 6. dependem muito da primeira interface vir antes da segunda, considerando que normalmente possuem o mesmo módulo de driver, comumente da família virtio (e se a primeira NIC nem sempre foreth0, a mesma nota² ainda se aplica).¹ Figurativamente, é claro. Eu estive neste negócio por muito tempo para ter algum sobrando.
² Se o fizessem, eu consideraria seriamente
fugir gritando delesmudando o provedor ou o software do hipervisor da VM.Ambos os esquemas podem ser misturados e combinados com a maioria das distribuições Linux.
As consequências podem ser desejáveis ou indesejáveis dependendo do caso de uso - por exemplo, pode-se preferir o esquema mais antigo (e até mesmo desabilitar os hacks de persistência no estilo udev) se a substituição a quente de unidades (hardware virtual ou hardware real) sem ter que modificar os arquivos de configuração for desejado.
A resposta à sua segunda pergunta ("por que esse esquema de endereçamento continua a ser usado?") é, eu acho, inércia. Sim, é totalmente possível usar apenas UUIDs em discos particionados GPT. Você pode usar UUIDs em vez de
/dev/xxxnomes em arquivos/etc/fstab. E agora que temos a Discoverable Partitions Specification , em muitos casos você nem precisa mais especificar os UUIDs, apenas particione seu disco com o tipo de partição e as partições serão selecionadas automaticamente. Na minha máquina, aroot=entrada está completamente ausente na linha de comando do kernel.E por falar em carregadores de inicialização: o GRUB é principalmente supérfluo em PCs UEFI modernos, no sentido de que tem muito pouco a ver com a inicialização da máquina. Atualmente o GRUB funciona apenas como um programa seletor de kernel, para o qual existem alternativas mais simples e melhores disponíveis, como systemd-boot.