After using incus-migrate to create an instance from kali-linux-2025.1c-qemu-amd64 instance never starts

Incus
1

Trying to get a kali desktop vm image working in incus. followed instructions to create the instance and it completes the migration, but after finishing the migration the instance never completes loading and is just hung. The Info for the instance is as follows:

Name: kalidt
Description:
Status: RUNNING
Type: virtual-machine
Architecture: x86_64
PID: 76182
Created: 2025/05/22 12:17 CDT
Last Used: 2025/05/23 06:03 CDT
Started: 2025/05/23 06:03 CDT

Resources:
Processes: -1
Disk usage:
root: 13.85GiB
Network usage:
eth0:
Type: broadcast
State: UP
Host interface: tap639b5043
MAC address: 10:66:6a:cb:2b:6a
MTU: 1500
Bytes received: 4.16kB
Bytes sent: 4.22kB
Packets received: 22
Packets sent: 21
IP addresses:
inet6: fd42:d70e:72e:3b78:1266:6aff:fecb:2b6a/64 (global)
inet6: fe80::1266:6aff:fecb:2b6a/64 (link)

Log:

the configuration for the instance looks like:
config:
volatile.cloud-init.instance-id: 5509c898-f38f-4ebf-9354-c14b34b6d26e
volatile.eth0.host_name: tap639b5043
volatile.eth0.hwaddr: 10:66:6a:cb:2b:6a
volatile.last_state.power: RUNNING
volatile.last_state.ready: “false”
volatile.uuid: 5c77de8e-d105-4609-9676-cc844661321a
volatile.uuid.generation: 5c77de8e-d105-4609-9676-cc844661321a
volatile.vm.definition: pc-q35-9.0
volatile.vsock_id: “1482958698”
devices:
root:
path: /
pool: data
type: disk
ephemeral: false
profiles:

  • default
    stateful: false
    description: “”

and the default profile looks like:
config: {}
description: Default Incus profile
devices:
eth0:
name: eth0
network: incusbr0
type: nic
root:
path: /
pool: data
type: disk
name: default
used_by:

  • /1.0/instances/kali
  • /1.0/instances/UBjammy
  • /1.0/instances/kalidt
    project: default

±--------±--------±---------------------±------------------------------------------------±----------------±----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
±--------±--------±---------------------±------------------------------------------------±----------------±----------+
| UBjammy | RUNNING | 10.0.100.82 (enp5s0) | fd42:d70e:72e:3b78:1266:6aff:fe7b:a574 (enp5s0) | VIRTUAL-MACHINE | 0 |
±--------±--------±---------------------±------------------------------------------------±----------------±----------+
| kali | RUNNING | 10.0.100.124 (eth0) | fd42:d70e:72e:3b78:1266:6aff:fed5:6b27 (eth0) | CONTAINER | 0 |
| | | | fd42:7f6d:308e:ad3b:1266:6aff:fed5:6b27 (eth0) | | |
±--------±--------±---------------------±------------------------------------------------±----------------±----------+
| kalidt | RUNNING | | fd42:d70e:72e:3b78:1266:6aff:fecb:2b6a (eth0) | VIRTUAL-MACHINE | 0 |
±--------±--------±---------------------±------------------------------------------------±----------------±----------+

I noticed kalidt is not getting assigned an ipv4 address simialr to how other instances are.

What am I missing, and what could be the cause for the instance running but never reaching a state where it can be interacted with.

2

Welcome!

There are Kali container images on the default repository but no VM images. Here’s the list, incus image list images:kali. Ideally it would be great if there was a distrobuilder configuration file for Kali that produces such VM images.

Having said that, you are trying to use the Kali QEMU qcow2 image and import to Incus with incus-migrate. Can you show the full output of the command incus-migrate, along with parameters? When you try to start the instance, does it find the root device?

3

Yes indeed using the Qemu gcow2 with incus-migrate. supplying answers with stdio redirection in an automated fashion using ansible, the output from the migrat looks like so:

The local Incus server is the target [default=yes]: yes
Would you like to create a container (1) or virtual-machine (2)?:  2
Name of the new instance: kalidt
Please provide the path to a disk, partition, or qcow2/raw/vmdk image file: /opt/kali-linux-2025.1c-qemu-amd64.qcow2
Does the VM support UEFI booting? [default=yes]: 
Does the VM support UEFI booting? [default=yes]: 
Instance to be created:
  Name: kalidt
  Project: default
  Type: virtual-machine
  Source: /opt/kali-linux-2025.1c-qemu-amd64.qcow2
  Source format: qcow2

Additional overrides can be applied at this stage:
1) Begin the migration with the above configuration
2) Override profile list
3) Set additional configuration options
4) Change instance storage pool or volume size
5) Change instance network

