Fiz o WSL 2 subir o meu Linux do dual boot direto da partição física

Uso um notebook de trabalho com dois SSDs de 256 GB: Windows 11 num, Kubuntu no outro, em dual boot. Eu queria uma única instalação Linux — mesma home, mesmos pacotes, mesmo Docker — tanto no boot nativo quanto aberta de dentro do Windows pelo WSL. Manter um segundo Linux inteiro dentro de um ext4.vhdx duplicava tudo e ainda comia um espaço que não sobra.

O problema

O WSL 2 oficial só sobe uma distro a partir de um arquivo ext4.vhdx. O wsl --mount anexa um disco físico, mas só como montagem extra, nunca como raiz de uma distro registrada. A issue pedindo isso (microsoft/WSL#6290) está aberta desde 2020.

Os contornos conhecidos fazem chroot ou systemd-nspawn na partição a partir de outra distro. Funciona, mas o wsl.exe, o \\wsl.localhost, o Remote WSL do VS Code e a integração do Docker continuam enxergando a outra distro: você vive dentro de um wrapper.

Onde o WSL escolhe a raiz

Lendo o código (o WSL virou open source), a raiz da distro não é decidida pelo kernel, e sim em dois lugares:

1. no serviço do Windows (WslCoreVm::CreateInstance), que anexa o VHD da distro à VM;
2. no mini_init, o primeiro processo da VM, que monta esse disco em /distro antes de entregar para o init normal do WSL.

Então a mudança é pequena: seis patches (~500 linhas) sobre a tag 3.0.3.

• O serviço resolve o disco autorizado por modelo + serial (exatamente um disco, nunca o disco do Windows, GPT obrigatório) e anexa por PassThrough, o mesmo caminho do wsl --mount.
• O mini_init recebe o PARTUUID e o UUID do ext4, acha a partição dentro do disco, confere o superbloco, as features do ext4 e a versão do kernel, e só então monta a partição como raiz.
• Daí pra frente é o WSL original: systemd, interop, WSLg, tudo igual.

O que deu mais trabalho: segurança

É um disco real montado em leitura e escrita por outro kernel. Algumas travas:

• a autorização fica no HKLM (só administrador grava) e é ligada ao SID do usuário; o serviço confere a identidade do disco a cada boot;
• as features do ext4 gravadas na autorização são conferidas contra o código-fonte do kernel do WSL; kernel novo ou filesystem alterado bloqueiam o boot até um novo registro;
• --export, --manage --resize/--move/--set-sparse, --set-version e --unregister são recusados: não existe imagem, só o seu disco;
• wsl --update é bloqueado, para uma atualização oficial não substituir o serviço com patch.

Fazendo o systemd de um desktop rodar no WSL sem quebrar o boot nativo

Esse foi o aprendizado mais interessante do lado Linux. Com um único /etc:

• um systemd generator que só age quando systemd-detect-virt --container responde wsl, e só escreve em /run: mascara display manager, NetworkManager, a ESP e todas as outras montagens do fstab menos /, serviços de firmware e de atualização;
• o /etc/wsl.conf (lido só pelo WSL) preserva o hostname nativo, o /etc/hosts e o symlink do systemd-resolved;
• um hook do APT recusa pacotes de GRUB/shim/kernel/initramfs dentro do WSL, porque ali a ESP não está montada.

Resultado: systemctl is-system-running = running sem units falhando no WSL, e no boot nativo o desktop sobe normal, com os boots do WSL aparecendo no journalctl --list-boots.

O que funciona

Sem elevação: wsl -d, \\wsl.localhost a frio, systemd, VS Code Remote WSL, Docker com portas no localhost do Windows, WSLg (apps KDE como janelas do Windows, com áudio) e desligamento limpo quando o Windows reinicia com a distro aberta.

Limites

Protótipo testado em uma máquina (Kubuntu 26.04, ext4, GPT, segundo NVMe). Layout suportado: raiz ext4 simples, sem LUKS/LVM/RAID. O build não é assinado e não publico binários de propósito: quem vai bootar o próprio disco deve compilar o que roda. Nunca hiberne o Linux nativo enquanto usa a partição pelo WSL.

Código, patches, instruções de build e matriz de testes: https://github.com/sottam/dualboot-linux-as-wsl

Também propus a ideia ao time do WSL na issue original. Feedback é muito bem-vindo, principalmente de quem usa outras distros e layouts.