Compacting NixOS failed with unspecified error

[SuperSandro2000]

To get the script working with NixOS I needed to change the path to df to /run/current-system/sw/bin/df.

Then after multiple errors the script failed with a very generic error message and immediately deleted the temporary vhdx so I couldn't inspect that.

PS C:\Users\user> WslCompact -c NixOS
 WslCompact v8.5 2023.02.16
 (C) 2023 Oscar Lopez
 wslcompact -h for help. For more information visit: https://github.com/okibcn/wslcompact

 Distro's name:  NixOS
 Image file:     C:\Users\user\NixOS\ext4.vhdx
 Current size:   152144 MB
 Estimated size: 137549 +/- 3355 MB
 The estimated process time using an SSD is about 34 minutes.
 NOTE: You can safely cancel at any time by pressing Ctrl-C
 Import in progress, this may take a few minutes.
Unspecified error
Error code: Wsl/Service/E_FAIL
 WARNING: wslcompact found errors in the current image. It could be a storage problem,
          a corrupted ext4 filesystem, or any other issue. Image not processed.

[okibcn]

I can see two issues there. One is just part of the script for tracking errors, this one could be my fault, and the size estimation depends largely on the availability of df, usually in the path.

However, the second problem is more delicate. Usually that error appears when there is an error in the filesystem.

For yourNixOS image, There is a test you can do to see if the problem is in the image or a problem with WSL itself. It requires 7zip installed in your system. The test is just a dump in tar format of all the files in the image. Type in powershell:

wsl --shutdown ; cmd /c "wsl  --export NixOS - | 7z a -si  ""Z:\External\path\dump.tar.7z"" "

7z is used to provide a nicer progress indicator, and as a way to reduce the required space for the test, even more when the data in your image is above 130GB.

Depending on the outcome:

• If it fails, then the problem is corruption in the ext4 filesystem. In this case, I would advise you to repair your filesystem.
• If the export works fine, then we will know that the problem is in WSL when importing that large image, and the problem would be related to a limitation of WSL when importing images.

Looking forward to hearing about your results.

[okibcn]

@SuperSandro2000 I have been trying to get the WSL2 image of NixOS, but in the official NixOS website, there is no WSL2 image.

The NixOS container can't be directly ported to WSL2 via Docker export -> wsl import.

The only reference to WSL2 on the NixOS website is related to how to install NixOS on top of any other distro as an environment on top of the underlying Linux OS.

wslcompact expects a minimal set of tools available for the default shell. Probably the default shell is not properly installed in the WSL2 image you have installed. 'nix-shell' should be the default shell if you want to use the df package using the NixOS environment.

NixOS also uses hard links instead of softlinks. This is a huge problem for WSL as it relies on a structure without dangerous hard links. This is one of the main reasons why there isn't any official NixOS image for WSL.

I would advise you to use another image and use NixOS in single user mode to avoid incompatibilities with WSL, and hence with wslcompact.

[okibcn]

Fixed in Release 8.7

Please follow the update instructions depending on the installation method you used. I can help you with your image, but since it is not a problem in wslcompact but a problem with how the image was built, from a community-generated image using dangerous hard links, I close will this issue.

I can continue helping you with that image, as you can save a lot of space. However, NixOS is an ever-growing OS as it never replaces packages, keeping any previous version. So, if you use NixOS, you must be prepared with several terabytes of storage.

[SuperSandro2000]

I have been trying to get the WSL2 image of NixOS, but in the official NixOS website, there is no WSL2 image.

You want to use https://github.com/nix-community/NixOS-WSL

wslcompact expects a minimal set of tools available for the default shell. Probably the default shell is not properly installed in the WSL2 image you have installed. 'nix-shell' should be the default shell if you want to use the df package using the NixOS environment.

The default shell for WSL is a bit tricky and only gets fully loaded in a login shell with all variables like PATH. This is also a bit tricky because WSL expects some binaries to be at specific PATHs.

NixOS also uses hard links instead of softlinks. This is a huge problem for WSL as it relies on a structure without dangerous hard links. This is one of the main reasons why there isn't any official NixOS image for WSL.

I think the main problem is, that Microsoft doesn't care enough to implement support for that. Hardlinks themselves are not dangerous and a standard feature in any reasonable new enough filesystem. Even Debians and Ubuntus fall flat here if some tools somewhere on the disk somehow used a hard link. It's just stupid.

Also NixOS by default only uses hardlinks when optimizing the store which is rather nice to have because it usually saves gigabytes on disk size.

There are works to get NixOS into the Microsoft store but they are not super high priority especially if every other bigger WSL update breaks the initialization.

I would advise you to use another image and use NixOS in single user mode to avoid incompatibilities with WSL, and hence with wslcompact.

Na, then I'd rather live with a big disk or setup my installation again (which is a lot easier than with any other Distro) and restore the few stateful directories manually.

a problem with how the image was built, from a community-generated image using dangerous hard links, I close will this issue.

It shouldn't matter that the NixOS image is done by the community. TBH it could be the official one and it is pretty solid. The Official Images by eg Ubuntu are not much better anyway eg. snapd completely breaks do-release-upgrade.

Hardlinks are not dangerous, Microsoft just needs to allocate some developer to fix this rather embarrassing bug. If the wsl.exe source code would be public than someone would probably already have fixed it.

However, NixOS is an ever-growing OS as it never replaces packages, keeping any previous version. So, if you use NixOS, you must be prepared with several terabytes of storage.

That's wrong. You can delete any old, not bootet system generation and then reclaim all store entries which are no longer referenced.

---

TLDR: If WSL is to stupid to allow this use case and there is nothing you can do to fix that, then that's fine for me. We can't nicely fix closed source programs. :)

[okibcn]

@SuperSandro2000 it is not MS's fault or even WSL's. It uses tar as a way to extract an image of the filesystem. In this sense is the pure Linux way of doing a backup. Actually, docker uses the same way to extract and import images. hard links are very dangerous because they can create loops, there is no easy way to port a filesystem without a deep analysis of the linked files, they can't link to files in other mounts, and the use case is limited to saving space in incremental backup systems.
NixOS uses that old way of doing incremental backup systems to integrate git-like incremental/differential changes into the OS and the packages. But it clashes with typical methods used today to keep an organized tree structure.

NixOS approach is really nice, but I feel that there must be a better way to integrate differential/incremental changes in a way more like git.

Since NixOS is so exotic in its approach and so incompatible with modern tools, It will remain a niche system. I like its approach, but it is useful only when doing experiments that require backtracking to previous configurations. Something you can easily do, for instance, with small Alpine images.

I really hope NixOS community could find a better way to reduce the already high footprint of a NixOS system.

[SuperSandro2000]

NixOS uses that old way of doing incremental backup systems to integrate git-like incremental/differential changes into the OS and the packages. But it clashes with typical methods used today to keep an organized tree structure.

No, it hashes the files and then moves the original file to a new directory and creates a hard link to the old location. It is completely client side and actually pretty dumb and a better solution would be preferable but anything smarter requires server side logic or enormous overhead. Right now the cache can just be a dumb file serving server like s3.

Since NixOS is so exotic in its approach and so incompatible with modern tools, It will remain a niche system. I like its approach, but it is useful only when doing experiments that require backtracking to previous configurations. Something you can easily do, for instance, with small Alpine images.

NixOS is not more exotic than alpine with its musl libc. There are other similar systems like Guix, Fedora Silverblue and probably others. I firmly believe that this way of configuring a linux system is the future.

Also WSL is the first tool that completely falls flat because of this. Any other tools I am using just works and is not completely dipping because it encountered a hard link.

An alternative to this is using a different file system like ZFS or btrfs but WSL to my knowledge also does not support that.