Please pick one of the options above [default=1]: 1

Converting image "/opt/kali-linux-2025.1c-qemu-amd64.qcow2" to raw format before importing
Transferring instance: kalidt: 135.54MB (135.54MB/s) .... 
Instance kalidt successfully created

this creates the instance and it shows as running (see my first message). however at this point things go sideways. it never reaches a booted state, and pretty much stays int he state i have shown previously. checking the logs for the kalidt instance this is all thats in there:

cat /var/log/incus/kalidt/qemu.qmp.log
[2025-05-23T06:03:01-05:00] QUERY: {“execute”:“qom-get”,“arguments”:{“path”:“/machine”,“property”:“type”}}
[2025-05-23T06:03:01-05:00] REPLY: {“return”: “pc-q35-9.0-machine”}

[2025-05-23T06:03:01-05:00] QUERY: {“execute”:“query-cpus-fast”}
[2025-05-23T06:03:01-05:00] REPLY: {“return”: [{“thread-id”: 76186, “props”: {“core-id”: 0, “thread-id”: 0, “node-id”: 0, “socket-id”: 0}, “qom-path”: “/machine/unattached/device[0]”, “cpu-index”: 0, “target”: “x86_64”}]}

[2025-05-23T06:03:01-05:00] QUERY: {“execute”:“netdev_add”,“arguments”:{“fds”:“/dev/net/tun.0:/dev/net/tun.1”,“id”:“incus_eth0”,“type”:“tap”,“vhost”:true,“vhostfds”:“/dev/vhost-net.0:/dev/vhost-net.1”}}
[2025-05-23T06:03:01-05:00] REPLY: {“return”: {}}

[2025-05-23T06:03:01-05:00] QUERY: {“execute”:“device_add”,“arguments”:{“addr”:“00.0”,“bootindex”:1,“bus”:“qemu_pcie4”,“driver”:“virtio-net-pci”,“id”:“dev-incus_eth0”,“mac”:“10:66:6a:cb:2b:6a”,“mq”:true,“netdev”:“incus_eth0”,“vectors”:6}}
[2025-05-23T06:03:01-05:00] REPLY: {“return”: {}}

[2025-05-23T06:03:01-05:00] QUERY: {“execute”:“blockdev-add”,“arguments”:{“aio”:“native”,“cache”:{“direct”:true,“no-flush”:false},“discard”:“unmap”,“driver”:“host_device”,“filename”:“/dev/fdset/0”,“locking”:“off”,“node-name”:“incus_root”,“read-only”:false}}
[2025-05-23T06:03:01-05:00] REPLY: {“return”: {}}

[2025-05-23T06:03:01-05:00] QUERY: {“execute”:“device_add”,“arguments”:{“bootindex”:0,“bus”:“qemu_scsi.0”,“channel”:0,“device_id”:“incus_root”,“drive”:“incus_root”,“driver”:“scsi-hd”,“id”:“dev-incus_root”,“lun”:1,“serial”:“incus_root”}}
[2025-05-23T06:03:01-05:00] REPLY: {“return”: {}}

[2025-05-23T06:03:01-05:00] QUERY: {“execute”:“system_reset”}
[2025-05-23T06:03:01-05:00] REPLY: {“return”: {}}

[2025-05-23T06:03:01-05:00] QUERY: {“execute”:“set-action”,“arguments”:{“panic”:“pause”,“reboot”:“shutdown”,“shutdown”:“poweroff”}}
[2025-05-23T06:03:01-05:00] REPLY: {“return”: {}}

[2025-05-23T06:03:01-05:00] QUERY: {“execute”:“cont”}
[2025-05-23T06:03:01-05:00] REPLY: {“return”: {}}

[2025-05-23T06:03:12-05:00] QUERY: {“execute”:“query-status”}
[2025-05-23T06:03:12-05:00] REPLY: {“return”: {“status”: “running”, “running”: true}}

[2025-05-23T06:05:30-05:00] QUERY: {“execute”:“query-status”}
[2025-05-23T06:05:30-05:00] REPLY: {“return”: {“status”: “running”, “running”: true}}

[2025-05-23T06:10:49-05:00] QUERY: {“execute”:“query-status”}
[2025-05-23T06:10:49-05:00] REPLY: {“return”: {“status”: “running”, “running”: true}}

[2025-05-23T06:14:35-05:00] QUERY: {“execute”:“query-status”}
[2025-05-23T06:14:35-05:00] REPLY: {“return”: {“status”: “running”, “running”: true}}

any ideas to get this instance working would be very helpfull thanks!

4

So I followed the exact same steps, and I got the Kali VM running on Incus 6.12.

image
image1300×880 236 KB

