GNU bug report logs - #53912
[PATCH 0/5] WIP Add WSL support.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53912 in the body.
You can then email your comments to 53912 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alex Griffin <a <at> ajgrf.com>
To: "guix-patches <at> gnu.org" <guix-patches <at> gnu.org>
Subject: [PATCH 0/5] WIP Add WSL support.
Date: Thu, 10 Feb 2022 06:05:43 +0000

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>

Message #8 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Alex Griffin <a <at> ajgrf.com>
To: 53912 <at> debbugs.gnu.org
Subject: [PATCH 1/5] scripts: Fix typo.
Date: Thu, 10 Feb 2022 06:12:04 +0000

[Message part 1 (text/plain, inline)]

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

Thanks,
–
Alex Griffin

[0001-scripts-Fix-typo.patch (text/x-patch, attachment)]

Message #11 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Alex Griffin <a <at> ajgrf.com>
To: "53912 <at> debbugs.gnu.org" <53912 <at> debbugs.gnu.org>
Subject: [PATCH 2/5] system: image: Add tarball support.
Date: Thu, 10 Feb 2022 06:22:10 +0000

[Message part 1 (text/plain, inline)]

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

--
Alex Griffin

[0002-system-image-Add-tarball-support.patch (text/x-patch, attachment)]

Message #14 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Alex Griffin <a <at> ajgrf.com>
To: 53912 <at> debbugs.gnu.org
Subject: [PATCH 3/5] system: image: Add wsl-tarball support.
Date: Thu, 10 Feb 2022 06:27:47 +0000

[Message part 1 (text/plain, inline)]

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

[0003-system-image-Add-wsl-tarball-support.patch (text/x-patch, attachment)]

Message #17 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Alex Griffin <a <at> ajgrf.com>
To: 53912 <at> debbugs.gnu.org
Subject: [PATCH 4/5] system: Add wsl module.
Date: Thu, 10 Feb 2022 06:31:07 +0000

[Message part 1 (text/plain, inline)]

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

[0004-system-Add-wsl-module.patch (text/x-patch, attachment)]

Message #20 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Alex Griffin <a <at> ajgrf.com>
To: 53912 <at> debbugs.gnu.org
Subject: [PATCH 5/5] image: Add wsl image.
Date: Thu, 10 Feb 2022 06:35:42 +0000

[Message part 1 (text/plain, inline)]

This patch adds the wsl system image. Generate it with

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

Thanks,
–
Alex Griffin

[0005-image-Add-wsl-image.patch (text/x-patch, attachment)]

Message #23 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: Alex Griffin <a <at> ajgrf.com>, 53912 <at> debbugs.gnu.org
Subject: Re: [PATCH 3/5] system: image: Add wsl-tarball support.
Date: Tue, 15 Feb 2022 15:10:43 +0100

Hi,

Am Donnerstag, dem 10.02.2022 um 06:27 +0000 schrieb 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.
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?

Message #26 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Alex Griffin <a <at> ajgrf.com>, 53912 <at> debbugs.gnu.org
Subject: Re: [bug#53912] [PATCH 3/5] system: image: Add wsl-tarball support.
Date: Tue, 15 Feb 2022 17:28:41 +0100

[Message part 1 (text/plain, inline)]

Alex Griffin via Guix-patches via schreef op do 10-02-2022 om 06:27
[+0000]:
> 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.

Why would WSL expect these things to be located there?
Can this assumption be removed upstream?

Greetings,
Maxime

[signature.asc (application/pgp-signature, inline)]

Message #29 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Alex Griffin <a <at> ajgrf.com>, 53912 <at> debbugs.gnu.org
Subject: Re: [bug#53912] [PATCH 3/5] system: image: Add wsl-tarball support.
Date: Tue, 15 Feb 2022 17:31:46 +0100

[Message part 1 (text/plain, inline)]

Alex Griffin via Guix-patches via schreef op do 10-02-2022 om 06:27
[+0000]:
>                  (with-directory-excursion image-root
> +                  (when #$wsl?
> +                    ;; WSL requires /bin/sh.  Will be overwritten by
> system
> +                    ;; activation.
> +                    (symlink #$root-shell "./bin/sh")
> +
> +                    ;; WSL requires /bin/mount to access the host
> fs.
> +                    (symlink #+(file-append util-linux "/bin/mount")
> +                             "./bin/mount"))

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.

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Alex Griffin <a <at> ajgrf.com>
Cc: "53912 <at> debbugs.gnu.org" <53912 <at> debbugs.gnu.org>
Subject: Re: bug#53912: [PATCH 0/5] WIP Add WSL support.
Date: Mon, 11 Apr 2022 12:34:58 +0200

Hi,

Alex Griffin <a <at> ajgrf.com> skribis:

> From ef951ff51bf0e2b2b50c57fbf652b0677c1e6701 Mon Sep 17 00:00:00 2001
> From: Alex Griffin <a <at> ajgrf.com>
> Date: Sun, 6 Feb 2022 16:29:47 -0600
> Subject: [PATCH 2/5] system: image: Add tarball support.
>
> * gnu/system/image.scm (tarball-image, tarball-image-type): New variables.
> (system-tarball-image): New procedure.
> (image->root-file-system): Add tarball image support.
> (system-image): Ditto.

Interesting!

> +++ b/gnu/system/image.scm
> @@ -1,6 +1,7 @@
>  ;;; GNU Guix --- Functional package management for GNU
>  ;;; Copyright © 2020, 2021 Mathieu Othacehe <m.othacehe <at> gmail.com>
>  ;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen <janneke <at> gnu.org>
> +;;; Copyright © 2022 Alex Griffin <a <at> ajgrf.com>
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -24,6 +25,7 @@ (define-module (gnu system image)
>    #:use-module (guix modules)
>    #:use-module (guix monads)
>    #:use-module (guix records)
> +  #:use-module (guix scripts pack)

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’.

Message #35 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Alex Griffin <a <at> ajgrf.com>
Cc: 53912 <at> debbugs.gnu.org
Subject: Re: bug#53912: [PATCH 0/5] WIP Add WSL support.
Date: Mon, 11 Apr 2022 12:41:21 +0200

Hi Alex,

Somehow I hadn’t noticed this patch series before…

Alex Griffin <a <at> ajgrf.com> skribis:

> 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
> └────

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’.

Message #38 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Alex Griffin <a <at> ajgrf.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 53912 <at> debbugs.gnu.org
Subject: Re: bug#53912: [PATCH 0/5] WIP Add WSL support.
Date: Tue, 26 Apr 2022 09:15:27 +0200

Hello,

> 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?

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

Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christine Lemmer-Webber <cwebber <at> dustycloud.org>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: Ludovic Courtès <ludo <at> gnu.org>, Alex Griffin <a <at> ajgrf.com>,
 guix-patches <at> gnu.org, 53912 <at> debbugs.gnu.org
Subject: Re: [bug#53912] [PATCH 0/5] WIP Add WSL support.
Date: Fri, 03 Jun 2022 20:31:12 -0400

Mathieu Othacehe <othacehe <at> gnu.org> writes:

> Hello,
>
>> 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?
>
> 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

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

Message #47 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Jacob MacDonald <jaccarmac <at> gmail.com>
To: 53912 <at> debbugs.gnu.org
Subject: Re: WSL support.
Date: Thu, 11 Aug 2022 11:27:25 -0500

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.

Message #50 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Stefan <stefan-guix <at> vodafonemail.de>
To: 53912 <at> debbugs.gnu.org
Subject: [PATCH 0/5] WIP Add WSL support.
Date: Thu, 11 Aug 2022 23:32:27 +0200

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

Message #53 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Jacob MacDonald <jaccarmac <at> gmail.com>
To: 53912 <at> debbugs.gnu.org
Subject: [PATCH 0/5] WIP Add WSL support.
Date: Thu, 11 Aug 2022 17:31:14 -0500

Stefan wrote:

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

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.

> This all seems to be far from perfect to me.

It is less than ideal.

> All in all WSL assumes the Filesystem Hierarchie Standard and /etc/environment

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.

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

> 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.

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.

> 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.

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.

> 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?

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.

> [WSL] 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.

> 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.

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.

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

The advice I saw on Guix-in-WSL suggested disabling nscd and I found
that to be the case.

> 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.

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.

Message #56 received at 53912 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Alex Griffin <a <at> ajgrf.com>, 53912 <at> debbugs.gnu.org
Subject: Re: bug#53912: [PATCH 0/5] WIP Add WSL support.
Date: Sun, 11 Sep 2022 14:23:05 +0200

Hey,

> 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.

I added a "System Images" documentation chapter with:
https://issues.guix.gnu.org/57643.

I sent a preliminary patchset to add tarball support here:
https://issues.guix.gnu.org/57680.

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

Message #61 received at 53912-done <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 53912-done <at> debbugs.gnu.org, Alex Griffin <a <at> ajgrf.com>
Subject: Re: bug#53912: [PATCH 0/5] WIP Add WSL support.
Date: Sun, 25 Sep 2022 13:56:29 +0200

Hey,

> 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.

And pushed, with a documentation update. I'll come up with a blog post
in the next coming days.

Thanks,

Mathieu

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.