Resumo rápido

  • O Ubuntu lê um "código de barras" de hardware (uma string modalias ) de cada dispositivo da sua máquina e a compara com padrões presentes nos pacotes disponíveis. Se houver correspondência, instala um pequeno pacote stub que desbloqueia o kernel e drivers corretos para seu hardware, tudo durante a instalação, sem que você precise tocar em nada.
  • O metapacote OEM não faz quase nada por si só. Seu único trabalho é adicionar um arquivo de fonte APT e instalar uma chave de assinatura. Os drivers e o kernel reais vêm do repositório que esse arquivo habilita. É uma chave, não um payload.
  • O Ubuntu tem três trilhas de kernel separadas: GA (estável, acompanha o LTS, 5 anos de suporte ), HWE (kernels mais novos trazidos de versões intermediárias, rolantes a cada 6 meses ) e OEM (construído para hardware certificado específico ). Estar em uma não significa estar em outra; você pode verificar com ubuntu-drivers list-oem e hwe-support-status.
  • O kernel OEM não é vinculado ou propriedade de fabricantes como Dell, Lenovo ou HP. Ele é publicado no arquivo regular do Ubuntu e construído pela equipe HWE da Canonical, com os fabricantes contribuindo com patches e requisitos, mas sem controlar o kernel em si. Qualquer um pode instalá-lo e executá-lo, mesmo em hardware não certificado (embora haja pouco benefício em fazê-lo ).

Introdução

Você acabou de instalar o Ubuntu em um laptop certificado. Em segundos após a primeira inicialização, os controles do ventilador funcionam, as teclas de função respondem e o kernel correto já está em execução. Você não instalou um único driver manualmente. Então, o que aconteceu?

O instalador do Ubuntu identificou seu hardware e cuidou silenciosamente de tudo. Este artigo explica exatamente como, desde o primeiro escaneamento de hardware até a reinicialização final. Seja você um usuário de desktop simplesmente curioso ou um sysadmin que precisa controlar esse comportamento em uma implantação automated, tudo o que precisa está aqui.

1. O problema que o Ubuntu está resolvendo para você

Nem toda máquina funciona perfeitamente com uma instalação genérica do Ubuntu. Fabricantes de hardware como Dell, Lenovo e HP frequentemente enviam laptops e servidores com componentes que precisam de um cuidado extra: um ajuste personalizado no kernel, um arquivo de firmware ou um driver que não faz parte do conjunto padrão de pacotes do Ubuntu.

Sem o software certo, você pode acabar com suspensão e retomada quebradas, um ventilador que nunca gira ou uma GPU que funciona com metade da velocidade. A resposta da Canonical é um sistema de detecção integrado ao instalador do Ubuntu, chamado Subiquity, que identifica seu hardware durante a configuração e instala automaticamente o melhor kernel e pacote de drivers para sua máquina.

1.1. O que é o Subiquity?

Subiquity, também conhecido como "ubiquity para servidores", é o framework de instalação por trás do Ubuntu Server desde o Ubuntu 20.04. Ele também fornece a configuração de primeira inicialização para o Ubuntu Core. A partir do Ubuntu 23.04, o Subiquity também se tornou o backend do instalador do Ubuntu Desktop, substituindo o antigo Ubiquity (instalador GTK/Qt ).

Você pode identificá-lo por sua interface limpa baseada em texto durante instalações de servidor e sua interface gráfica no desktop. Ambos compartilham a mesma lógica de backend para detecção OEM e HWE.

2. GA, HWE e OEM: três kernels, três trabalhos

Antes de mergulhar em como a detecção funciona, você precisa entender as três trilhas de kernel que o Ubuntu oferece. Muitos guias pulam essa explicação, e isso torna o resto confuso.

2.1. Kernel GA (General Availability )

Este é o kernel que acompanha uma versão LTS do Ubuntu no dia do lançamento. É estável, bem testado e recebe atualizações de segurança durante a janela de suporte LTS padrão de 5 anos. O Ubuntu Server usa o kernel GA por padrão. Para a maioria dos servidores de produção com hardware antigo ou comum, o kernel GA é exatamente o que você deseja.

Você pode, claro, estender o suporte para até 15 anos ativando o Ubuntu Pro. Mais detalhes no link abaixo:

2.2. Kernel HWE (Hardware Enablement )

O Ubuntu lança uma nova versão intermediária a cada seis meses (ex.: 26.10, 27.04 ). Cada uma delas vem com um kernel mais novo.

A pilha HWE traz esses kernels mais novos para a versão LTS. Então, se você está no Ubuntu 26.04 LTS, mas precisa de um kernel do Ubuntu 26.10 para suportar um chip Wi-Fi novo, a pilha HWE entrega isso.

O Ubuntu Desktop usa a pilha HWE por padrão. Cada kernel HWE não final geralmente recebe cerca de 6 meses de atualizações de segurança antes que o sistema avance para o próximo.

A exceção é o kernel HWE final em cada ciclo LTS: esse kernel se torna o kernel GA da próxima versão LTS e recebe a janela completa de suporte LTS de 5 anos a partir desse ponto.

2.3. Kernel OEM

Este é o mais específico dos três. A equipe de Hardware Enablement da Canonical constrói e mantém kernels OEM em estreita colaboração com fabricantes de hardware como Dell e Lenovo.

Um kernel OEM frequentemente inclui drivers de dispositivo e patches que ainda não foram aceitos no kernel Linux upstream ou no kernel Ubuntu genérico, por exemplo, um driver gráfico Intel novo ou uma correção para leitor de cartão Realtek.

Pense nele como uma área de preparação: patches que chegam ao kernel OEM hoje tendem a se formar no kernel Ubuntu genérico em uma versão futura.

Ponto chave: Se ubuntu-drivers list-oem retornar um resultado na sua máquina, você está na trilha OEM, não na HWE. Ambas são separadas. Executar uma não significa que você está executando a outra.

3. Impressões digitais de hardware: o que é um modalias

Para corresponder seu hardware ao pacote de driver correto, o sistema precisa de uma maneira de identificar cada dispositivo dentro da sua máquina. O Linux resolve isso com algo chamado modalias.

Pense nisso como um código de barras que cada dispositivo de hardware transmite. O kernel Linux lê esses códigos de barras do hardware e os armazena em uma pasta especial chamada /sys. Você pode lê-los você mesmo:

$ cat /sys/devices/pci0000:00/0000:00:1b.0/modalias
pci:v00008086d00003B56sv000017AAsd0000215Ebc04sc03i00

Essa longa string segue uma estrutura clara. Ela codifica o ID do fabricante, o ID do dispositivo, o subsistema fabricante, o ID do subsistema dispositivo e a classe do dispositivo. Em termos simples, ela diz algo como: "Este é um chip de áudio Intel dentro de um laptop Lenovo."

Agora, pacotes de driver que não fazem parte da instalação padrão do Ubuntu carregam um campo em seu arquivo debian/control chamado XB-Modaliases, gerado pela ferramenta dh_modaliases. Uma vez que o pacote é construído, isso se torna um cabeçalho Modaliases nos metadados do pacote, contendo uma lista de padrões glob (pense neles como curingas ) que correspondem a uma ou mais strings modalias.

Portanto, o processo de detecção é uma correspondência rápida de padrões: as impressões digitais do seu hardware versus as impressões digitais incorporadas nos pacotes disponíveis.

Como os pacotes OEM lidam com a correspondência de forma diferente

A correspondência por modalias funciona bem para drivers gerais, como pacotes de GPU Nvidia. Mas os metapacotes OEM precisam ser ainda mais precisos. Você quer corresponder a um modelo de laptop inteiro, não apenas um chip dentro dele. Então, duas abordagens existem:

Ambos os métodos produzem uma string modalias. Pacotes Dell e HP usam um padrão como pci:...bc0Csc05... (mirando na classe SMBus ), enquanto pacotes Lenovo usam um padrão como dmi:*bvnLENOVO:bvr...:pvr...*. De qualquer forma, o motor de correspondência funciona da mesma forma internamente.

4. A ferramenta por trás da mágica: ubuntu-drivers

O Subiquity não constrói essa lógica de detecção por si só. Em vez disso, ele chama uma ferramenta separada chamada ubuntu-drivers, que vem do pacote ubuntu-drivers-common. Esta ferramenta tem um trabalho principal: olhar para seu hardware e encontrar os pacotes certos para ele.

A função de detecção central vive no módulo Python UbuntuDrivers.detect. Importante, ela só precisa da biblioteca python-apt para funcionar. Ela não requer privilégios de root ou chamadas D-Bus, o que a torna rápida e segura para executar durante a instalação.

