| Message ID | 875ypndznv.fsf@ajgrf.com |
|---|---|
| Headers | show |
| Series | WIP Add WSL support. | expand |
Hi Alex, Somehow I hadn’t noticed this patch series before… Alex Griffin <a@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’.
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
Mathieu Othacehe <othacehe@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
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: > 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.
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
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
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>