[PATCH 0/5] WIP Add WSL support.

These patches are a work-in-progress, adding support for running Guix

System under [WSL].

Windows Subsystem for Linux (WSL) lets developers run a GNU/Linux

environment – including most command-line tools, utilities, and

applications – directly on Windows, unmodified, without the overhead

of a traditional virtual machine or dual-boot setup.

Things mostly just work already. To try it out, first generate an

os tarball:

┌────

│ guix system image gnu/system/images/wsl.scm

└────

Then copy the result to your Windows system and run:

┌────

│ wsl --import guix ./guix/ image.tar.gz

└────

You can now run Guix System under WSL:

┌────

│ wsl -d guix

└────

The approach I took is copied from the [NixOS-WSL] project. Since WSL

doesn’t run the guest distro’s init system, as a work-around I set the

root user’s shell to a script that boots the system and then starts a

user login shell.

Thanks,

–

Alex Griffin

[WSL] https://docs.microsoft.com/en-us/windows/wsl/

[NixOS-WSL] https://github.com/nix-community/NixOS-WSL

This patch just fixes a simple typo needed for the next patch.

Thanks,

–

Alex Griffin

This patch adds support for generating a tarball from operating-system definitions.

--

Alex Griffin

This patch adds the wsl-tarball image type. The difference between

this and the plain tarball type is the creation of the symlinks at

/bin/sh and /bin/mount.

These are necessary for the first boot to work after importing. We

can’t rely on special-files-service-type for this because the system

is not activated yet, and the /bin/sh symlink initiates the first

system activation.

Thanks,

–

Alex Griffin

This patch adds a new module at gnu/system/wsl.scm. It contains a

minimal operating-system definition that works in WSL.

Thanks,

–

Alex Griffin

This patch adds the wsl system image. Generate it with

guix system image gnu/system/images/wsl.scm

Thanks,

–

Alex Griffin

Hi,

Am Donnerstag, dem 10.02.2022 um 06:27 +0000 schrieb Alex Griffin:

I don't think this ad-hoc hack "deserves" its own tarball type.

Imagine WSL 3 requires /bin/ed besides /bin/sh and /bin/mount, then

you'd need to add a wsl3-tarball-type, and so on and so forth.

I think the correct way of implementing this would be to make image

respect --symlink the way guix pack does. WDYT?

Alex Griffin via Guix-patches via schreef op do 10-02-2022 om 06:27

[+0000]:

Why would WSL expect these things to be located there?

Can this assumption be removed upstream?

Greetings,

Maxime

Alex Griffin via Guix-patches via schreef op do 10-02-2022 om 06:27

[+0000]:

I would change this to

(with-directory-excursion image-root

#$@(if wsl?

;; Comment ...

#~((symlink ...)

(symlink ...)

#~())

other things ...)

such that the tarball could be built without building util-linux.

Also, (symlink #+(file-append util-linux ...) "./bin/mount") seems

wrong here when cross-compiling, wouldn't a 'mount' compiled for --

target be required instead of a 'mount' compiled for --system when

cross-compiling? Do you mean #$(file-append ...) instead?

Greetings,

Maxime.

Hi,

Alex Griffin <a@ajgrf.com> skribis:

Interesting!

We cannot refer to (guix scripts …) modules from here (conceptually

(guix scripts …) modules are layered above the rest).

If needed, we can move the relevant bits to a new (guix pack) module and

use it here. (I didn’t spot which part of (guix scripts pack) is used.)

Ludo’.

Hi Alex,

Somehow I hadn’t noticed this patch series before…

Alex Griffin <a@ajgrf.com> skribis:

That seems pretty fun.

You say it’s work in progress; what exactly is missing at this point?

At first sight, it looks mostly ready to me. What’s missing is a

section like “Running Guix under WSL”, maybe next to “Running Guix in a

VM”. WDYT?

Better yet would be a “System Images” section under “System

Configuration”, with a subsection dedicated to WSL images.

Ludo’.

Hello,

I agree with Ludo it seems like ready to me. That's a very interesting

series and I would like to see it merged :).

In the meantime, I pushed the first commit that is fixing a typo.

Thanks,

Mathieu

Mathieu Othacehe <othacehe@gnu.org> writes:

Turns out I have an immediate need for this to collaborate with a

coworker at my organization also.

Is all that's left is adding docs? It might be worth merging what

exists then already at its current state?

Even though my coworker needs it, I actually don't have access to a

Windows machine or I'd offer to write it. :)

- Christine

I'm also excited about the patch; I use Guix on WSL at work, with an

image I used Guix's Docker to create.

I just updated my WSL kernel to 5.15 and started seeing setuid errors

for binaries installed in /run/setuid-programs (sudo, passwd, etc.).

I've filed an upstream bug and suspect it has something to do with the

way WSL's init mounts file systems. Has anyone else encountered this

yet?

If not, and if you use WSL from the Windows Store, you might want to

delay your update.

Cheers,

Jacob.

Hi!

The problems with sudo etc. in /run/setuid-programs/ stem from the nosuid and noexec flags, which WSL sets when mounting /run as tmpfs.

I use a guile script which remounts /run with these flags removed.

But there is another mount-problem. When WSL is using root as the default user, then the default mounts of local drives like /mnt/c/ use uid=0 and gid=0. This is problematic, when a script is changing the user with sudo. So my script is unmounting all local drives and mounting them again with /sbin/mount.drvfs of WSL with the uid and gid of that user and the metadata flag. By the way, I was not able to use the type drvfs with the mount command from Guix for this. But I didn’t try the type 9p for this yet, which it actually seems to be.

Changing the default user to prevent problems with local drives seems possible with an /etc/wsl.conf file. But then it will not be possible to use root’s shell entry for the script anymore.

Hm, I guess that even if the sudo problem is solved, then still a “sudo -i” won’t be possible with the patch. Is that right?

Another possible problem with the patch might be the current-directory. I guess that a “wsl -d guix -e ls” will not list the directory from which the wsl command got invoked, but the user’s home directory.

My setup is using a gnu.bat file, which invokes a guile script named gnu.scm in WSL, which – if needed – does the re-mounts and starts shepherd, and calls sudo to login the user and change the directory before executing further commands from the user. It is retaining some environment variables like TERM, and the content of WSLENV. So from the Windows side it is possible to call “gnu.bat ls -lA” etc. or just “gnu.bat” to get a shell.

I’m experimenting with another script, which like busybox evaluates its name, and put symlinks to it in /usr/local/bin/, which is in the default WSL search path. That script invokes the mentioned gnu.scm script. With this it is possible to call e.g. “wsl -d guix -e ls -l” for the Windows user in USERNAME.

With the WSL version I’m using on Windows 10 its /init requires a group cache for nscd, too.

With Windows 11 there is a boot option for the /etc/wsl.config, which might be the optimal place for a script to do re-mounts and start shepherd.

All in all WSL assumes the Filesystem Hierarchie Standard and /etc/environment and makes it hard to launch arbitrary commands as intended with just “wsl -e ls” in Guix. In such a case no shell is involved and no /etc/profile or ~/.profile is sourced, so ls won’t be found. This all seems to be far from perfect to me.

Bye

Stefan

Stefan wrote:

Do you know if there was a 5.10->5.15 change on that front? I only saw

the issue after upgrading WSL (and not Guix), even though I had to

work around several mount issues getting Guix set up in the first

place.

It is less than ideal.

I do have some workarounds for the issues you mention; No long

examples since that work machine is airgapped, but I'll outline my

setup and can follow up with code. The filesystem standard, Linux and

Guix internals are the areas I'm fuzzy on, relying mostly on

third-party advice and a little bit of common-sense tinkering. It's

possible that something other than the WSL upgrade broke /run, but my

image started with a broken Guix and has undergone several successful

revisions.

That is exactly right based on my experience. My init script doesn't

do any mounts (since the old WSL seemed to let me call sudo just

fine), but it does start as root and make sure the file system is sane

before kicking things off.

I never investigated the ownership of /mnt/c/, but it seemed to work

OK in userspace. I could create files or delete/trash them from a

user-level Emacs.

I haven't used this patch, so I'm not sure how it interacts. However,

/run/setuid-programs/sudo -i fails for me as expected while

/run/current-system/profile/bin/sudo -i works.

This may be another Win11 feature, but I figured out that --shell-type

is a way around that annoyance. wsl --shell-type login ls in a fresh

PowerShell shows me files in my Windows home. My shell configuration

is small enough that the startup overhead is minimal, and based on

running top that way, there's no shell process that sticks around.

The advice I saw on Guix-in-WSL suggested disabling nscd and I found

that to be the case.

My /etc/wsl.conf sets the default user and specifies a script to run

at boot. That script sets up /run/current-system, boots from it, and

does those few trivial fs sanity checks. From there, I can start new

shells for my user and everything seems to behave. System

reconfigurations were the biggest footgun prior to this latest

breakage, but this is my only GuixSD experience so that might be a

general problem.

Thanks!

Jacob.

Hey,

I added a "System Images" documentation chapter with:

I sent a preliminary patchset to add tarball support here:

I also took most of the comments of this thread into account an pushed a

revised version of this series to wip-image.

In the documentation patchset, there is an "Image Modules" section

describing how to create an image by running "guix system image

gnu/system/images/pine64.scm". Maybe I should also give a more specific

example of how to create a WSL image in that section?

Tested all of it by creating a WSL image with some web services (nginx,

tailon), they are started by Shepherd in the WSL and accessible from

Windows.

Thanks,

Mathieu

Hey,

And pushed, with a documentation update. I'll come up with a blog post

in the next coming days.

Thanks,

Mathieu