# Example: how ubuntu-drivers queries packages for a given modalias
import apt
from UbuntuDrivers import detect
apt_cache = apt.Cache()
packages = detect.packages_for_modalias(
apt_cache,
"pci:v000010DEd00002684sv000019DAsd00004675bc03sc00i00"
)
# Returns matching driver packages, e.g. nvidia-driver-550

E o hardware que não usa modaliases?

Alguns drivers simplesmente não podem usar correspondência por modalias. Por exemplo, um driver de modem pode precisar verificar /proc/asound/cards para saber se ele se aplica ao seu sistema.

Para esses casos especiais, ubuntu-drivers suporta plugins de detecção: pequenos scripts Python que vivem em /usr/share/ubuntu-drivers-common/detect/. Cada plugin exporta uma única função detect(apt_cache) que pode executar qualquer lógica personalizada e então retornar uma lista de pacotes correspondentes.

Nota: Plugins de detecção também não podem depender de privilégios de root. A Canonical projetou toda a pilha de detecção para ser executada com segurança em um ambiente restrito, como dentro do snap do Subiquity durante a instalação.

5. O que um metapacote OEM realmente faz

A palavra "metapacote" pode parecer intimidante, mas a ideia é simples. Um metapacote OEM é quase vazio por si só. Ele não envia arquivos de kernel, blobs de firmware ou documentação. Em vez disso, ele faz três coisas específicas quando você o instala:

Passo 1: Adiciona um novo arquivo de fonte APT

Ele instala um arquivo .list em /etc/apt/sources.list.d/ que aponta para o arquivo OEM da Canonical. Isso desbloqueia o acesso a pacotes que não fazem parte do repositório padrão do Ubuntu.

Passo 2: Instala a chave de assinatura OEM

Ele também depende do pacote ubuntu-oem-keyring, para que seu sistema confie em pacotes desse arquivo OEM. Sem a chave, o APT rejeitaria esses pacotes como não confiáveis.

Passo 3: Puxa o suporte de hardware real

Do arquivo OEM recém-habilitado, ele puxa o kernel real, firmware e pacotes de driver que seu hardware precisa. Por exemplo, um pacote nomeado no padrão oem-somerville-<codename>-meta (esquema de nomenclatura interno da Canonical e Dell para seu projeto OEM, onde <codename> é um codinome interno de dispositivo, não um número de modelo de varejo ) puxa tudo necessário para uma plataforma Dell certificada específica.

Qual kernel um pacote OEM puxa

Metapacotes OEM também podem influenciar qual kernel seu sistema inicializa. Na prática, as dependências de um metapacote OEM podem apontar para um pacote de kernel específico OEM ou para o kernel genérico/HWE padrão, dependendo de como o suporte para aquela plataforma específica foi construído. A maioria do hardware certificado acaba no kernel específico OEM, já que é onde os patches específicos da plataforma residem.

Nota: Um metapacote OEM não é um driver, é uma chave que desbloqueia um arquivo inteiro de suporte de hardware e então entrega a instalação aos pacotes dentro desse arquivo.

O kernel OEM é vinculado a fabricantes específicos?

Não. Apesar do nome, o kernel OEM não é um recurso privado e exclusivo do fabricante. A Canonical o publica no arquivo do Ubuntu, e qualquer um pode instalá-lo e usá-lo em seu dispositivo.

Ele simplesmente recebe esse nome pelo fato de a Canonical construí-lo em estreita colaboração com parceiros de hardware. Os patches dentro dele visam hardware específico, mas nada impede que você o execute em qualquer máquina compatível.

6. O que mudou no Ubuntu 26.04

Antes do Ubuntu 26.04, a detecção automatica de metapacotes OEM e HWE era, por padrão, um recurso focado no Desktop.

Se você instalasse o Ubuntu Server em hardware certificado, o comportamento padrão do instalador não puxava o metapacote OEM ou HWE correspondente. Você tinha que adicioná-lo manualmente após o fato, um passo fácil de perder durante uma implantação apressada.

As notas de versão do Subiquity 26.04 descrevem uma mudança aqui: a partir da ISO do Ubuntu 26.04 Server, se o instalador encontrar um metapacote OEM ou HWE correspondente para seu hardware, ele é instalado automaticamente durante a instalação do Server também, aproximando o Server do comportamento de longa data do Desktop.

