@wegank good catch! Do you know if it's just our package, or if the upstream code really isn't compatible with other architectures?

I am not aware of how other distros do, but our own libguestfs-appliance simply fetches and extracts the prebuilt appliance from upstream (which is x86).

I'll work on building the appliance from source, then. I think I'm close to succeeding, but there's still a weird issue where augeas.c can't find a libxml2 include…

@minijackson I am also interested in supermin support. Have you a branch/something I could look at and try to fix ?

@Et7f3 I've pushed what I have in the guestfs-default-appliance-wip branch of my fork:

https://github.com/minijackson/nixpkgs/tree/guestfs-default-appliance-wip

But it's more complicated than I initially thought. Building the appliance is about building a small image of a given Linux distribution, with some tools installed.

How supermin does it is by using the host's package manager to create a small rootfs, and install extra packages in it. The call to the host's package manager needs internet connection, and assumes the host is configured with repos and such.

That doesn't work for us. I think the best we could do would be to create our own small NixOS appliance with the same tools installed, and the same init script.

For more info in the libguestfs source code:

• m4/guestfs-appliance.m4 search for the --with-distro option
• appliance/Makefile.am search for:
  • the HAVE_RPM conditional
  • the guestfsd.deps target
• appliance/packagelist.in
• appliance/make.sh.in (the script that builds the appliance)
• appliance/init (the init script for the appliance)

On another note, I don't think supermin can work on NixOS without either upstream support for NixOS, or using something like Distrobox. But both would only work in the Nix sandbox by using a fixed-output derivation and fixed repos (like CentOS/Rocky's vault repos), or by using impure derivations.

Thanks for reaching out, I'm quite busy these days, but still open for discussion if you're still interested.

I thought about patching supermin upstream like suggested by main dev or bypass supermin and use out tooling to directly create an image.

EDIT: thanks for those hints through codebase.

I think porting supermin to NixOS will be quite difficult; the code is very much distro-specific and the currently supported distros (Fedora, Debian, ...) are nothing like NixOS. Another option would be to build a fixed appliance (like the ones being distributed at https://download.libguestfs.org/binaries/appliance/) in a debian guest using vmTools.runInLinuxImage and libguestfs-make-fixed-appliance. I've implemented this because I needed an aarch64 libguestfs appliance, which is currently not available as a binary, and it works quite well. The downside is that we'll depend on Debian (or another distro supported by supermin) to package new versions of libguestfs, but the maintenance burden for us would be minimal. I could make a PR using that approach, although the builder is currently a little bit hacky because libguestfs-make-fixed-appliance fails to test the appliance it has built due to nested KVM virtualization not being supported in the vmTools VM (probably due to #300084). What do you think?

I think porting supermin to NixOS will be quite difficult; the code is very much distro-specific and the currently supported distros (Fedora, Debian, ...) are nothing like NixOS. Another option would be to build a fixed appliance (like the ones being distributed at https://download.libguestfs.org/binaries/appliance/) in a debian guest using vmTools.runInLinuxImage and libguestfs-make-fixed-appliance. I've implemented this because I needed an aarch64 libguestfs appliance, which is currently not available as a binary, and it works quite well. The downside is that we'll depend on Debian (or another distro supported by supermin) to package new versions of libguestfs, but the maintenance burden for us would be minimal. I could make a PR using that approach, although the builder is currently a little bit hacky because libguestfs-make-fixed-appliance fails to test the appliance it has built due to nested KVM virtualization not being supported in the vmTools VM (probably due to #300084). What do you think?

Fixed appliance is what is currently packaged. According to the docs the performance is the same. If you try grepping debian in nixpkgs you can see there are already many dependencies.
As a side note, won't container or even chroot be enough to run libguestfs-make-fixed-appliance? This should improve build times. Building in container would be a lot of work, but building in debian chroot might be feasible by using existing code from buildFHSEnv.

I think porting supermin to NixOS will be quite difficult; the code is very much distro-specific and the currently supported distros (Fedora, Debian, ...) are nothing like NixOS. Another option would be to build a fixed appliance (like the ones being distributed at https://download.libguestfs.org/binaries/appliance/) in a debian guest using vmTools.runInLinuxImage and libguestfs-make-fixed-appliance. I've implemented this because I needed an aarch64 libguestfs appliance, which is currently not available as a binary, and it works quite well. The downside is that we'll depend on Debian (or another distro supported by supermin) to package new versions of libguestfs, but the maintenance burden for us would be minimal. I could make a PR using that approach, although the builder is currently a little bit hacky because libguestfs-make-fixed-appliance fails to test the appliance it has built due to nested KVM virtualization not being supported in the vmTools VM (probably due to #300084). What do you think?

I've made a PR using this approch here: #381224