Criar uma distribuição Linux mínima com Yocto no Ubuntu

Objetivo e contexto

O Yocto Project é uma ferramenta amplamente usada no mundo do Linux embarcado para gerar imagens personalizadas e reproduzíveis. Neste tutorial criamos uma distro mínima para o alvo qemux86-64 (emulador QEMU) e a executamos no QEMU. Este artigo foca no fluxo prático em uma máquina de desenvolvimento Ubuntu.

Importante: Yocto não é uma distribuição pronta; é um sistema de construção para gerar distribuições. Definição rápida: Poky é o ambiente de referência minimal do Yocto.

Variantes de intenção relacionadas

• criar imagem Yocto
• Yocto no Ubuntu
• build Yocto qemux86-64
• core-image-minimal Yocto
• rodar Yocto no QEMU

Pré-requisitos da máquina de desenvolvimento

• Memória RAM: 4–6 GB ou mais recomendado.
• Sistema: Ubuntu recente (ex.: 16.04 usado como exemplo). Use uma LTS estável para builds pesados.
• Espaço em disco: 60–80 GB livres (cache, downloads e builds ocupam espaço).
• Pacotes necessários instalados antes de começar.
• Baixar o branch estável do Poky (aqui usamos “morty”).

Execute:

apt-get update

Em seguida instale os pacotes de desenvolvimento necessários:

apt-get install wget git-core unzip make gcc g++ build-essential subversion sed autoconf automake texi2html texinfo coreutils diffstat python-pysqlite2 docbook-utils libsdl1.2-dev libxml-parser-perl libgl1-mesa-dev libglu1-mesa-dev xsltproc desktop-file-utils chrpath groff libtool xterm gawk fop

Nota: a instalação desses pacotes pode consumir quase 1 GB.

Clonar o Poky (ramo morty)

No diretório de trabalho, clone o Poky no branch “morty”:

 git clone -b morty git://git.yoctoproject.org/poky.git

Entre no diretório “poky” e prepare o ambiente OE (OpenEmbedded):

source oe-init-build-env

Esse script cria e troca para o diretório “build” para configurações posteriores.

Configuração do build: local.conf e bblayers.conf

O arquivo local.conf em build/conf controla o comportamento do Yocto: máquina alvo, SDK, cache, diretórios temporários e opções de imagem.

Edite build/conf/local.conf e defina a máquina alvo. Exemplo:

MACHINE ?= "qemux86-64"

Descomente e ajuste os diretórios recomendados (garante cache e downloads persistentes):

DL_DIR ?= "${TOPDIR}/downloads"

SSTATE_DIR ?= "${TOPDIR}/sstate-cache"

TMPDIR ?= "${TOPDIR}/tmp"

Outras opções úteis (exemplos):

PACKAGE_CLASSES ?= "package_rpm"
SDKMACHINE ?= "i686"

Para permitir login com root sem senha na imagem mínima (útil para desenvolvimento), adicione:

EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

Nota: “debug-tweaks” habilita, entre outras coisas, a conta root sem senha. Remova em imagens de produção.

Importante: não usamos GUI como Toaster aqui; todo o processo é via linha de comando.

Compilação com bitbake

Inicie a compilação da imagem mínima com:

bitbake core-image-minimal

Execute esse comando como usuário normal, não como root. Se executado como root, o bitbake abortará com erro de permissões.

Se ocorrer erro, re-carregue o ambiente e execute novamente:

source oe-init-build-env
bitbake core-image-minimal

O bitbake primeiro analisa as receitas e exibe o estado do sistema de build.

O download e a compilação podem levar muitas horas na primeira execução (geralmente 2–3 horas ou mais, dependendo da máquina e conexão). O processo baixa SDKs e pacotes e depois compila para a arquitetura alvo.

Ao final, o log de tarefas indica conclusão.

Os artefatos gerados ficam em build/tmp/deploy/images/qemux86-64.

Executando a imagem no QEMU

Algumas interfaces SSH/terminal remotas (ex.: PuTTY em certas configurações) podem apresentar problemas ao rodar QEMU interativamente. Se houver erro, tente abrir um terminal local na sessão RDP ou diretamente no Ubuntu.

