Void Linux no escuro: instalação manual, i3, zsh e um boot de 6 segundos

Disclaimer: este post não pretende substituir a documentação oficial do Void Linux e definitivamente não é um guia de instalação que tenta cobrir hardware, layouts de disco e todos os cenários possíveis.

O que vem abaixo é mais próximo de um relato técnico guiado: os passos que eu segui, as decisões que tomei e os erros que cometi enquanto instalava o sistema manualmente.

Se a intenção é simplesmente instalar Void, use o void-installer. Se a intenção é fazer uma instalação manual e entender cada etapa, siga o guia de instalação via chroot do Void Linux Handbook. A documentação oficial é a referência. Este texto é a história de alguém deliberadamente tentando ver até onde conseguiria chegar sem transformar a instalação em uma prova acadêmica.

Eu não estava procurando uma nova distribuição.

Uso Arch, gosto do Arch e não havia nenhum problema específico que eu estivesse tentando resolver. O Void apareceu muito mais como curiosidade.

É uma distribuição independente, tem seu próprio gerenciador de pacotes, não usa systemd e, apesar de aparecer com alguma frequência em discussões entre usuários mais entusiastas de Linux, eu nunca tinha parado para realmente instalar e usar.

Então resolvi fazer o experimento da forma que parecia mais divertida: baixei a ISO base com glibc e decidi instalar manualmente.

Sem desktop environment pronto. Sem Hyprland. Sem tentar reproduzir imediatamente meu ambiente principal.

A ideia era ver quanto do processo eu conseguiria resolver apenas aplicando o que já sabia sobre Linux, consultando a documentação quando necessário e aceitando que provavelmente alguma coisa seria quebrada no caminho.

Quebrei.

Mas menos do que esperava.

O plano

A configuração que eu queria era simples: Void Linux x86_64 com glibc, Btrfs, GRUB, runit, Xorg, i3, zsh, autocomplete, autosuggestions e Fastfetch, porque existem limites para o minimalismo.

Nada disso foi escolhido pensando em produzir o sistema mais exótico possível.

Na verdade, fiz o contrário.

Escolhi glibc em vez de musl porque o experimento era sobre conhecer o Void, não descobrir quantas aplicações do meu desktop assumem silenciosamente a existência da glibc.

Escolhi X11 e i3 porque queria uma sessão gráfica simples e previsível.

Mantive GRUB porque já conhecia, funcionava e eu não estava tentando ganhar pontos extras por originalidade no bootloader.

E mudei o filesystem para Btrfs porque é o filesystem que eu preferia usar nesse tipo de instalação.

O objetivo era reduzir o número de variáveis desconhecidas e deixar o Void ser a variável desconhecida.

Preparando o disco

A ISO base já entrega o suficiente para começar.

Primeiro:

lsblk

No meu caso o disco da instalação era /dev/sda.

Obviamente, isso não significa que o seu será.

Pode ser /dev/nvme0n1, /dev/vda, outra coisa completamente diferente ou aquele disco externo que você definitivamente não queria formatar.

Vale conferir antes de continuar.

Para particionar:

cfdisk /dev/sda

Eu separei uma partição FAT32 para a ESP, uma partição Btrfs para / e outra partição Btrfs para /home.

A partição EFI ficou próxima de 1 GiB. Não existe nenhuma necessidade especial de dar esse espaço todo ao GRUB, mas espaço em disco não era exatamente a restrição mais importante desse experimento.

Depois formatei:

mkfs.vfat -F32 /dev/sda1
mkfs.btrfs -f /dev/sda2
mkfs.btrfs -f /dev/sda3

E comecei a montar o futuro sistema:

mount /dev/sda2 /mnt

mkdir -p /mnt/boot/efi
mkdir -p /mnt/home

mount /dev/sda1 /mnt/boot/efi
mount /dev/sda3 /mnt/home

É aqui que vale introduzir o primeiro personagem importante da história: a minha capacidade de cometer um erro extremamente simples depois de acertar as partes mais complicadas.

A /home e o erro mais besta da instalação

Em uma das tentativas eu configurei a partição da home de forma errada.

A instalação terminou.

O sistema iniciou.

O usuário kristyan existia.

Eu conseguia autenticar.

