libguestfs-appliance-debian: init at 1.54.0

[malte-v]

Instead of downloading the binary appliance from upstream, build it locally inside a debian guest. This adds aarch64 support as upstream does not provide prebuilt aarch64 appliances.

This currently leads to an evaluation warning because the libguestfs-appliance package has a lower version than the libguestfs package. It's probably no big deal™ and can be solved once the debian maintainers update their libguestfs package to 1.54.0.

Needs testing on x86_64.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[malte-v]

I don't really understand the CI failures...

[minijackson]

@malte-v I think it has to do with IFD (Import From Derivation):

the way vmTools.makeImageFromDebDist is implemented, it generates a .nix file (see here) and then imports it (here). This behavior is not allowed in nixpkgs, so I think vmTools as a whole is only usable outside of nixpkgs, unfortunately…

[jchv]

This currently leads to an evaluation warning because the libguestfs-appliance package has a lower version than the libguestfs package. It's probably no big deal™ and can be solved once the debian maintainers update their libguestfs package to 1.54.0.

It does matter for libguestfs things that need the appliance, like guestmount. It can work, but isn't guaranteed to. That's actually the reason why I opened #280881.

Unfortunately I think this approach can't work due to the IFD anyways, but it really would be great if we could get the libguestfs appliance building in NixOS properly. Maybe some day :\

[malte-v]

@malte-v I think it has to do with IFD (Import From Derivation):

the way vmTools.makeImageFromDebDist is implemented, it generates a .nix file (see here) and then imports it (here). This behavior is not allowed in nixpkgs, so I think vmTools as a whole is only usable outside of nixpkgs, unfortunately…

Thanks, that was it! I've checked in the generated nix file to get rid of the IFD and expanded the instructions for updating accordingly.

[malte-v]

This currently leads to an evaluation warning because the libguestfs-appliance package has a lower version than the libguestfs package. It's probably no big deal™ and can be solved once the debian maintainers update their libguestfs package to 1.54.0.

It does matter for libguestfs things that need the appliance, like guestmount. It can work, but isn't guaranteed to. That's actually the reason why I opened #280881.

Fair point. I've tested the appliance with guestfish and partitioning, uploading/downloading files etc., but we can wait for libguestfs 1.54.0 to land in Debian before going forward with this to be extra safe. I still think that this approach is better than relying on the infrequently-updated x86-only upstream appliance.

[jchv]

I was curious to see if this had ever been done before in Nixpkgs and the answer seems to be yes... once.

#368081

It still seems like it's better than the status quo, but it definitely leaves me with a lot of questions. Certainly it has a much lower maintenance burden than basically building the image manually, but it also seems like it is unlikely to be synced with libguestfs very often.

An interesting problem.

[malte-v]

but it also seems like it is unlikely to be synced with libguestfs very often.

I think keeping the two packages in sync won't be an issue; the only downside I see is that we're always going to be slower than the Debian folks with packaging new libguestfs versions (simply because we're effectively shipping a tiny version of Debian in the form of the appliance). I've added a comment in the libguestfs package explaining that the two packages need to be updated simultaneously, and in particular they can only be updated after the update lands in Debian testing.

[lukts30]

I will have a closer look at this PR over the weekend.

For now I will leave this counter proposal / proof of concept to build a NixOS based guest appliance.
POC only, as I only tested it against libguestfs-test-tool, libguestfs' installCheckPhase and virt-v2v. Most of /etc/ is also missing. Work by pretending to be an Arch Linux + pacman but everything get copied via hostfiles.

[lukts30]

I could not build this on x86_64 as the deb-closure.nix file currently only lists arm64 packages. And as I do not have an arm64 system with virtualisation capabilities I did not test that either.

starting stage 2 (/nix/store/2320kcbfc691fd8mrhb3fh62c7swqswh-vm-run-stage2)
/nix/store/wr2g12zjwngip349s7ryiaz67j58zlfl-stdenv-linux/setup: line 1199: /usr/bin/install: cannot execute binary file: Exec format error
/nix/store/wr2g12zjwngip349s7ryiaz67j58zlfl-stdenv-linux/setup: line 1199: /usr/bin/install: cannot execute binary file: Exec format error
Running phase: patchPhase
/nix/store/wr2g12zjwngip349s7ryiaz67j58zlfl-stdenv-linux/setup: line 1199: /usr/bin/install: cannot execute binary file: Exec format error
/nix/store/wr2g12zjwngip349s7ryiaz67j58zlfl-stdenv-linux/setup: line 1763: /usr/bin/date: cannot execute binary file: Exec format error
[    5.669721] request_module: modprobe binfmt-464c cannot be processed, kmod busy with 50 threads for more than 5 seconds now
[    5.852925] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007e00

I also think you need to keep the Hydra opt out, otherwise we will get the "output limit exceeded" error. Even though the appliance is a 4GB ext2 sparse file hydra will still complain. But since it would be quite annoying to always build the appliance locally, one way to fix this would be to try to convert the 4GB raw to a qcow2 image. (libguestfs can read raw and qcow2 but on its own always creates raw)

If we do this, I would also like to keep the existing libguestfs-appliance as is (maybe rename the existing pkg to libguestfs-appliance-fedora-bin and name the new one libguestfs-appliance-debian. I am ok with changing libguestfs-with-appliance to use the debian one, as that would improve the situation for arm64.

But first I need a version that works on x86_64 that I can test.

[malte-v]

I could not build this on x86_64 as the deb-closure.nix file currently only lists arm64 packages.

Whoops, I've pushed a fix.

As for producing an appliance in qcow2 format, can you point me to some documentation? I couldn't find any information in the manual pages.

[lukts30]

Something like this should do it. libguestfs/libguestfs@3cad943

mkdir appliance
libguestfs-make-fixed-appliance appliance/
${pkgs.qemu-utils}/bin/qemu-img convert -f raw -O qcow2 appliance/root root.qcow2

install -m444 -D appliance/kernel $out/
install -m444 -D appliance/initrd $out/
install -m444 -D root.qcow2 $out/root
install -m444 -D appliance/README.fixed $out/

But for this to work libguestfs/package.nix --enable-appliance-format-auto must also be appended to the configureFlags.

[malte-v]

Thanks! The latest commit now builds a qcow2 appliance.

If we do this, I would also like to keep the existing libguestfs-appliance as is

May I ask why? Functionally it should be the same as the new one, right?

[lukts30]

Just having access to the upstream blessed (fedora) appliance in nixpkgs makes testing / validating newer libguestfs versions easier. It also does not really add maintainer overhead as it only wraps a tar file. It's src can also easily be overridden to point to someone else build libguestfs-make-fixed-appliance -xz etc.

So my preferred path forward would be:

• 1st commit changes li/libguestfs/package.nix and adds --enable-appliance-format-auto
• 2nd commit introduces the new li/libguestfs-appliance-debian/package.nix
  • with updated meta.description
  • split buildPhase & installPhase
• 3rd commit changes li/libguestfs-with-appliance/package.nix
  • sets appliance = libguestfs-appliance-debian & enables aarch64-linux
  • also need to relax the version warning while still making sure that mishaps do not happen in the future...
    • not sure what the right check would be
• 4th commit changes libguestfs/package.nix
  • removes the hydra opt-out
• 5th commit (optionally) renames the "old" libguestfs-appliance & changes description to avoid confusion

[lukts30]

I did test this PR with virt-v2v and virt-inspector and found no issues like #280881
So it seems like in this case the older appliance does not cause a problem.

[lukts30]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 381224

---

x86_64-linux

❌ 2 packages failed to build:

• python313Packages.guestfs
• python313Packages.guestfs.dist

✅ 14 packages built:

• diffoscope
• diffoscope.dist
• diffoscope.man
• guestfs-tools
• libguestfs
• libguestfs-appliance-debian
• libguestfs-appliance-fedora-bin
• libguestfs-with-appliance
• libguestfs-with-appliance.guestfsd
• libguestfs.guestfsd
• python312Packages.guestfs
• python312Packages.guestfs.dist
• vagrant
• virt-v2v

---

• depreciate python3.guestfs in favour of libguestfs python bindings (which are currently not built) #167865

[malte-v]

I've tried splitting the build and install phases btw, but then the build always fails with a "no space left on device" error, even after increasing the VM disk image size to 32G.

[lukts30]

LGTM now, but someone else should judge if this vmTools.runInLinuxImage approach is OK for a hydra build.
Especially since the only other example @jchv found in #368081 was in an unfree package, which means it does not run on hydra.

[malte-v]

Updated to v1.54.0