Solved Using bhyve to run Kali

Maxnix said:
I've seen this a lot of times when booting Linux systems, and was always harmless.
That said, if you didn't already enable debug output in the VM config file adding debug=yes.

Then post the output of vm-bhyve.log and of bhyve.log (they are both in the VM directory).
Click to expand...
I will collect those logs, but I disagree about this being harmless. It does not boot! That is the only message I get when I attempt to boot. Next post I will include my configuration file.....
 
Ok, wiped the slate clean; destroyed the previous VM and created a new one. The problem remains, it will do the install, try to reboot and then hang with that one line in the VNC window -- No irq handler for 1.55

Here is the configuration file:
Code: 
loader="uefi"
uefi_var="yes"
debug="yes"

cpu="2"
memory="4G"
network0_type="virtio-net"
network0_switch="public"
disk0_type="virtio-blk"
disk0_name="kali.img"

graphics="yes"
# graphics_listen="0.0.0.0"
graphics_port="5901"
graphics_res="1280x1024"
xhci_mouse="yes"

# network0_mac=""
uuid="4eb0c805-92a8-11f1-bbd8-04d4c43907d1"
network0_mac="58:9c:fc:09:37:42"

The bhyve.log file:
Code: 
wrmsr to register 0x140(0) on vcpu 0
wrmsr to register 0x140(0) on vcpu 1
rdmsr to register 0x64e on vcpu 0
rdmsr to register 0x34 on vcpu 0
rdmsr to register 0xc0011029 on vcpu 0
Unhandled ps2 mouse command 0xe1
Unhandled ps2 mouse command 0x88
rdmsr to register 0x64d on vcpu 0
rdmsr to register 0x64d on vcpu 0

And finally the vm-bhyve.log file:
Code: 
2026-08-07T15:38:19-06:00: generated static mac 58:9c:fc:09:37:42
2026-08-07T15:39:57-06:00: initialising
2026-08-07T15:39:57-06:00:  [loader: uefi]
2026-08-07T15:39:57-06:00:  [cpu: 2]
2026-08-07T15:39:57-06:00:  [memory: 4G]
2026-08-07T15:39:57-06:00:  [hostbridge: standard]
2026-08-07T15:39:57-06:00:  [com ports: com1]
2026-08-07T15:39:57-06:00:  [uuid: 4eb0c805-92a8-11f1-bbd8-04d4c43907d1]
2026-08-07T15:39:57-06:00:  [debug mode: yes]
2026-08-07T15:39:57-06:00:  [primary disk: kali.img]
2026-08-07T15:39:57-06:00:  [primary disk dev: file]
2026-08-07T15:39:57-06:00: initialising network device tap1
2026-08-07T15:39:57-06:00: adding tap1 -> vm-public (public addm)
2026-08-07T15:39:57-06:00: bring up tap1 -> vm-public (public addm)
2026-08-07T15:39:57-06:00: booting
2026-08-07T15:39:57-06:00:  [bhyve options: -c 2 -m 4G -AHPw -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd -U 4eb0c805-92a8-11f1-bbd8-04d4c43907d1 -u]
2026-08-07T15:39:57-06:00:  [bhyve devices: -s 0,hostbridge -s 31,lpc -s 0:4:0,virtio-blk,/mnt/vm/kalivm/kali.img -s 0:5:0,virtio-net,tap1,mac=58:9c:fc:09:37:42 -s 0:6:0,fbuf,tcp=0.0.0.0:5901,w=1280,h=1024,wait -s 0:7:0,xhci,tablet]
2026-08-07T15:39:57-06:00:  [bhyve console: -l com1,/dev/nmdm-kalivm.1A]
2026-08-07T15:39:57-06:00:  [bhyve iso device: -s 3:0,ahci-cd,/mnt/vm/.iso/kali-linux-2026.2-installer-amd64.iso,ro,bootindex=1]
2026-08-07T15:39:57-06:00: starting bhyve (run 1)
2026-08-07T15:55:12-06:00: bhyve exited with status 0
2026-08-07T15:55:12-06:00: restarting
2026-08-07T15:55:12-06:00:  [bhyve options: -c 2 -m 4G -AHPw -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd -U 4eb0c805-92a8-11f1-bbd8-04d4c43907d1 -u]
2026-08-07T15:55:12-06:00:  [bhyve devices: -s 0,hostbridge -s 31,lpc -s 0:4:0,virtio-blk,/mnt/vm/kalivm/kali.img -s 0:5:0,virtio-net,tap1,mac=58:9c:fc:09:37:42 -s 0:6:0,fbuf,tcp=0.0.0.0:5901,w=1280,h=1024 -s 0:7:0,xhci,tablet]
2026-08-07T15:55:12-06:00:  [bhyve console: -l com1,/dev/nmdm-kalivm.1A]
2026-08-07T15:55:12-06:00:  [bhyve iso device: -s 3:0,ahci-cd,/mnt/vm/.iso/kali-linux-2026.2-installer-amd64.iso,ro,bootindex=1]
2026-08-07T15:55:12-06:00: starting bhyve (run 2)

The log files looked clean to me - nothing obvious anyway.
 
I think this is the issue with Debian based systems in UEFI boot mode. Here is the solution: start rescue system with the disc attached, or mount the EFI partition of your image on your host. Then
mkdir /target/boot/efi/EFI/BOOT/ && cp /target/boot/efi/EFI/kali/grubx64.efi /target/boot/efi/EFI/BOOT/bootx64.efi
hopefully does the trick
 
I think what I will do next is create the VM and install it without the vm-bhyve tools. I know that works -- did it yesterday. If I can then start the VM with the vm-bhyve tools, rather than type in the bhyve command, that will be a win for me. I am curious as to why the "all vm-bhyve tools" approach is not working -- but that's the fun of computers! Thanks all, I will report how it works out in case it may be helpful to someone else.
 
You must log in or register to reply here.
Back
Top