[nixos] WslRegisterDistributionFailed: 0x800707b - ProcMon - CreateFile NAME INVALID

[ghuntley]

• Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.16299.431]

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

Howdy folks I'm working on bringing https://nixos.org v18.03 up on WSL (NixOS/nixpkgs#30391). You can reproduce this issue by cloning down http://github.com/ghuntley/nixos-wsl and uncompressing install.tar.7z.[0..] into the x64 directory.

• What's wrong / what should be happening instead:

See twitter thread at https://twitter.com/tara_msft/status/996870558741508096 and below

If I understand this correctly the installation is failing because this image contains filenames or directories that cannot be expanded onto NTFS which is causing WslRegisterDistributionFailed to go boom. I'm not sure if you have used NixOS before but it's a functional linux distribution which centers around the concept of /nix aka the nixstore.

When /etc/nixos/configuration.nix is updated/applied by root or nix-shell is invoked the output state (ie operating system or resulting application) is placed into the nixstore. This allows scenarios such as side-by-side installation of multiple versions of python with different FFI dependancies and instant rollback to previous known operating state (think of it like "boot to last known good configuration" in windows). NixOS has a garbage collector which cleans up state within the nixstore as need be.

Thus the filenames or directories you see here are valid and a requirement for nixos.

[ghuntley]

https://twitter.com/grhmc/status/996876883307499520

Hmm I don’t know of any reason the nix store paths would be illegal, but the packages definitely could create paths inside of the store path directory which is illegal. What sort of restrictions would need to apply?

— Graham Christensen (@grhmc) May 16, 2018

[benhillis]

@DarthSpock - This repo is fine.

@ghuntley - Can you share the instructions you are using to create your install.tar.gz file so I can step through this under a debugger?

[bencoman]

I presume the expansion is happening on the Windows side, in which case the question mark in the filename being an invalid NTFS path character is the problem (quick summary here). I guess it will be difficult to get NTFS behaviour changed.

Curious about how WSL translates these characters to be stored on the underlying NTFS,
on the Linux side I ran this script...

#!/bin/bash
mkdir -p wslPathCharsTest
cd wslPathCharsTest
rm -f *-From*
echo FromLinux > LessThan-FromLinux-\<
echo FromLinux > GreaterThan-FromLinux-\>
echo FromLinux > Colon-FromLinux-\:
echo FromLinux > DoubleQuote-FromLinux-\"
echo FromLinux > BackSlash-FromLinux-\\
echo FromLinux > Pipe-FromLinux-\|
echo FromLinux > QuestionMark-FromLinux-\?
echo FromLinux > Asterisk-FromLinux-\*
ls -1

resulting in...

Asterisk-FromLinux-*
BackSlash-FromLinux-\
Colon-FromLinux-:
DoubleQuote-FromLinux-"
GreaterThan-FromLinux->
LessThan-FromLinux-<
Pipe-FromLinux-|
QuestionMark-FromLinux-?

Then on the Windows side...

cd C:\Users\Ben\AppData\Local\lxss\home\ben\wslPathCharsTest>
dir /b 

resulting in...

Asterisk-FromLinux-#002A
BackSlash-FromLinux-#005C
Colon-FromLinux-#003A
DoubleQuote-FromLinux-#0022
GreaterThan-FromLinux-#003E
LessThan-FromLinux-#003C
Pipe-FromLinux-#007C
QuestionMark-FromLinux-#003F

So perhaps it would work if you repackage the "install.tar...s" with question marks mapped to #003F,
and when the Linux side boots it sees a proper question-mark character.

Proof of concept...

On Windows side...

echo FromWindows > QuestionMark-FromWindows-#003F

Then on Linux side...
(actually the file didn't show in the directory until I closed all bash windows and opened a new one, but after that...)

chmod +r QuestionMark-FromWindows-\?
cat QuestionMark-FromWindows-\?

results in

FromWindows

[Biswa96]

@ghuntley I installed NixOS with some tweaking: Download install.tar.7z.001 > extract install.tar.gz with 7zip > install with WslRegisterDistribution function > Paste this: root:x:0:0:System administrator:/root:/bin/sh in the first line in /etc/passwd file.

Some queries & suggestions:

1. Why did you put so many 7zip file in git repository? It takes time to clone.
2. You may use CI to build tar.gz.
3. There are some errors to use normal commands. e.g. to run ping I've to type /nix/store/3l8a93aapkk4lx44l73cm58wklwyy2nx-extra-utils/bin/ping instead of normal ping. May be some packaging error.
4. You may share the packaging procedure.

[ghuntley]

Replies for @Biswa96:

Why did you put so many 7zip file in git repository? It takes time to clone.

GitHub has a restriction on how many big a particular binary can be so I split them.

You may use CI to build tar.gz.

Of course - let's get a successful bring up first tho.

There are some errors to use normal commands. e.g. to run ping I've to type /nix/store/3l8a93aapkk4lx44l73cm58wklwyy2nx-extra-utils/bin/ping instead of normal ping. May be some packaging error.

Nope, that's standard with nixos. When packages are installed they are installed into the nixstore. Assuming standard locations is a recipe for failure. Always defer to #!/bin/env bash instead of /usr/bin/bash. This is the magic of nixos and how state is managed/allows SxS installs.

You may share the packaging procedure.

Install nixos v18.03 (see next post) and then from /mnt

cd /mnt
tar -cvf install.tar.gz *

Then FTP it off the virtual machine ;-)

[ghuntley]

Replies for @benhillis:

Can you share the instructions you are using to create your install.tar.gz file so I can step through this under a debugger?

• Download https://d3g5gsiof5omrk.cloudfront.net/nixos/18.03/nixos-18.03.132336.ef74cafd3e5/nixos-graphical-18.03.132336.ef74cafd3e5-x86_64-linux.iso and whack it into a virtual machine

Partition however you like

$ fdisk /dev/sda

  new - primary - slot 1 at 500mb
  new - primary - slot 2 at remaining

Filesystems are somewhat important

$ mkfs.ext4 /dev/sda1
$ mkfs.ext4 /dev/sda2

I guess we should mount em eh?

$ mkdir /mnt
$ mount /dev/sda2 /mnt
$ mkdir /mnt/boot
$ mount /dev/sda1 /mnt/boot

Generate the declarative configuration - this the heart and soul of nixos

$ nixos-generate-config --root /mnt

Do the bare min config as follows or use my config at https://gist.github.com/ghuntley/10fef3ed7a8f9371a537fa72960ebae4

$ vi /mnt/nixos/configuration.nix
>   boot.loader.grub.device = "/dev/sda";
>   environment.systemPackages = with pkgs; [
>     wget vim
>   ];

Install nixos!

$ nixos-install

Create the install.tar.gz

$ cd /mnt
$ tar -zcvf install.tar.gz *

I'm happy to pair with you @benhillis - name the time and place. You'll also find the install instructions over at https://nixos.org/nixos/manual/#sec-installation.

ps. this may help 👇

A big implication of the way that Nix/NixOS stores packages is that there is no /bin, /sbin, /lib, /usr, and so on. Instead all packages are kept in /nix/store. (The only exception is a symlink /bin/sh to bash in the Nix store.) Not using ‘global’ directories such as /bin is what allows multiple versions of a package to coexist. Nix does have a /etc to keep system-wide configuration files, but most files in that directory are symlinks to generated files in /nix/store.

[wmertens]

Just chiming in to clarify that on NixOS, the PATH environment variable is everything. You run programs with the correct PATH set and they will find only the correct version of the program they want.

To prevent too long PATH, normally you use a profile directory that is simply all desired packages symlinked together. In fact, the entire OS is like that, and upgrading the OS is simply changing the symlink to the profile.

[dtzWill]

Fwiw at a glance it looks like the distrolauncher has some absolute paths that may need to be touched up (when trying to create the user?). Not sure if relevant.

You say same result, is there an error or....? (does something point to tools not being found? seems worth chasing! Also any logs/traces may be useful)

[ghuntley]

I didn't commit any changes to distro launcher as it's blowing up during extraction. Yes it will need to be customised to account for nixos conventions of not using standard paths.

[phryneas]

It is pretty common that a program in nix is installed multiple times, although I'm not too sure about bash.

It might be interesing to do a garbage collection and see if the second bash goes away.

You might be looking fot the nix pill on store paths

[bencoman]

Just naive idea floating through my head...
what about running Nix inside WSL in a chroot
https://github.com/lethalman/nix-user-chroot

Outside the chroot directory the binaries required by WSL could be provided in the location it expects.
The tar containing the NTFS-invalid characters might be included outside the chroot folder and the untar'ing invoked on the Linux side.

[ghuntley]

To be perfectly clear NixOS != Nix.

• Nix is a package manager that can be installed into operating systems such as MacOS or Ubuntu
• NixOS is a Linux operating system that is built end-to-end using the package manager.

Subtle but major difference.

This thread was raised to report NTFS errors upon expansion of a valid install.tar.gz

[ghuntley]

There was no distribution registered when this error occurred. It is directly related to expanding install.tar.gz. Shall we open up another issue related to nixos and move these discussions about nixos bring up there?

[ghuntley]

Let's keep this topic about ntfs file names and move to 👉 NixOS/nixpkgs#30391

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!