Há uma sutileza que vale a pena conhecer se você escreve configs de instalação automatica. No momento desta escrita, a documentação de referência de instalação automatica do Subiquity ainda descreve o padrão auto da chave oem.install como habilitando a instalação de metapacote OEM "no Ubuntu Desktop, mas não no Ubuntu Server."

Em outras palavras, a mudança descrita nas notas de versão do 26.04 parece viver no nível do que a imagem de instalação do Server faz por padrão, em vez de uma mudança documentada no padrão do esquema oem.install: auto em si.

Se você está construindo implantações automated de Server e quer ter certeza de que um metapacote OEM será instalado quando um estiver disponível, a abordagem mais segura ainda é definir oem: install: true explicitamente em sua configuração de instalação automatica. Além disso, verifique a documentação atual para sua versão específica antes de confiar no comportamento padrão.

Isso importa especialmente para hardware de servidor. A Canonical certifica muitos servidores em rack, estações de trabalho e nós de computação densa de grandes fabricantes. Sem o metapacote OEM, você pode perder atualizações de firmware, ajustes de gerenciamento de energia ou suporte para interfaces de gerenciamento de hardware como IPMI ou Redfish.

Sob o capô:

A opção de instalação automatica oem: install aceita três valores: true, false e auto. O padrão documentado é auto.

Qualquer que seja o comportamento padrão exato em sua versão instalada, o nome da chave e os três valores aceitos (true / false / auto ) são estáveis e documentados, então definir explicitamente oem: install: true ou oem: install: false é uma maneira confiável de obter um resultado previsível.

7. O fluxo completo, passo a passo

Agora vamos juntar tudo. Aqui está exatamente o que acontece quando você instala o Ubuntu em uma máquina suportada, desde o momento em que o instalador inicia até o momento em que você reinicia.

Passo 1 - Subiquity chama ubuntu-drivers

No início da instalação, o controlador OEM dentro do Subiquity chama ubuntu-drivers list-oem. Este comando escaneia cada dispositivo em seu sistema e coleta sua string modalias de /sys.

Passo 2 - ubuntu-drivers pesquisa o cache APT

Em seguida, ele compara as strings modalias do seu hardware com os cabeçalhos Modaliases em cada pacote que o instalador pode ver. Para pacotes OEM, ele também verifica strings DMI para hardware Lenovo e IDs de subsistema PCI para Dell e HP.

Passo 3 - Uma correspondência retorna um nome de pacote

Se existir um pacote OEM correspondente, por exemplo, um pacote oem-somerville-<codename>-meta para um laptop Dell certificado, então ubuntu-drivers o retorna. O Subiquity enfileira esse pacote para instalação junto com o sistema base.

Passo 4 - O metapacote é instalado

Durante a fase de instalação de pacotes, o Subiquity instala o metapacote OEM. Isso adiciona o arquivo de fonte APT, puxa a dependência do keyring e dispara uma puxada do arquivo OEM.

Passo 5 - Você reinicia no kernel correto Finalmente, o sistema reinicia. Como o pacote de kernel apropriado foi instalado durante a configuração, você inicializa diretamente no kernel adequado ao seu hardware. Sem passos manuais, sem comandos de acompanhamento.

Cuidado com conflitos de kernel: Se você também especificar um kernel manualmente em sua config de instalação automatica usando a chave kernel:, pode encontrar um conflito. O metapacote OEM pode exigir seu próprio pacote de kernel, e isso pode colidir com sua escolha explícita de kernel. O mesmo tipo de conflito pode surgir se você ativar um kernel FIPS ou em tempo real após a instalação, já que a entrada de configuração GRUB do kernel OEM pode ter prioridade na ordem de boot. Para evitar isso, remova a chave kernel: ou defina oem: install: false em sua config de instalação automatica.

8. Como verificar se sua máquina Ubuntu Linux recebeu um pacote OEM

Após a instalação, você pode verificar se sua máquina está executando um kernel OEM ou seguindo a pilha HWE. Aqui está uma verificação prática em duas etapas:

# Step 1: List any OEM metapackages on your system
$ ubuntu-drivers list-oem
# If this returns output, you are on the OEM track.
# If it returns nothing, your machine is on the GA or HWE track instead.
# Step 2: Confirm which kernel flavour you are running
$ uname -r
# OEM kernel example:  7.0.0-22-oem    <- note the -oem suffix
# GA / HWE example:    7.0.0-22-generic  <- both show -generic
# Step 3: Distinguish GA from HWE (both report -generic in uname -r)
$ hwe-support-status --verbose
# Output tells you whether the running kernel is a GA or HWE kernel
# and whether it is still within its support window.
# Alternative: check which HWE metapackage is installed
$ dpkg -l 'linux-generic-hwe-*' | grep ^ii
# A result here confirms you are on the HWE stack.
# No result means you are on the GA kernel.

O kernel OEM mostra -oem em sua string de versão, o que facilita identificá-lo.

Os kernels HWE e GA mostram -generic em uname -r, o que significa que você não pode distingui-los apenas pela string de versão.

Portanto, a maneira confiável de distingui-los é executar hwe-support-status --verbose, que informa em qual trilha o kernel em execução pertence e se ainda é suportado.

Se ubuntu-drivers list-oem retornar um resultado não vazio, a máquina está no ritmo OEM, não na trilha HWE.

Dica: A Canonical aconselha contra a troca manual de sabores de kernel em hardware certificado. Mudar de um kernel OEM para o kernel GA pode causar regressões no desempenho, suporte de hardware e recursos certificados.

9. Como controlar esse comportamento

Na maioria das vezes, você quer que o instalador lide com tudo automaticamente. Mas às vezes, por exemplo, em um ambiente empresarial com restrições de conformidade onde você fixa um kernel específico, você precisa desligar esse recurso. Você pode fazer isso com uma única chave em sua configuração de instalação automatica.

Desabilitar instalação OEM

# autoinstall.yaml
autoinstall:
version: 1
oem:
install: false   # skip OEM metapackage installation entirely

Forçar instalação OEM explicitamente

Se você quiser ter certeza de que um metapacote OEM será instalado quando um corresponder ao seu hardware, independentemente do comportamento padrão atual da plataforma, defina install: true explicitamente.

# autoinstall.yaml
autoinstall:
version: 1
oem:
install: true   # explicitly request OEM metapackage installation if one is found

Deixar no automatic (o padrão )

Se você não incluir a chave oem:, o instalador usa auto. Conforme documentado, auto destina-se a instalar um metapacote OEM quando um é encontrado no Ubuntu Desktop.

O comportamento do Server sob auto foi descrito de forma diferente por diferentes fontes da Canonical em torno do lançamento do Ubuntu 26.04, então se o comportamento previsível do Server é importante para você, defina install: true ou install: false explicitamente em vez de confiar em auto.

# This is what "auto" looks like explicitly:
autoinstall:
version: 1
oem:
install: auto   # default, documented as Desktop-focused

Remover a configuração OEM após a instalação

Mudou de ideia após a instalação? Você pode remover o metapacote OEM e desabilitar seu repositório APT a qualquer momento. A GUI software-properties e a CLI ubuntu-drivers suportam isso.

Remover o metapacote não quebra seu sistema em execução, apenas para de puxar atualizações do arquivo OEM.

# List installed OEM packages
$ ubuntu-drivers list-oem
# Remove a specific OEM metapackage
$ sudo apt remove oem-somerville-tentacool-meta
# Disable the OEM repository via the GUI
$ software-properties-gtk

10. Pontos-chave para lembrar

  • O Ubuntu oferece três trilhas de kernel: GA (estável, 5 anos ), HWE (mais novo, rolante a cada 6 meses por kernel, com o final herdando suporte LTS completo ) e OEM (hardware certificado, mantido pela equipe HWE da Canonical ). Elas são separadas; estar em uma não significa que você está em outra.
  • Cada dispositivo em sua máquina exporta uma string modalias para /sys. Esta string é a impressão digital que torna a detecção possível.
  • ubuntu-drivers faz a correspondência real. Ele compara suas impressões digitais de hardware com os cabeçalhos Modaliases nos pacotes disponíveis.
  • Um metapacote OEM é um stub mínimo. Seu trabalho real é habilitar um repositório APT e deixar os pacotes dentro dele fazerem o trabalho pesado.
  • O Ubuntu 26.04 trouxe a detecção automatica OEM e HWE para instalações Server de alguma forma, de acordo com as notas de versão do Subiquity, embora o padrão documentado oem.install: auto na referência de instalação automatica ainda descreva comportamento focado no Desktop. Se você precisa de comportamento garantido no Server, defina oem: install: true ou false explicitamente.
  • Execute ubuntu-drivers list-oem a qualquer momento para verificar se sua máquina está na trilha OEM.
  • Controle tudo com oem: install: true | false | auto em sua config de instalação automatica.

