Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package for Windows Store #63

Open
sielicki opened this issue Mar 24, 2022 · 27 comments
Open

Package for Windows Store #63

sielicki opened this issue Mar 24, 2022 · 27 comments
Labels
enhancement New feature or request

Comments

@sielicki
Copy link

It would be nice to just have this available on the Windows Store. It's more or less just a matter of making a manifest and emailing the right people.

See: github.com/microsoft/WSL-DistroLauncher

@sielicki
Copy link
Author

I started looking through this tonight. I'd be interested to hear ideas around how we could take advantage of having an executable in the default Windows %PATH% to do more interesting nix-on-wsl things, especially with regards to switching and rolling back generations.

There's a nice little API within there where you can run arbitrary commands within WSL through WslLaunchInteractive to call whatever you want.

@nzbr nzbr mentioned this issue May 22, 2022
10 tasks
@nzbr nzbr pinned this issue Jun 3, 2022
@nzbr
Copy link
Member

nzbr commented Jun 3, 2022

I have implemented a custom distro launcher (#94). A test-signed build can be found here. To install it, run the included install.ps1 script in PowerShell. It may be necessary to enable Developer Mode in the Windows settings

If you discover any issues, please leave a comment on the Pull Request

@Diti
Copy link

Diti commented Jan 17, 2023

@nzbr The link to your test-signed build does not work.

@nzbr
Copy link
Member

nzbr commented Jan 18, 2023

The build artifact I linked has probably expired since then. You should alwasys be able to grab the appx artifact from the latest CI run here: https://github.com/nzbr/NixOS-WSL/actions?query=branch%3Adistro-launcher

@nixos-discourse
Copy link

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-installer-workgroup/21495/17

@nzbr nzbr unpinned this issue Mar 31, 2023
@luochen1990
Copy link

Has there been any progress?

@SuperSandro2000
Copy link
Member

Not to much on #94

@FilipeBento
Copy link

Hi, is there any progress towards having a NixOS in the Microsoft Store to use in WSL2?

@aikooo7
Copy link

aikooo7 commented Feb 11, 2024

Hi, is there any progress towards having a NixOS in the Microsoft Store to use in WSL2?

The distrolauncher is already done, but I'm not sure how we can put it in the store and since @nzbr is the maintainer, maybe should be he doing it?

@nzbr
Copy link
Member

nzbr commented Feb 12, 2024

The latest CI runs already build the store package. It'd be great if some of you would test the thing to see if it works on other computers than mine. Just grab the launcher-msix artifact from here, unpack it and run the Install.ps1 inside. ([right-click] -> [run with powershell] should do the trick)

@aisk
Copy link

aisk commented Feb 12, 2024

Hi @nzbr, thanks for your work! After running the Install.ps1 succeeded, the NixOS item showed in the start menu, but it quite imediately after click. Run nixos in command line shows:

C:\Users\xxxxx>nixos
Registering NixOS...
There was an error registering the distribution

Running it with administrator got the same error.

I'm using Win10 22H2 with Windows Feature Experience Pack 1000.19052.1000.0.

@nzbr
Copy link
Member

nzbr commented Feb 12, 2024

Can you try again with nixos --distro-name <some other name>?

@aisk
Copy link

aisk commented Feb 14, 2024

@nzbr I've got the same error:

C:\Users\xxxxx>nixos --distro-name asdf
Registering NixOS...
There was an error registering the distribution

@aisk
Copy link

aisk commented Feb 14, 2024

@nzbr Sorry my bad. I resolved the problem, just running wsl --install -d debian, then the NixOS can be started with the start menu or command line.

I guess my current machine don't activate WSL2 before, so there are some components are missing.

[nixos@nixos:~]$ uname -a
Linux nixos 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 GNU/Linux

[nixos@nixos:~]$ ps -a
    PID TTY          TIME CMD
      2 hvc0     00:00:00 init-systemd(Ni
      3 hvc0     00:00:00 init
    272 pts/1    00:00:00 bash
    295 pts/0    00:00:00 ps

@nzbr
Copy link
Member

nzbr commented Feb 14, 2024

There should probably be a check if WSL is actually installed. Gonna make an issue for it

Edit: #421

@JojOatXGME
Copy link
Contributor

I also tried it. Is there a reason that the shell initially starts up with the working directory of /mnt/c/WINDOWS/system32? Other distributions start up in the home directory in my experience.

@nzbr
Copy link
Member

nzbr commented Feb 18, 2024

@JojOatXGME the shell working directory is the same the launcher gets started with. The others probbably have some sort of check so that it gets set to the home directory in that case
#423

@onny
Copy link

onny commented Feb 24, 2024

Upstream issue microsoft/WSL#11206

@JamieMagee
Copy link
Member

@onny I think someone from the NixOS side needs to publish the launcher to the Microsoft Store. See the instructions here

@sirredbeard
Copy link

Hi there! I'm the creator of Pengwin, Fedora Remix for WSL, and Pengwin Enterprise, all Linux distros published in the Store, I also managed Ubuntu's publication in the Store during my time at Canonical. I would be happy to help get NixOS published in the Store. I am not familiar with building NixOS images, but if I can partner with someone who is, I can then advise on how to automate the build pipeline and publish them regularly to the Store.

@TLMcNulty
Copy link

TLMcNulty commented Jul 3, 2024

I think there's a little more work to be done before it can be listed. I'm trying to set up a Nix instance on W10 22H. I've started with the wsl --import nixos.tar.gz etc and have an instance correctly registered, but some general NixOS use things are sticking at the moment.

From what I can tell there's no hardware-configuration.nix included initially. The docs mention needing to add channels, as my nix-channel --list was initially empty. I added nixos-24.05 as nixos and that resolved some errors. I'm not familiar with the inner workings of why this might be unset in the current tarball, perhaps to avoid pinning an old version? If so, build should try to check the current appropriate channels (https://status.nixos.org/) so that's set for the user once the shell is opened.

The other item has been previously mentioned. (#63 (comment)) The working directory set when the image starts is -I'm assuming, haven't thoroughly tested- a passthrough to the Windows host system disks? Which is sorta cool and nice and useful in one way, but if we want to do what user in the comment mentioned and set a home directory, we will need some fileSystems definition as when I try to load a configuration.nix that will start to include system packages, rebuild fails needing it.

[nixos@nixos:/etc/nixos]$ sudo nixos-rebuild switch
building Nix...
building the system configuration...
error:
       … while calling the 'head' builtin

         at /nix/var/nix/profiles/per-user/root/channels/nixos/lib/attrsets.nix:922:11:

          921|         || pred here (elemAt values 1) (head values) then
          922|           head values
             |           ^
          923|         else

       … while evaluating the attribute 'value'

         at /nix/var/nix/profiles/per-user/root/channels/nixos/lib/modules.nix:807:9:

          806|     in warnDeprecation opt //
          807|       { value = builtins.addErrorContext "while evaluating the option `${showOption loc}':" value;
             |         ^
          808|         inherit (res.defsFinal') highestPrio;

       (stack trace truncated; use '--show-trace' to show the full trace)

       error:
       Failed assertions:
       - The ‘fileSystems’ option does not specify your root file system.
       - You must set the option ‘boot.loader.grub.devices’ or 'boot.loader.grub.mirroredBoots' to make the system bootable.

hardware-configuration.nix is usually left up to the user for their system right? Is there any sort of minimal virtual mount/directory creation step we can do as a part of set up that could give us a minimal fileSystems block? My goal is simply to get a package installed at the moment. I have relatively little experience with Nix, so any perspective would be great.

Finally, I enabled developer mode and loaded the testing cert to test a build artifact built last week, https://github.com/nix-community/NixOS-WSL/actions/runs/9638299838. Execution went smoothly and no errors hung around, but I did this after having installed a distro labeled NixOS via the tar.gz import. Might this have collided? I didn't see any changes to the distro list after this and I don't think any apps in the Windows Store have changed.

@malik-n
Copy link

malik-n commented Jul 30, 2024

From what I can tell there's no hardware-configuration.nix included initially.

@TLMcNulty
My NixOS WSL Configuration is working fine without a hardware-configuration.nix
Configuration of a bootloader like grub doesn't really make sense for a wsl instance I would say

@sirredbeard
Copy link

From what I can tell there's no hardware-configuration.nix included initially. The docs mention needing to add channels, as my nix-channel --list was initially empty. I added nixos-24.05 as nixos and that resolved some errors. I'm not familiar with the inner workings of why this might be unset in the current tarball, perhaps to avoid pinning an old version? If so, build should try to check the current appropriate channels (https://status.nixos.org/) so that's set for the user once the shell is opened.

Going on my limited understanding of hardware-configuration.nix, I think a minimal hardware-configuration.nix would suffice. There's no need to set boot settings, unless a user wants to modify them to load additional kernel modules, but that is rare. There should be no need to mount filesystems or define swap, that will be handled by WSL. Maybe consider: networking.useDHCP = lib.mkDefault true; and nixpkgs.hostPlatform = lib.mkDefault "x86_64-linux"; for x86_64 vs. arm64 images.

The other item has been previously mentioned. (#63 (comment)) The working directory set when the image starts is -I'm assuming, haven't thoroughly tested- a passthrough to the Windows host system disks? Which is sorta cool and nice and useful in one way, but if we want to do what user in the comment mentioned and set a home directory, we will need some fileSystems definition as when I try to load a configuration.nix that will start to include system packages, rebuild fails needing it.

I defer to your knowledge on needing a filesystem definition for a user home directory. Usually the WSL-Distrolauncher package for new user setup handles adding a default user and by extension creating a home directory. That home directory is then set as the default in WSL and stored in the Windows Registry. Local drives are automatically mounted at /mnt/c by WSL. I do not recommend setting this as the default for the home user. There is a small performance penalty when performing work across the /mnt/c bridge which can snowball when working with large projects with lots of dependencies. I suggest leaving the created user's home within the WSL environment the default and, optionally, creating a symlink to /mnt/c in that home folder for ease of access.

   - The ‘fileSystems’ option does not specify your root file system.
   - You must set the option ‘boot.loader.grub.devices’ or 'boot.loader.grub.mirroredBoots' to make the system bootable.

This is interesting. This could be configured in the distro by adding logic to the WSL-Distrolauncher C++ distro initiation code where the default new user is created. GRUB is not needed though, it can be installed (several WSL distros still ship with GRUB in them), but it will be bypassed by the WSL's own boot/init flow.

hardware-configuration.nix is usually left up to the user for their system right? Is there any sort of minimal virtual mount/directory creation step we can do as a part of set up that could give us a minimal fileSystems block? My goal is simply to get a package installed at the moment. I have relatively little experience with Nix, so any perspective would be great.

See above. I also would need to hear from someone with more Nix experience to property advise on this.

Finally, I enabled developer mode and loaded the testing cert to test a build artifact built last week, https://github.com/nix-community/NixOS-WSL/actions/runs/9638299838. Execution went smoothly and no errors hung around, but I did this after having installed a distro labeled NixOS via the tar.gz import. Might this have collided? I didn't see any changes to the distro list after this and I don't think any apps in the Windows Store have changed.

It's possible it overwrote the existing NixOS. In the future, I would recommend removing the .tar.gz import, restarting WSL, and then trying this from scratch.

Hope some of this helps.

@sylvorg
Copy link

sylvorg commented Jul 30, 2024

There should be no need to mount filesystems or define swap, that will be handled by WSL. ... Usually the WSL-Distrolauncher package for new user setup handles adding a default user and by extension creating a home directory.

Is there a way to define filesystem mounts and user creation only in the NixOS configuration, so that everything is in one place? Or do those events occur before the distribution is started?

@sirredbeard
Copy link

Is there a way to define filesystem mounts and use creation only in the NixOS configuration, so that everything is in one place? Or do those events occur before the distribution is started?

WSL automatically mounts the root file system and /mnt/c (the latter by default unless disabled) when the distribution is launched.

This would all occur before hardware-configuration.nix is parsed.

The options here are limited and geared towards more traditional Linux distros. It's possible to disable automount of /mnt/c or enable the mounting of /etc/fstab but I don't think either one of those would be of assistance.

@nzbr
Copy link
Member

nzbr commented Oct 13, 2024

The .nix files are parsed when running nixos-rebuild and are not touched at all during boot. It is completely possible to have nixos systems that do not contain their own config (for example servers which can have their config applied remotely from another system). On WSL we don't install any bootloader; The NixOS-WSL module sets a dummy bootloader, so the fact that it complains for @TLMcNulty about a missing bootloader leads me to believe that the module is not loaded properly. A hardware-configuration.nix is not needed either. Even on bare-metal NixOS the file is just imported by the system's configuration.nix, which is the actual entry-point for evaluating the system configuration (that one is present on NixOS-WSL). hardware-configuration.nix is a separate module because it gets auto-generated by nixos-generate-config during the installation of a bare-metal NixOS system. Normally the user isn't supposed to touch it, because it would be overwritten were they to invoke nixos-generate-config again at a later point.

@nzbr
Copy link
Member

nzbr commented Oct 13, 2024

The Launcher uses NixOS as the distro name by default. So if a distro with that name is already present when the launcher is installed, it will just use that and not register it. (I think the C++ implementation had the same behavior, but I'm not sure)

There is no first-time setup wizard like on the other distros, because it would require editing the configuration.nix. The process for changing the user name is documented now though: https://nix-community.github.io/NixOS-WSL/how-to/change-username.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests