[Backport release-24.11] incus: 6.8.0 -> 6.9.0

[adamcstephens]

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.

[adamcstephens]

Ahh, nice. The x86 test passed in ofborg. Built both x86 and aarch64 tests locally.

Cherry-pick error is known, as I had to manually resolve the conflict in package.nix

[srd424]

Something to do with lxc/incus#1547 subtly breaks read/write 9p mounts? As in, I get permission denied errors in the guest. Switching to virtiofs seems to sort it. This is probably only going to mess up people like me doing weird manual mounts - I assume the agent will handle it for most people.

[srd424]

It looks like the db schema changed for 6.5, so using incus-lts (6.0.x) wouldn't be an easy option for anyone hit by this. I suppose we could add an explicit 6.8 package? But maybe not worth it unless anyone else complains :)

[adamcstephens]

Hmm, you could try reversing that patch to see if it fixes the issue. That was for qemu 9.2, which doesn't affect 24.11. I'll accept a PR to do so if it helps. Or we can revert this version and call non-LTS unsupported for the remainder of 24.11.

I treat this package as a best effort on the stable release, but there's a point where it passes the amount of time I'm willing to spend to maintain. That's why LTS is the default :)

[srd424]

Ah, I've fiddled with my VM to switch the mount to virtiofs and that's solved it for me. Probably not worth worrying about unless anyone else moans - we should be more or less half-way to 25.05 now anyway!

(I think I ended up on non-LTS by accident - at one point I needed a feature not in the previous LTS, and forgot to switch back. This was the first time I noticed, by which time the schema upgrade has happened!)

[adamcstephens]

Yeah, the schema upgrades are a bit unfortunate. I'm not sure if there's a good way for us to protect users from the point of no return. :/

[srd424]

I can't think of a general solution that wouldn't involve throwing errors on upgrade to force the users to specifically consent to the schema update, and that doesn't feel like it's "the nixos way" :(

The only thing that did occur to me is a way to request a minimum incus version, e.g. if you need a specific feature like I did. That could always select LTS where possible, and only non-LTS where necessary, eventually switching the user back to a later LTS when it had 'caught up.' But if I'm the only person doing weird things that may still be overkill :)