Executando via RDP/terminal nativo, o QEMU abre a janela de emulação e a imagem inicializa.

A tela de login aparece; usuário padrão: root com senha em branco (se você usou debug-tweaks).

Faça login e teste comandos básicos:

Exemplos úteis após login:

date
ifconfig
uname -a

Checklists práticos

Checklist antes de iniciar:

• Ubuntu com espaço em disco suficiente (≥ 60 GB livre).
• Instalar pacotes listados em apt-get.
• Clonar o poky no branch desejado.
• Verificar usuário não-root ao rodar bitbake.

Checklist de pós-build:

• Confirme imagens em build/tmp/deploy/images/qemux86-64.
• Teste inicial no QEMU.
• Remova debug-tweaks para builds de produção.

Mini-metodologia de trabalho (5 passos)

1. Preparar ambiente e dependências.
2. Clonar Poky e iniciar oe-init-build-env.
3. Editar local.conf (MACHINE, DL_DIR, SSTATE_DIR, TMPDIR, EXTRA_IMAGE_FEATURES).
4. Executar bitbake core-image-minimal como usuário normal.
5. Testar em QEMU e iterar receitas/recursos conforme necessário.

Casos de teste básicos e critérios de aceitação

Cenários de aceitação simples:

• A imagem é gerada sem erros em bitbake.
• Arquivos esperados aparecem em build/tmp/deploy/images/qemux86-64.
• QEMU inicializa e apresenta prompt de login.
• Comandos básicos (date, uname) executam corretamente.

Testes adicionais:

• Remova debug-tweaks e verifique que a conta root exige senha (segurança).
• Habilite rede na imagem e confirme conectividade.

Problemas comuns e soluções rápidas

• Erro: “Do not run bitbake as root” — Solução: Troque para usuário normal e re-run source oe-init-build-env.
• Espaço insuficiente — Libere espaço, especialmente em TMPDIR e SSTATE_DIR.
• Falhas no download — Verifique proxy/ firewall e repita o build; os downloads permanecem em DL_DIR para reutilização.
• QEMU travando em PuTTY — Use um terminal gráfico local (RDP ou console físico) para rodar o QEMU.

Quando o método falha (contraexemplos)

• Máquina com <4 GB RAM possivelmente falhará em compilar grandes pacotes.
• Conexão lenta/instável prolonga muito o tempo de download, tornando o processo pouco prático.

Papéis e responsabilidades (checklist por função)

• Desenvolvedor embarcado:
  • Editar receitas e testar builds locais.
  • Iterar sobre pacotes e dependências.
• Engenheiro de QA:
  • Validar critérios de aceitação, rede e serviços.
  • Rodar testes funcionais dentro do QEMU.
• Administrador de build:
  • Manter espaço em disco, caches e SSTATE.
  • Atualizar dependências do host.

Glossário (1 linha cada)

• Yocto Project: sistema de construção para gerar distribuições Linux embarcadas.
• Poky: repositório de referência do Yocto com bitbake e camadas básicas.
• bitbake: ferramenta de build que processa receitas e gera imagens.
• QEMU: emulador que executa a imagem gerada em arquitetura simulada.

Notas de segurança e produção

• Nunca distribua imagens com debug-tweaks habilitado em produção.
• Reforce senhas, serviços e usuários antes de liberar a imagem ao campo.

Resumo final

Criar uma distribuição mínima com Yocto no Ubuntu envolve preparar o host, clonar o poky (ramo estável), configurar local.conf e executar bitbake como usuário normal. O processo baixa dependências e compila a imagem, que pode levar horas na primeira execução. Teste a imagem em QEMU e remova opções de desenvolvimento antes de implantar em produção.

Principais pontos:

• Use SSTATE_DIR e DL_DIR para cache e reduzir builds subsequentes.
• Sempre execute bitbake como usuário normal.
• debug-tweaks facilita desenvolvimento, mas não é seguro para produção.

Obrigado por seguir este guia. Se precisar de um playbook de automação (scripts de CI/CD para Yocto) ou matrizes de compatibilidade entre branches, posso fornecer modelos e exemplos adaptados ao seu ambiente.