I had to set security.secureboot=false (as you did earlier), and also security.csm=true (i.e. not UEFI).
Can you verify that both are set properly for you?

5

i noticed in the first instance i tried those were set incorrectly, however i did set them and re-image with those set but in my instance the vm is still not starting. Heres the config as it stands now

incus config show kalidt
sh: 0: getcwd() failed: No such file or directory
architecture: x86_64
config:
security.csm: “true”
security.secureboot: “false”
volatile.cloud-init.instance-id: cdbc77ed-67f2-454a-8696-a847a711e0ca
volatile.eth0.host_name: tap0c9bf63b
volatile.eth0.hwaddr: 10:66:6a:20:a3:9e
volatile.last_state.power: RUNNING
volatile.uuid: 7e8f47b5-e165-4b03-a9c7-1296dc32784c
volatile.uuid.generation: 7e8f47b5-e165-4b03-a9c7-1296dc32784c
volatile.vm.definition: pc-q35-9.0
volatile.vsock_id: “2537560653”
devices:
root:
path: /
pool: data
type: disk
ephemeral: false
profiles:

  • default
    stateful: false
    description: “”

one thing i did notice is “sh: 0: getcwd() failed: No such file or directory” is that normal?

6

The getcwd() is weird.
As if your current directory does not exist, and the Incus client tries to run getcwd() in there. Can you run the command in some other directory, like your home directory?

Here’s to compare.

$ incus config show kalivm
architecture: x86_64
config:
  security.csm: "true"
  security.secureboot: "false"
  volatile.cloud-init.instance-id: 64b58b97-e803-4d66-8df0-35f2293c0bc3
  volatile.eth0.hwaddr: 10:66:6a:42:29:e9
  volatile.last_state.power: STOPPED
  volatile.uuid: 354c6165-409f-4f0f-b8d7-f72ec158f88a
  volatile.uuid.generation: 354c6165-409f-4f0f-b8d7-f72ec158f88a
  volatile.vm.definition: pc-q35-9.0
  volatile.vsock_id: "1702760338"
devices:
  root:
    path: /
    pool: default
    type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""
$
7

Update: the getcwd issue seemed to be a temporary problem related to networking. no longer occurring

The instance now gets an ip. But it seems to be halting at grub start?. i stopped the instance, and that’s when THIS console.log gets crated:

