Início / computer / Perguntas / 1713269
Accepted
cryptic
Asked: 2022-03-29 07:05:35 +0800 CST

Por que a importação da imagem de bootstrap do Arch para o WSL2 causa erros de montagem, mas a importação da imagem do Docker do Arch não?

  • 772

Recentemente, instalei o Arch no WSL2 e queria saber por que a importação oficial da imagem de bootstrap falha, mas a importação de uma imagem extraída do Docker do Arch funciona bem.

Caso 1

  • Baixei a última imagem de bootstrap de um dos espelhos listados em archlinux.org .
  • Recompactado para se livrar do root.x86_64sub-diretório com: 
    fakeroot -- bash -c "tar -xf bootstrap.tar.gz && tar -czaf rootfs.tar.gz root.x86_64/*"
  • Movido .tarpara o sistema de arquivos do Windows
  • Importou o .tare correu wsl -d Arch. Isso gerou o seguinte erro, tornando a distribuição inútil. 
    Error mounting one of the file systems. Run 'dmesg' for more details.
  • Eu tentei executar dmesgcom wsl -d Arch --exec dmesg, mas foi retornado o mesmo erro anterior, então não consegui identificar o problema.

Caso 2

  • Criou um contêiner do Docker com a imagem do Arch mais recente. 
    docker run -t --name arch archlinux ls /
  • Exportou para um arquivo tar. 
    docker export arch -o arch-wsl.tar
  • Importado. Correu wsl -d Arch. E isso imediatamente me deixou em bash.

Alguma idéia de por que esses dois casos produzem resultados diferentes?

linux arch-linux

2 respostas

  1. Resposta curta:

    Sua primeira tentativa usando a imagem de bootstrap e fakerootestá produzindo um rootfs inválido. Na verdade, não está removendo o root.x86_64diretório pai.

    Mais detalhes:

    O Error mounting one of the file systems. Run 'dmesg' for more details., na minha experiência, geralmente significa que o arquivo não contém um rootfs válido (para WSL).

    No começo eu pensei que isso era devido à importação de um arquivo gzipado, já que o padrão para --exporté um tar simples (e você faz isso nas etapas do Docker).

    No entanto, acabei de testar com a tare a .tar.gze funcionou para mim de qualquer maneira. No entanto, usei etapas um pouco diferentes - Especificamente, usei sudoem vez de usá fakeroot-lo em uma distribuição existente do Ubuntu 20.04. Edit : Eu também tentei com fakeroota minha distribuição Artix e encontrei o problema. Veja a seção abaixo "Por que sua tentativa de fakeroot não funcionou" .

    Eu tive sucesso com o seguinte. Primeiro, do Ubuntu 20.04:

    wget http://mirror.rackspace.com/archlinux/iso/2022.03.01/archlinux-bootstrap-2022.03.01-x86_64.tar.gz
sudo tar --xattrs -xzvf archlinux-bootstrap-2022.03.01-x86_64.tar.gz
cd root.x86_64/
sudo tar --xattrs -cf ../archtest.tar .
# or
# sudo tar --xattrs -czf ../arch-wsl.tar.gz .
mv ../arch-wsl.tar* /mnt/c/Users/<some_location_in_my_profile>
# I have a standard WSL directory under my Documents folder

    Em seguida, do PowerShell (você já está familiarizado com essas etapas, obviamente):

    cd <location_from_above>
mkdir -p instances\arch
wsl --import arch .\instances\arch .\arch-wsl.tar --version 2
wsl ~ -d arch

    Por que sua tentativa de fakeroot não funcionou

    Executei sua linha de comando para testá-lo no Artix e posso ver o problema. O tar que é criado a partir dele ainda tem o arquivo root.x86_64nele. Para se livrar dele, você precisa usar a -C/--directoryopção para especificar a raiz real:

    fakeroot -- bash -c "tar -xf bootstrap.tar.gz && tar -C root.x86_64 -czaf rootfs.tar.gz ."

    No entanto, ainda há um problema com isso, pois o arquivo de resultados não possui o recurso de segurança adequado em alguns comandos:

    tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.security.capability'
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.security.capability'

    Tentar usar --xattrscomo fiz com um simples sudoacima, ainda não funciona, e não tenho certeza do porquê neste momento:

    fakeroot -- bash -c "tar --xattrs -xf bootstrap.tar.gz  && tar --xattrs -C root.x86_64 -czaf rootfs.tar.gz ."

    Resulta em:

    tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.security.capability'
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.security.capability'
tar: ./usr/bin/newuidmap: Unknown file type; file ignored
tar: ./usr/bin/newgidmap: Unknown file type; file ignored
tar: Exiting with failure status due to previous errors

    Se você puder descobrir por que isso está falhando em fakeroot, me avise. Mas a sudoversão funciona muito bem para mim.

    Algumas notas laterais:

    • Depois de criar seu usuário padrão, você desejará defini-lo como o usuário padrão do WSL usando estas etapas .

    • Arch ainda é uma distribuição do Systemd e (como você já deve saber), o Systemd não é bem suportado no WSL devido (a) ao /initsistema do WSL que configura a integração WSL/Windows e (b) à exigência do Systemd de que seja PID1.

      Eu rapidamente migrei do Arch para o Artix, já que o último é uma distribuição baseada no Arch sem Systemd. Ainda estou "cedo" (estou nisso há cerca de um mês), mas os resultados são animadores. O Artix suporta 5 diferentes supervisores de processo alternativos e possui scripts/arquivos de unidade para a maioria dos serviços instalados pacman(mas não, no entanto, AUR). Se você quiser seguir esse caminho, me avise e eu posso compartilhar minhas instruções de configuração.

    • 1
  2. Best Answer

    Obrigado a @NotTheDr01ds por reservar um tempo e apontar os problemas com minha tentativa anterior e o arquivo tar.

    Descobri que usar bsdtarincluído com libarchivefunciona perfeitamente, em vez de GNU tarcom fakeroot:

    fakeroot -- bash -c "bsdtar -xf bootstrap.tar.gz  && bsdtar -C root.x86_64 -czaf rootfs.tar.gz ."

    Isso resulta em uma importação perfeita. Você pode continuar inicializando o pacmanchaveiro e outras coisas.

    Quanto ao por que GNU tarproduz avisos, não tenho certeza. De acordo com isso , trata-se apenas de um conflito de compatibilidade entre as duas ferramentas. Encontrei um tópico de comparação aqui .

    • 0

relate perguntas