E, depois do login, fui recebido por uma situação maravilhosa: meu usuário parecia não ter permissão para absolutamente nada.

Até operações extremamente básicas começaram a parecer suspeitas.

Minha primeira reação foi pensar em grupos, sudo, permissões, ownership, configuração do usuário e qualquer outra explicação interessante.

A explicação era muito menos interessante.

Minha configuração de /home estava errada e a sessão acabava me deixando em /root.

Naturalmente, um usuário normal não deveria passear livremente pelo diretório pessoal do root.

Não era um misterioso problema de permissões do Void.

Era eu.

Depois de corrigir o mountpoint da home, o problema de permissões desapareceu.

Esse tipo de erro é uma das razões pelas quais gosto de instalações manuais. Quando algo quebra, normalmente existe uma relação razoavelmente direta entre o que você configurou e a consequência.

Às vezes a relação é simplesmente você ter esquecido de montar a home.

Não existe abstração capaz de proteger o usuário de si mesmo.

Bootstrap do Void com XBPS

Com os filesystems montados, começa a parte que realmente instala o sistema.

Para uma instalação x86_64 com glibc:

REPO=https://repo-default.voidlinux.org/current
ARCH=x86_64

O XBPS precisa das chaves usadas para verificar os pacotes:

mkdir -p /mnt/var/db/xbps/keys
cp /var/db/xbps/keys/* /mnt/var/db/xbps/keys/

Depois é possível instalar o sistema base diretamente no novo root:

XBPS_ARCH=$ARCH xbps-install \
  -S \
  -r /mnt \
  -R "$REPO" \
  base-system btrfs-progs

Essa etapa demora conforme sua conexão, seu mirror e o humor da infraestrutura entre você e o servidor.

Foi justamente aqui que encontrei uma das coisas menos agradáveis da experiência com Void.

A latência dos mirrors não foi particularmente boa para mim.

O Void possui uma rede consideravelmente menor de mirrors do que distribuições maiores e, no Brasil, a diferença é perceptível. O download não transformou a instalação em uma tragédia, mas definitivamente foi a parte em que mais fiquei olhando para barras de progresso.

Ironicamente, esperar os pacotes demorou muito mais do que configurar boa parte do sistema.

fstab, meu primeiro tropeço e o chroot

Depois do bootstrap, é hora de descrever ao sistema onde os filesystems devem ser montados.

Com tudo montado corretamente:

xgenfstab -U /mnt > /mnt/etc/fstab

Eu tive um problema nessa etapa durante a primeira instalação.

Foi um daqueles momentos em que a instalação manual lembra que o fstab não tem nenhuma obrigação de adivinhar o que você queria fazer. O arquivo só pode refletir corretamente aquilo que está montado e configurado corretamente no momento em que ele é criado.

Por isso, antes de continuar:

cat /mnt/etc/fstab

Não trate o arquivo como uma cerimônia burocrática antes do chroot.

Leia.

Confirme /.

Confirme /home.

Confirme a ESP.

Especialmente /home.

Depois disso:

xchroot /mnt /bin/bash

E finalmente temos aquela sensação familiar de uma instalação manual: você está dentro do sistema que ainda não iniciou nenhuma vez.

É basicamente Linux em estado embrionário.

Hostname, locale e configuração básica

Dentro do chroot, comecei pelo básico.

Hostname:

echo "void" > /etc/hostname

Depois revisei:

vi /etc/rc.conf

Como escolhi uma imagem glibc, também configurei os locales em:

vi /etc/default/libc-locales

E regenerei:

xbps-reconfigure -f glibc-locales

Também defini a senha do root:

passwd

Nada particularmente diferente de qualquer outra instalação manual de Linux.

Essa foi uma impressão que continuou aparecendo durante todo o processo.

Void tem ferramentas diferentes.

A estrutura conceitual não é diferente.

Você continua configurando filesystem, locale, hostname, usuários, bootloader, initramfs, serviços e uma sessão gráfica.

Os nomes mudam.

Linux continua sendo Linux.

Criando o usuário

Criei meu usuário normalmente:

useradd -m -G wheel,audio,video -s /bin/bash kristyan
passwd kristyan

O wheel seria usado para privilégios administrativos.

Depois:

visudo

E habilitei:

%wheel ALL=(ALL) ALL

Eu ainda mantive Bash como shell durante a instalação.

Trocar para zsh antes de saber se o sistema inicia é um daqueles tipos de customização que não oferecem nenhuma vantagem real.

Primeiro o computador liga.

Depois o prompt fica bonito.

GRUB e initramfs

Eu poderia ter usado isso como desculpa para testar outro bootloader.

Não usei.

GRUB funciona, eu já conhecia e havia problemas mais interessantes para criar.

Em UEFI:

xbps-install -S grub-x86_64-efi

Depois:

grub-install \
  --target=x86_64-efi \
  --efi-directory=/boot/efi \
  --bootloader-id="Void"

E então:

xbps-reconfigure -fa

Essa última etapa é particularmente conveniente no Void porque a reconfiguração dos pacotes também dispara o que precisa ser reconstruído, incluindo initramfs e configuração do GRUB.

Quando isso terminou, saí do chroot:

exit

Desmontei:

umount -R /mnt

E reiniciei.

reboot

Aquele primeiro boot depois de uma instalação manual sempre tem um pequeno momento de negociação espiritual com o computador.

O GRUB apareceu.

Selecionei Void.

O kernel iniciou.

O sistema subiu.

Ótimo.

Agora faltava transformar uma TTY em um computador que eu realmente usaria.

Runit era a parte que eu esperava odiar

Essa talvez tenha sido a maior surpresa da experiência.

Estou muito mais habituado ao systemd.

Também já usei OpenRC o suficiente para não estranhar completamente um init diferente.

Mesmo assim, antes de instalar Void eu imaginava que runit seria uma das partes em que eu precisaria parar constantemente para consultar documentação.

Aconteceu o contrário.

A ideia básica é quase ofensivamente simples.

Os serviços disponibilizados pelos pacotes ficam em:

/etc/sv/

Os serviços habilitados aparecem no runsvdir ativo, normalmente acessível por:

/var/service/

Quer habilitar um serviço?

sudo ln -s /etc/sv/dbus /var/service/

Quer olhar o estado?

sudo sv status dbus

Quer reiniciar?

sudo sv restart dbus

Quer parar?

sudo sv down dbus

Quer subir?

sudo sv up dbus

Quer desabilitar?

Remove o link.

sudo rm /var/service/dbus

Acabou.

Claro que runit tem mais coisas do que cinco comandos e um symlink. Mas para administrar os serviços de um desktop simples, a experiência inicial foi essa.

Eu esperava sentir falta de:

systemctl enable --now alguma-coisa.service

Em poucos minutos eu já estava tratando:

ln -s /etc/sv/alguma-coisa /var/service/

como algo completamente normal.

Não precisei aprender runit antes de usar runit.

Eu precisava entender uma ideia.

Depois disso as coisas começaram a encaixar.

Xorg e i3

Eu deliberadamente não quis instalar Hyprland.

Não porque exista algum problema especial entre Hyprland e Void, mas porque eu já passo tempo suficiente brincando com Wayland, compositores e shells customizados.

Para esse experimento eu queria a rota mais previsível possível.

Xorg.

i3.

Fim.

Instalei a base gráfica:

sudo xbps-install -S \
  xorg \
  xinit \
  mesa-dri \
  i3 \
  i3status \
  dmenu \
  dbus \
  elogind

Habilitei o D-Bus:

sudo ln -s /etc/sv/dbus /var/service/

Antes de colocar um display manager no caminho, preferi verificar se a sessão gráfica funcionava.

Criei:

printf '%s\n' 'exec /bin/i3' > ~/.xinitrc

E rodei:

startx

i3 abriu.

Esse é um ponto em que a instalação deixa oficialmente de parecer uma instalação e começa a parecer um sistema.

Uma TTY funcional significa que Linux iniciou.

Um window manager abrindo significa que eu já começo a pensar onde vou colocar terminal, launcher, barra, wallpaper e vinte configurações que não têm absolutamente nenhuma relação com produtividade.

Um greeter sem transformar isso em um desktop environment

Depois de validar o X manualmente, coloquei um display manager simples.

A escolha natural para esse setup foi LightDM com o GTK greeter:

sudo xbps-install -S lightdm lightdm-gtk-greeter

Com runit, habilitar o LightDM segue exatamente a mesma lógica:

sudo ln -s /etc/sv/lightdm /var/service/

Antes de habilitar serviços desse tipo definitivamente, vale testá-los.

Uma das coisas boas do runit é que o modelo continua previsível mesmo quando o serviço muda completamente.

D-Bus, daemon de rede, display manager. Para o supervisor, continuam sendo processos supervisionados.

Depois do próximo boot, o caminho já estava completo:

GRUB
- kernel
- runit
- LightDM
- Xorg
- i3

Sem desktop environment escondendo metade da sessão.

Era exatamente o que eu queria.

Finalmente, zsh

Com o sistema gráfico funcionando, chegou a etapa realmente crítica da instalação: fazer o terminal parar de parecer recém-instalado.

Instalei zsh, completions, autosuggestions e Fastfetch:

sudo xbps-install -S \
  zsh \
  zsh-completions \
  zsh-autosuggestions \
  fastfetch

Depois troquei o shell:

chsh -s "$(command -v zsh)"

No .zshrc, habilitei completion:

autoload -Uz compinit
compinit

E autosuggestions:

source /usr/share/zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh

Por último:

fastfetch

Sim, toda nova shell abre com Fastfetch.

Não existe justificativa técnica.

É obrigatório.

A essa altura o sistema já tinha passado do estágio “Void instalado” para “meu computador”.

i3 funcionando.

zsh funcionando.

completion funcionando.

suggestions funcionando.

Fastfetch me lembrando a cada terminal qual distribuição eu estava usando, caso todo o processo anterior não tivesse sido suficiente.

XBPS é interessante. A disponibilidade de pacotes nem sempre é

XBPS foi outra parte que gostei bastante.

Os comandos demoram alguns minutos para deixar de parecer estranhos:

sudo xbps-install -S pacote

para instalar.

sudo xbps-install -Su

para atualizar.

xbps-query -Rs pacote

para pesquisar.

Depois disso, ele simplesmente funciona.

O problema para mim apareceu em outro lugar: o ecossistema de pacotes.

Quem vem do Arch fica mal-acostumado.

Existe o repositório oficial.

Se não estiver lá, provavelmente existe no AUR.

Se não existir no AUR, alguém vai criar um PKGBUILD em algum momento porque aparentemente existe um usuário Arch disposto a empacotar qualquer software já compilado pela humanidade.

Void tem outra dinâmica.

Existe o void-packages, uma coleção comunitariamente mantida de templates usada para construir os pacotes da distribuição.

Quer adicionar um pacote oficialmente?

O fluxo passa pelo repositório, pelo template, pelo build, pelo teste, pelo pull request, pela revisão e pelo merge.

Eu entendo perfeitamente o motivo.

Esse modelo centraliza revisão, padroniza empacotamento e coloca os pacotes dentro de um processo de manutenção comum.

Mas ainda parece estranho quando sua referência é o AUR.

Principalmente quando você só quer instalar uma aplicação relativamente comum e percebe que ela simplesmente não está no XBPS.

Não existe um AUR oficial do Void esperando no segundo estágio.

O modelo é community-driven, não um repositório comunitário permissivo separado da coleção oficial.

Essa diferença é pequena semanticamente e enorme na experiência de uso.

Naturalmente isso me deu uma ideia ruim

Minha primeira reação ao encontrar pacotes ausentes não foi simplesmente instalar de outra forma.

Foi pensar em manter outro repositório.

Isso provavelmente diz mais sobre mim do que sobre Void.

XBPS suporta repositórios customizados, incluindo repositórios remotos assinados, então tecnicamente existe uma base muito interessante para algo assim.

A ideia seria complementar o ecossistema oficial com um repositório mais permissivo e agressivo em atualizações.

Não competir com void-packages.

Não criar uma distribuição nova.

Não transformar segurança de supply chain em “confia”.

A proposta seria oferecer uma camada complementar para pacotes que não entram no repositório oficial, aplicações mais niche, versões mais recentes, ferramentas de desktop, software que muda rápido demais para uma política mais conservadora e pacotes que façam sentido para usuários avançados, mas talvez não para a coleção principal.

O usuário continuaria tendo a experiência que importa:

sudo xbps-install pacote

A complexidade ficaria do lado de quem mantém o repositório.

Automação de builds, atualização de versões, assinatura, CI, arquiteturas suportadas e política de manutenção seriam a parte realmente interessante.

Talvez isso vire projeto.

Talvez seja só o efeito colateral esperado de deixar alguém que gosta de infraestrutura usar uma distribuição com pacotes faltando.

E então o Void iniciou em aproximadamente seis segundos

Esse foi o momento em que o experimento ganhou outra dimensão.

Eu não havia feito uma instalação obsessivamente otimizada.

Não recompilei kernel.

Não substituí GRUB por alguma solução escolhida especificamente por velocidade.

Não passei horas desabilitando serviços para postar um benchmark.

Eu simplesmente tinha uma instalação base, runit, os serviços necessários, Xorg, i3 e GRUB.

E o boot ficou na casa dos seis segundos a partir da confirmação no bootloader.

Foi o setup mais rápido que já tive.

O detalhe curioso é que isso apareceu quase como consequência, não como objetivo.

Quando você instala apenas aquilo que precisa e usa um supervisor extremamente pequeno, sobra pouca coisa para acontecer entre o GRUB e um sistema utilizável.

Não estou dizendo que runit é melhor porque bootou seis segundos.

Boot time isoladamente é uma métrica relativamente pobre para avaliar um init system.

Também não estou transformando isso em argumento contra systemd. O systemd resolve uma quantidade muito maior de problemas do que simplesmente iniciar daemons e eu continuo usando sistemas baseados nele todos os dias.

Mas é difícil não achar divertido quando você aperta Enter no GRUB e praticamente imediatamente está olhando para sua sessão.

Seis segundos são seis segundos.

Void me lembrou que instalação manual não é magia

Talvez essa tenha sido a melhor parte do experimento.

Eu comecei sem conhecer profundamente o processo de instalação específico do Void.

Sabia os conceitos.

Particionar.

Formatar.

Montar.

Bootstrap do userspace.

Gerar fstab.

Entrar em chroot.

Configurar locale.

Criar usuários.

Instalar bootloader.

Gerar initramfs.

Habilitar serviços.

Instalar servidor gráfico.

Iniciar window manager.

O resto foi mapear esses conceitos para as ferramentas da distribuição.

No Arch eu costumo pensar em pacman, systemd e mkinitcpio.

No Void, rapidamente passei a pensar em xbps, runit e dracut.

As convenções mudam.

Os fundamentos não.

Foi provavelmente por isso que a instalação andou tão rápido mesmo sendo um tiro no escuro.

Depois de certo ponto, aprender outra distribuição Linux deixa de ser aprender como instalar uma distro e vira descobrir como aquela distro decidiu representar problemas que você já conhece.

O melhor exemplo foi runit.

Eu esperava que fosse a parte estranha.

Em poucos minutos era uma das partes mais óbvias do sistema.

Não, não vou abandonar o Arch

Esse experimento não terminou com uma revelação religiosa.

Não vou migrar meu computador principal imediatamente.

Arch continua resolvendo muito bem o que eu quero de uma distribuição diária e o ecossistema de pacotes pesa bastante nessa decisão.

Pacman + AUR é uma combinação difícil de abandonar quando você usa muito software diferente, principalmente coisas pequenas, projetos novos e ferramentas que talvez nunca apareçam em um repositório oficial menor.

Mas isso não diminui o Void.

Na verdade, talvez seja justamente o contrário.

Eu entrei esperando uma distribuição bastante niche, um init estranho, menos pacotes e uma instalação que provavelmente exigiria mais manutenção manual do que eu gostaria.

Saí com um sistema simples, rápido e surpreendentemente transparente.

O erro mais irritante da instalação foi culpa minha.

O runit foi fácil.

O i3 subiu sem drama.

O zsh ficou pronto rapidamente.

XBPS é agradável de usar.

E, usando GRUB sem nenhuma obsessão particular por otimização, terminei com o boot mais rápido que já tive.

Não encontrei uma substituição para Arch.

Encontrei outro Linux que gostei de usar.

E talvez uma desculpa para criar um repositório XBPS.

O que, considerando que tudo começou porque eu resolvi baixar uma ISO por curiosidade, já é um resultado bastante razoável.