Machine UUID 7e8f47b5-e165-4b03-a9c7-1296dc32784c
iPXE (http://ipxe.org) 05:00.0 CA00 PCI2.10 PnP PMM+7EFD3050+7EF33050 CA00

Booting from Hard Disk…
GRUB loading.
Welcome to GRUB!

And thats all. it never gets past that
I should mention I am running incus 6.12 on ubuntu 22.04 and lts loading other vm/containers correctly.
heres what the current config looks like:
Name: kalidt
Description:
Status: RUNNING
Type: virtual-machine
Architecture: x86_64
PID: 118672
Created: 2025/05/23 12:04 CDT
Last Used: 2025/05/24 02:05 CDT
Started: 2025/05/24 02:05 CDT

Resources:
Processes: -1
Disk usage:
root: 13.94GiB
Network usage:
eth0:
Type: broadcast
State: UP
Host interface: tape9550814
MAC address: 10:66:6a:20:a3:9e
MTU: 1500
Bytes received: 119.90kB
Bytes sent: 37.83kB
Packets received: 1103
Packets sent: 402
IP addresses:
inet: 10.0.100.115/24 (global)
inet6: fd42:d70e:72e:3b78:1266:6aff:fe20:a39e/64 (global)
inet6: fe80::dc7f:7432:60b0:2f20/64 (link)

Log:

architecture: x86_64
config:
limits.memory: 14GiB
security.csm: “true”
security.secureboot: “false”
volatile.cloud-init.instance-id: cdbc77ed-67f2-454a-8696-a847a711e0ca
volatile.eth0.host_name: tape9550814
volatile.eth0.hwaddr: 10:66:6a:20:a3:9e
volatile.last_state.power: RUNNING
volatile.last_state.ready: “false”
volatile.uuid: 7e8f47b5-e165-4b03-a9c7-1296dc32784c
volatile.uuid.generation: 7e8f47b5-e165-4b03-a9c7-1296dc32784c
volatile.vm.definition: pc-q35-9.0
volatile.vsock_id: “2537560653”
devices:
root:
path: /
pool: data
type: disk
ephemeral: false
profiles:

  • default
    stateful: false
    description: “”
    ±--------±--------±---------------------±------------------------------------------------±----------------±----------+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
    ±--------±--------±---------------------±------------------------------------------------±----------------±----------+
    | UBjammy | RUNNING | 10.0.100.82 (enp5s0) | fd42:d70e:72e:3b78:1266:6aff:fe7b:a574 (enp5s0) | VIRTUAL-MACHINE | 0 |
    ±--------±--------±---------------------±------------------------------------------------±----------------±----------+
    | kali | RUNNING | 10.0.100.124 (eth0) | fd42:d70e:72e:3b78:1266:6aff:fed5:6b27 (eth0) | CONTAINER | 0 |
    | | | | fd42:7f6d:308e:ad3b:1266:6aff:fed5:6b27 (eth0) | | |
    ±--------±--------±---------------------±------------------------------------------------±----------------±----------+
    | kalidt | RUNNING | 10.0.100.115 (eth0) | fd42:d70e:72e:3b78:1266:6aff:fe20:a39e (eth0) | VIRTUAL-MACHINE | 0 |
    ±--------±--------±---------------------±------------------------------------------------±----------------±----------+

and thers the contents of the
cat qemu.qmp.log
[2025-05-25T03:00:41-05:00] QUERY: {“execute”:“qom-get”,“arguments”:{“path”:“/machine”,“property”:“type”}}
[2025-05-25T03:00:41-05:00] REPLY: {“return”: “pc-q35-9.0-machine”}

[2025-05-25T03:00:41-05:00] QUERY: {“execute”:“query-cpus-fast”}
[2025-05-25T03:00:41-05:00] REPLY: {“return”: [{“thread-id”: 138569, “props”: {“core-id”: 0, “thread-id”: 0, “node-id”: 0, “socket-id”: 0}

[2025-05-25T03:00:41-05:00] QUERY: {“execute”:“netdev_add”,“arguments”:{“fds”:“/dev/net/tun.0:/dev/net/tun.1”,“id”:“incus_eth0”,“type”:"ta
[2025-05-25T03:00:41-05:00] REPLY: {“return”: {}}

[2025-05-25T03:00:41-05:00] QUERY: {“execute”:“device_add”,“arguments”:{“addr”:“00.0”,“bootindex”:1,“bus”:“qemu_pcie4”,“driver”:"virtio-ne
[2025-05-25T03:00:41-05:00] REPLY: {“return”: {}}

[2025-05-25T03:00:41-05:00] QUERY: {“execute”:“blockdev-add”,“arguments”:{“aio”:“native”,“cache”:{“direct”:true,“no-flush”:false},"discard
[2025-05-25T03:00:41-05:00] REPLY: {“return”: {}}

[2025-05-25T03:00:41-05:00] QUERY: {“execute”:“device_add”,“arguments”:{“bootindex”:0,“bus”:“qemu_scsi.0”,“channel”:0,“device_id”:"incus_r
[2025-05-25T03:00:41-05:00] REPLY: {“return”: {}}

[2025-05-25T03:00:41-05:00] QUERY: {“execute”:“system_reset”}
[2025-05-25T03:00:41-05:00] REPLY: {“return”: {}}

[2025-05-25T03:00:41-05:00] QUERY: {“execute”:“set-action”,“arguments”:{“panic”:“pause”,“reboot”:“shutdown”,“shutdown”:“poweroff”}}
[2025-05-25T03:00:41-05:00] REPLY: {“return”: {}}

[2025-05-25T03:00:41-05:00] QUERY: {“execute”:“cont”}
[2025-05-25T03:00:41-05:00] REPLY: {“return”: {}}

At this point to me it looks the issue is somewhere with the incus-migrate as incus seems to be doing everything correctly, but this is just a guess since i don’t know incus that well yet to know where else to look. Or is there additional missing config that i need to add during the migration to get past this?

8

Ive been thinking about and alternate solution is to create a distro builder from the current template , and add the additional packages and tooling necessary to be a vm (vncserver, desktop, etc.) ( This would also be useful for adding additional packages that i would like in the kali vm to begin with.)

Are there any additional gochas or necessary components to add to create a kali desktop vm i would need (not listed on the distribuilder requirements?)

9

There are a few desktop VM images on the official repository of images. You can start there and try them out to verify that your system does not have some unrelated issue. See How to run a Linux Desktop virtual machine on Incus – Mi blog lah!

Then, you can check the repository at lxc-ci/images at main · lxc/lxc-ci · GitHub and locate the distrobuilder configuration files that are related to those desktop images.

When you run distrobuilder with a configuration file, you need to use the appropriate parameters in order to get the correct image (i.e. specify desktop to get the desktop image). See https://images.linuxcontainers.org/ and the column Build date for the build logs of each image. In there you can find the exact distrobuilder command line. For example, the parameters for the Ubuntu desktop image are -o image.architecture=amd64 -o image.release=jammy -o image.variant=desktop -o source.url=http://archive.ubuntu.com/ubuntu.