11. Perguntas frequentes (FAQ )

P: Qual é a diferença entre o kernel HWE e o kernel OEM?

R: O kernel HWE traz um kernel Linux upstream mais novo da versão intermediária mais recente do Ubuntu para sua base LTS. Ele visa uma ampla gama de hardware moderno, e cada kernel HWE não final é tipicamente suportado por cerca de 6 meses antes que o sistema avance para o próximo. O kernel HWE final em cada ciclo LTS é especial: ele se torna o kernel GA da próxima versão LTS e recebe a janela completa de suporte LTS de 5 anos.

O kernel OEM, por outro lado, visa um conjunto específico de plataformas de hardware certificadas. A Canonical o constrói em parceria com fabricantes como Dell e Lenovo, e ele frequentemente inclui patches que ainda não chegaram ao kernel mainline. Se ubuntu-drivers list-oem retornar um resultado em sua máquina, você está na trilha OEM, não na HWE. Elas são separadas.

P: O Ubuntu instala drivers automaticamente em todas as máquinas?

R: Não. A detecção automatica só é acionada quando o instalador encontra um metapacote OEM ou de driver correspondente no cache APT.

Máquinas que não aparecem na lista de certificação de hardware da Canonical não corresponderão a nenhum desses pacotes, e o instalador simplesmente continuará sem instalar um.

Para essas máquinas, os drivers padrão do Ubuntu lidam com tudo através do sistema de pacotes normal.

P: Posso instalar um kernel OEM manualmente sem reinstalar o Ubuntu?

R: Sim, em geral. Pacotes de kernel OEM são publicados no arquivo do Ubuntu e não estão bloqueados por restrições de fabricante ou instalações especiais.

O nome exato do pacote e o sufixo de sabor variam por versão e plataforma (a família de pacotes linux-oem-<release> é o padrão geral ), então verifique apt search linux-oem em seu sistema para encontrar o nome correto do pacote para sua versão do Ubuntu.

Dito isso, o kernel OEM é mais útil em hardware que a Canonical certificou. Executá-lo em hardware não certificado não oferece benefício adicional e pode introduzir comportamento inesperado.

P: O kernel OEM substitui o kernel HWE permanentemente?

R: Não. O kernel OEM é uma área de preparação. A Canonical mescla seus patches de volta ao kernel Ubuntu genérico em versões futuras. Portanto, recursos que seu kernel OEM carrega hoje eventualmente chegarão ao kernel genérico ou HWE mainline. Nesse ponto, sua máquina não precisará mais do sabor OEM para obter suporte completo de hardware.

P: Isso vai quebrar se eu também usar FIPS ou um kernel em tempo real?

R: Possivelmente. A entrada de configuração GRUB do kernel OEM pode ter prioridade na ordem de boot. Se você ativar posteriormente FIPS ou um kernel em tempo real, o sistema pode continuar inicializando no kernel OEM em vez disso.

Se você executa um ambiente sensível à conformidade, defina oem: install: false em sua config de instalação automatica antes da instalação, em vez de tentar desembaraçar o conflito depois.

P: Posso verificar se meu hardware é certificado antes de comprar?

R: Sim. A Canonical mantém um banco de dados público de certificação de hardware em ubuntu.com/certified.

Você pode pesquisar por fabricante, modelo e versão do Ubuntu para ver se uma máquina vem com um metapacote OEM e para qual versão do Ubuntu ela é certificada.

12. Concluindo

O sistema de detecção OEM e HWE que o Subiquity dirige é um ótimo exemplo do Linux "simplesmente funcionando."

Sob o capô, o processo é direto: uma varredura rápida do cache APT, uma correspondência de padrão modalias e um pacote stub que desbloqueia um arquivo inteiro de suporte de hardware. Nada disso é mágica, é apenas ferramentas bem projetadas trabalhando juntas.

Da próxima vez que o Ubuntu inicializar perfeitamente em seu hardware certificado logo após a instalação, você saberá exatamente o que aconteceu nos bastidores: uma varredura de código de barras, uma consulta de pacote e um pacote stub muito pequeno que colocou tudo em movimento.

Recursos: