2

I recently installed Arch on WSL2 and was wondering why the official bootstrap image import fails but importing an extracted Arch's Docker image works fine.

Case 1

  • Downloaded the latest bootstrap image from one of the mirrors listed at archlinux.org.
  • Repacked it to get rid of the root.x86_64 sub-dir with: 
    fakeroot -- bash -c "tar -xf bootstrap.tar.gz && tar -czaf rootfs.tar.gz root.x86_64/*"
  • Moved the .tar to the Windows File System
  • Imported the .tar and ran wsl -d Arch. This yielded the following error, rendering the distro useless. 
    Error mounting one of the file systems. Run 'dmesg' for more details.
  • I tried running dmesg with wsl -d Arch --exec dmesg but was returned the same previous error so couldn't pinpoint the issue.

Case 2

  • Created a Docker container with the latest Arch image. 
    docker run -t --name arch archlinux ls /
  • Exported it to a tar file. 
    docker export arch -o arch-wsl.tar
  • Imported it. Ran wsl -d Arch. And it immediately dropped me into bash.

Any idea why do these two cases yield different results?

cryptic
  • 106

2 Answers2

2

Short answer:

Your first attempt using the bootstrap image and fakeroot is producing an invalid rootfs. It's not actually removing the root.x86_64 parent directory.

More detail:

The Error mounting one of the file systems. Run 'dmesg' for more details., in my experience, usually means that the archive doesn't contain a valid (to WSL) rootfs.

At first I thought this was due to importing a gzipped file, since the default for --export is a simple tar (and you do that in your Docker steps).

However, I just tested with both a tar and a .tar.gz and it worked for me either way. I used slightly different steps, though -- Specifically, I used sudo rather than fakeroot since I'm trying it from an an existing Ubuntu 20.04 distribution. Edit: I also gave it a try with fakeroot under my Artix distribution and found the problem. See the section below "Why your fakeroot attempt didn't work".

I was successful with the following. First, from 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

Then from PowerShell (you are already familiar with these steps, obviously):

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

Why your fakeroot attempt didn't work

I ran your command-line to try it out under Artix, and I can see the problem. The tar that is created from it still has the root.x86_64 in it. To get rid of it, you need to use the -C/--directory option to specify the real root:

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

However, there's still a problem with that, since the result archive doesn't have the proper security capability on a few commands:

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

Attempting to use --xattrs as I did with a simple sudo above, still doesn't work, and I'm not sure just why at this point:

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

Results in:

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

If you can figure out why that's failing under fakeroot, let me know. But the sudo version works just fine for me.

A few side-notes:

  • After creating your default user, you'll want to set it as the WSL default user using these steps.

  • Arch is still a Systemd distribution, and (as you may already know), Systemd is not well supported under WSL due to (a) WSL's /init system which sets up the WSL/Windows integration, and (b) Systemd's requirement that it be PID1.

    I quickly migrated from Arch to Artix, as the latter is a Systemd-free Arch-based distro. I'm still "early" (been on it about a month), but the results are encouraging. Artix supports 5 different alternative process supervisors, and has scripts/unit files for most all services installed through pacman (but not, however, AUR). If you want to go this route, let me know, and I can share my setup instructions.

NotTheDr01ds
  • 28,025
0

Thanks to @NotTheDr01ds for taking out time and pointing out the issues with my previous attempt and the resultant tar.

I found that using bsdtar included with libarchive works perfectly, instead of GNU tar with fakeroot:

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

This results in a perfect import. You can then continue initializing pacman keyring and stuff.

As for why GNU tar produces warnings, I am not sure. According to this, it is just a compatibility conflict between the two tools. I found a comparison thread here.

cryptic
  • 106