Incus shows "Error: VM agent isn't currently running"

Incus
1

When creating a new VM with a fresh Incus installation, I cannot run any command because the incus-agent seems not to be started.

OS: Fedora
Kernel version: 6.15.4
Incus version: 6.12

~
❯ incus ls
+-----------+---------+------+------------------------------------------------+-----------------+-----------+
|   NAME    |  STATE  | IPV4 |                      IPV6                      |      TYPE       | SNAPSHOTS |
+-----------+---------+------+------------------------------------------------+-----------------+-----------+
| debian-vm | RUNNING |      | fd42:c16f:915f:bdd6:1266:6aff:feb3:d9e4 (eth0) | VIRTUAL-MACHINE | 0         |
+-----------+---------+------+------------------------------------------------+-----------------+-----------+
| first     | RUNNING |      | fd42:c16f:915f:bdd6:1266:6aff:fea5:39bf (eth0) | VIRTUAL-MACHINE | 0         |
+-----------+---------+------+------------------------------------------------+-----------------+-----------+

~
❯ incus info first
Name: first
Description:
Status: RUNNING
Type: virtual-machine
Architecture: x86_64
PID: 57388
Created: 2025/07/07 14:21 -03
Last Used: 2025/07/07 14:21 -03
Started: 2025/07/07 14:21 -03

Resources:
  Processes: -1
  Network usage:
    eth0:
      Type: broadcast
      State: UP
      Host interface: tap726c1eb8
      MAC address: 10:66:6a:a5:39:bf
      MTU: 1500
      Bytes received: 858B
      Bytes sent: 164B
      Packets received: 5
      Packets sent: 2
      IP addresses:
        inet6: fd42:c16f:915f:bdd6:1266:6aff:fea5:39bf/64 (global)

~
❯ date
Mon Jul  7 02:34:52 PM -03 2025

I understand that “Process: -1” means that the incus-agent hasn’t started yet, but why? When I run incus console first --show-log it returns this:

~
❯ incus console first --show-log
0
0
BdsDxe: loading Boot0002 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/Scsi(0x0,0x1)
BdsDxe: starting Boot0002 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/Scsi(0x0,0x1)
!!!! X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID - 00000000 !!!!
ExceptionData - 0000000000000011  I:1 R:0 U:0 W:0 P:1 PK:0 SS:0 SGX:0
RIP  - 0000000001800200, CS  - 0000000000000038, RFLAGS - 0000000000210006
RAX  - 0000000001800200, RCX - 0000000000000000, RDX - 000000003CF513E8
RBX  - 000000003CF51000, RSP - 000000003EF291B0, RBP - 0000000000000190
RSI  - 000000003CF51000, RDI - 0000000000000010
R8   - 0000000000000085, R9  - 0000000034B487B0, R10 - 0000000010000000
R11  - 00000000F0000000, R12 - 000000003CF51000, R13 - 000000003C6EDEA0
R14  - 000000003C6E85A1, R15 - 000000003C6F8FA0
DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
GS   - 0000000000000030, SS  - 0000000000000030
CR0  - 0000000080010033, CR2 - 0000000001800200, CR3 - 000000003EC01000
CR4  - 0000000000000668, CR8 - 0000000000000000
DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 000000003E9E1000 0000000000000047, LDTR - 0000000000000000
IDTR - 000000003E3AE018 0000000000000FFF,   TR - 0000000000000000
FXSAVE_STATE - 000000003EF28E10
!!!! Find image based on IP(0x3C6EDEA0) (No PDB)  (ImageBase=000000003C6DD000, EntryPoint=000000003C6DE000) !!!!
2

The UEFI EDK2 firmware crashed, so your VM never booted.

You may want to give different OS/releases a try in the guest VM to see if they all fail in the same way. But given that Fedora packages its own EDK2, it’s not likely to be something we can do much about.

Once you narrow things down a bit, you’ll need to file a bug against the Fedora package.

The main things I’d play with when it comes to such failures:

  • Guest OS. We’ve seen older RHEL based distros using an old UEFI protocol which has been known to trigger this kind of EDK2 failure. The Ubuntu/Debian Zabbly packages ship with this EDK2 change reverted to maximize compatibility.
  • We’ve occasionally seen EDK2 crash based on limits.cpu/limits.memory value, so playing around with those may be useful.
3

I’ve tested with Centos 9 and Ubuntu jammy and both crashed on VM boot. I filed a bug on bugzilla, here is the link

4

Maybe try Ubuntu Noble or Debian 13 for something that we know for sure handles the modern UEFI protocol though I believe the issue with that was on the likes of CentOS 7 so I’d expect CentOS 9 and Ubuntu Jammy to both support it fine.

It’s probably something else odd going on in EDK2… We find ourselves testing new versions and then reverting to older ones much more regularly than we’d like for a project of this importance (EDK2 is supposed to be a reference UEFI implementation) …

5

Yeah, I tested with Ubuntu noble and it works fine (fingerprint: 2b799c83d6f8). I reboot my PC and reinstall Incus just in case, but the problem still occurs.

With Ubuntu noble:

~
❯ incus ls -c nstf
+-------+---------+-----------------+--------------+
| NAME  |  STATE  |      TYPE       |  BASE IMAGE  |
+-------+---------+-----------------+--------------+
| test  | RUNNING | VIRTUAL-MACHINE | 2b799c83d6f8 |
+-------+---------+-----------------+--------------+
| test2 | RUNNING | VIRTUAL-MACHINE | 955e60f4861e |
+-------+---------+-----------------+--------------+

~
❯ incus info test
Name: test
Description:
Status: RUNNING
Type: virtual-machine
Architecture: x86_64
PID: 4617
Created: 2025/07/08 09:58 -03
Last Used: 2025/07/08 09:58 -03
Started: 2025/07/08 09:58 -03

Operating System:
  OS: Ubuntu
  OS Version: 24.04
  Kernel Version: 6.8.0-63-generic
  Hostname: test
  FQDN: localhost

Resources:
  Processes: 13
6

Okay, so it’s probably some variation of the UEFI bootloader protocol change or whatever it was called and that lines up with what we’ve seen on our end when trying to push a newer EDK2 through the Zabbly packages…

It may be worth checking with edk2 upstream to see if it’s something they’re aware of, especially when it impacts something that’s still pretty recent (CentOS 9).