Vm wont boot

[jacha]

I have a pfsense vm that wont boot. And I dont getting much in the logs on why that can be. Where can I look for the reason? In syslog I get this:

Mar 26 00:14:03 pve pvestatd[2084]: VM 100 qmp command failed - VM 100 qmp command 'query-proxmox-support' failed - unable to connect to VM 100 qmp socket - timeout after 51 retries
Mar 26 00:14:03 pve pvestatd[2084]: status update time (8.098 seconds)
Mar 26 00:14:04 pve pve-guests[2222]: start failed: command '/usr/bin/kvm -id 100 -name 'pfSense,debug-threads=on' -no-shutdown -chardev 'socket,id=qmp,path=/var/run/qemu-server/100.qmp,server=on,wait=off' -mon 'chardev=qmp,mode=control' -chardev 'socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5' -mon 'chardev=qmp-event,mode=control' -pidfile /var/run/qemu-server/100.pid -daemonize -smbios 'type=1,uuid=fd4b60d9-bdea-4d8b-a019-928bd74e0963' -smp '4,sockets=1,cores=4,maxcpus=4' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' -vnc 'unix:/var/run/qemu-server/100.vnc,password=on' -cpu kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep -m 8192 -object 'iothread,id=iothread-virtioscsi0' -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' -device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' -device 'pci-bridge,id=pci.3,chassis_nr=3,bus=pci.0,addr=0x5' -device 'vmgenid,guid=5a394dca-b1ee-4081-852c-b0bca72bda4a' -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'qxl-vga,id=vga,max_outputs=4,bus=pci.0,addr=0x2' -device 'virtio-serial,id=spice,bus=pci.0,addr=0x9' -chardev 'spicevmc,id=vdagent,name=vdagent' -device 'virtserialport,chardev=vdagent,name=com.redhat.spice.0' -spice 'tls-port=61000,addr=127.0.0.1,tls-ciphers=HIGH,seamless-migration=on' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3,free-page-reporting=on' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:614434bd2755' -device 'virtio-scsi-pci,id=virtioscsi0,bus=pci.3,addr=0x1,iothread=iothread-virtioscsi0' -drive 'file=/dev/zvol/rpool/data/vm-100-disk-0,if=none,id=drive-scsi0,format=raw,cache=none,aio=io_uring,detect-zeroes=on' -device 'scsi-hd,bus=virtioscsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100' -netdev 'type=tap,id=net0,ifname=tap100i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=6A:8F:AD:DB:4E:31,netdev=net0,bus=pci.0,addr=0x12,id=net0,rx_queue_size=1024,tx_queue_size=1024' -netdev 'type=tap,id=net5,ifname=tap100i5,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=AE:8A:AE:B7:00:91,netdev=net5,bus=pci.0,addr=0x17,id=net5,rx_queue_size=1024,tx_queue_size=1024' -machine 'type=pc+pve0'' failed: got timeout
Mar 26 00:14:04 pve pvesh[2182]: Starting VM 100 failed: start failed: command '/usr/bin/kvm -id 100 -name 'pfSense,debug-threads=on' -no-shutdown -chardev 'socket,id=qmp,path=/var/run/qemu-server/100.qmp,server=on,wait=off' -mon 'chardev=qmp,mode=control' -chardev 'socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5' -mon 'chardev=qmp-event,mode=control' -pidfile /var/run/qemu-server/100.pid -daemonize -smbios 'type=1,uuid=fd4b60d9-bdea-4d8b-a019-928bd74e0963' -smp '4,sockets=1,cores=4,maxcpus=4' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' -vnc 'unix:/var/run/qemu-server/100.vnc,password=on' -cpu kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep -m 8192 -object 'iothread,id=iothread-virtioscsi0' -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' -device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' -device 'pci-bridge,id=pci.3,chassis_nr=3,bus=pci.0,addr=0x5' -device 'vmgenid,guid=5a394dca-b1ee-4081-852c-b0bca72bda4a' -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'qxl-vga,id=vga,max_outputs=4,bus=pci.0,addr=0x2' -device 'virtio-serial,id=spice,bus=pci.0,addr=0x9' -chardev 'spicevmc,id=vdagent,name=vdagent' -device 'virtserialport,chardev=vdagent,name=com.redhat.spice.0' -spice 'tls-port=61000,addr=127.0.0.1,tls-ciphers=HIGH,seamless-migration=on' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3,free-page-reporting=on' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:614434bd2755' -device 'virtio-scsi-pci,id=virtioscsi0,bus=pci.3,addr=0x1,iothread=iothread-virtioscsi0' -drive 'file=/dev/zvol/rpool/data/vm-100-disk-0,if=none,id=drive-scsi0,format=raw,cache=none,aio=io_uring,detect-zeroes=on' -device 'scsi-hd,bus=virtioscsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100' -netdev 'type=tap,id=net0,ifname=tap100i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=6A:8F:AD:DB:4E:31,netdev=net0,bus=pci.0,addr=0x12,id=net0,rx_queue_size=1024,tx_queue_size=1024' -netdev 'type=tap,id=net5,ifname=tap100i5,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=AE:8A:AE:B7:00:91,netdev=net5,bus=pci.0,addr=0x17,id=net5,rx_queue_size=1024,tx_queue_size=1024' -machine 'type=pc+pve0'' failed: got timeout
Mar 26 00:14:04 pve pve-guests[2182]: <root@pam> end task UPID:pve:000008AD:00000973:641F801D:startall::root@pam: OK
Mar 26 00:14:04 pve systemd[1]: Finished PVE guests.
Mar 26 00:14:07 pve kernel: [   57.468362] vmbr0: port 2(tap100i5) entered blocking state
Mar 26 00:14:07 pve kernel: [   57.468412] vmbr0: port 2(tap100i5) entered forwarding state
Mar 26 00:14:07 pve pvedaemon[2113]: <root@pam> successful auth for user 'root@pam'
Mar 26 00:14:07 pve systemd[1]: Starting Proxmox VE scheduler...
Mar 26 00:14:07 pve kernel: [   58.054506] vmbr0: port 2(tap100i5) entered disabled state
Mar 26 00:14:08 pve pvescheduler[2654]: starting server
Mar 26 00:14:08 pve systemd[1]: Started Proxmox VE scheduler.
Mar 26 00:14:08 pve systemd[1]: Reached target Multi-User System.
Mar 26 00:14:08 pve systemd[1]: Reached target Graphical Interface.
Mar 26 00:14:13 pve kernel: [   63.852593] device eno1 left promiscuous mode
Mar 26 00:14:13 pve systemd[1]: Starting Update UTMP about System Runlevel Changes...
Mar 26 00:14:13 pve systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
Mar 26 00:14:13 pve systemd[1]: Finished Update UTMP about System Runlevel Changes.
Mar 26 00:14:13 pve systemd[1]: Startup finished in 1min 14.375s (firmware) + 3.715s (loader) + 6.835s (kernel) + 57.078s (userspace) = 2min 22.004s.
Mar 26 00:14:13 pve kernel: [   64.315556] vmbr1: port 2(tap100i0) entered disabled state
Mar 26 00:14:14 pve pvestatd[2084]: VM 100 qmp command failed - VM 100 qmp command 'query-proxmox-support' failed - unable to connect to VM 100 qmp socket - timeout after 51 retries
Mar 26 00:14:14 pve pvestatd[2084]: status update time (8.094 seconds)
Mar 26 00:14:23 pve pvestatd[2084]: VM 100 qmp command failed - VM 100 qmp command 'query-proxmox-support' failed - unable to connect to VM 100 qmp socket - timeout after 51 retries
Mar 26 00:14:23 pve pvestatd[2084]: status update time (8.093 seconds)
Mar 26 00:14:33 pve pvestatd[2084]: VM 100 qmp command failed - VM 100 qmp command 'query-proxmox-support' failed - unable to connect to VM 100 qmp socket - timeout after 51 retries
Mar 26 00:14:33 pve pvestatd[2084]: status update time (8.093 seconds)

 

[leesteken]

I have a pfsense vm that wont boot. And I dont getting much in the logs on why that can be. Where can I look for the reason? In syslog I get this:

Mar 26 00:14:04 pve pve-guests[2222]: start failed: command '/usr/bin/kvm -id 100 -name 'pfSense,debug-threads=on' -no-shutdown -chardev 'socket,id=qmp,path=/var/run/qemu-server/100.qmp,server=on,wait=off' -mon 'chardev=qmp,mode=control' -chardev 'socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5' -mon 'chardev=qmp-event,mode=control' -pidfile /var/run/qemu-server/100.pid -daemonize -smbios 'type=1,uuid=fd4b60d9-bdea-4d8b-a019-928bd74e0963' -smp '4,sockets=1,cores=4,maxcpus=4' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' -vnc 'unix:/var/run/qemu-server/100.vnc,password=on' -cpu kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep -m 8192 -object 'iothread,id=iothread-virtioscsi0' -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' -device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' -device 'pci-bridge,id=pci.3,chassis_nr=3,bus=pci.0,addr=0x5' -device 'vmgenid,guid=5a394dca-b1ee-4081-852c-b0bca72bda4a' -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'qxl-vga,id=vga,max_outputs=4,bus=pci.0,addr=0x2' -device 'virtio-serial,id=spice,bus=pci.0,addr=0x9' -chardev 'spicevmc,id=vdagent,name=vdagent' -device 'virtserialport,chardev=vdagent,name=com.redhat.spice.0' -spice 'tls-port=61000,addr=127.0.0.1,tls-ciphers=HIGH,seamless-migration=on' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3,free-page-reporting=on' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:614434bd2755' -device 'virtio-scsi-pci,id=virtioscsi0,bus=pci.3,addr=0x1,iothread=iothread-virtioscsi0' -drive 'file=/dev/zvol/rpool/data/vm-100-disk-0,if=none,id=drive-scsi0,format=raw,cache=none,aio=io_uring,detect-zeroes=on' -device 'scsi-hd,bus=virtioscsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100' -netdev 'type=tap,id=net0,ifname=tap100i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=6A:8F:AD:DB:4E:31,netdev=net0,bus=pci.0,addr=0x12,id=net0,rx_queue_size=1024,tx_queue_size=1024' -netdev 'type=tap,id=net5,ifname=tap100i5,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=AE:8A:AE:B7:00:91,netdev=net5,bus=pci.0,addr=0x17,id=net5,rx_queue_size=1024,tx_queue_size=1024' -machine 'type=pc+pve0'' failed: got timeout

If you don't get any actual errors and only this timeout, it's usually because there is not enough free memory to start the VM. Try starting it with 4GB instead (or even less) to check.

EDIT: It that's not it, then I don't know where to look as there are no error messages or clues (that I recognize).

 

[jacha]

If you don't get any actual errors and only this timeout, it's usually because there is not enough free memory to start the VM. Try starting it with 4GB instead (or even less) to check.

The machine has 32 gb free memory. But I tried to lower it to 8gb and it wont start on that.

 

[bryq]

Hi! It seems I have the same issue after upgrade to 7.4
I can't start any Linux VM on proxmox 7.4 (windows one starts as usual) All Linux machine goes to grub and probe all available slots - endless loop

root@proxmox:~# pveversion -v
proxmox-ve: 7.4-1 (running kernel: 5.15.102-1-pve)
pve-manager: 7.4-3 (running version: 7.4-3/9002ab8a)
pve-kernel-5.15: 7.3-3
pve-kernel-5.13: 7.1-9
pve-kernel-5.4: 6.4-11
pve-kernel-5.15.102-1-pve: 5.15.102-1
pve-kernel-5.15.85-1-pve: 5.15.85-1
pve-kernel-5.15.83-1-pve: 5.15.83-1
pve-kernel-5.15.74-1-pve: 5.15.74-1
pve-kernel-5.15.64-1-pve: 5.15.64-1
pve-kernel-5.15.60-1-pve: 5.15.60-1
pve-kernel-5.15.39-3-pve: 5.15.39-3
pve-kernel-5.15.39-1-pve: 5.15.39-1
pve-kernel-5.15.35-2-pve: 5.15.35-5
pve-kernel-5.13.19-6-pve: 5.13.19-15
pve-kernel-5.13.19-2-pve: 5.13.19-4
pve-kernel-5.4.157-1-pve: 5.4.157-1
pve-kernel-5.4.106-1-pve: 5.4.106-1
ceph-fuse: 15.2.15-pve1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: 0.8.36+pve2
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.4
libproxmox-backup-qemu0: 1.3.1-1
libproxmox-rs-perl: 0.2.1
libpve-access-control: 7.4-2
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.3-3
libpve-guest-common-perl: 4.2-4
libpve-http-server-perl: 4.2-1
libpve-rs-perl: 0.7.5
libpve-storage-perl: 7.4-2
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.2-2
lxcfs: 5.0.3-pve1
novnc-pve: 1.4.0-1
proxmox-backup-client: 2.3.3-1
proxmox-backup-file-restore: 2.3.3-1
proxmox-kernel-helper: 7.4-1
proxmox-mail-forward: 0.1.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-offline-mirror-helper: 0.5.1-1
proxmox-widget-toolkit: 3.6.3
pve-cluster: 7.3-3
pve-container: 4.4-3
pve-docs: 7.4-2
pve-edk2-firmware: 3.20221111-2
pve-firewall: 4.3-1
pve-firmware: 3.6-4
pve-ha-manager: 3.6.0
pve-i18n: 2.11-1
pve-qemu-kvm: 7.2.0-8
pve-xtermjs: 4.16.0-1
qemu-server: 7.4-2
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+3
vncterm: 1.7-1
zfsutils-linux: 2.1.9-pve1

(proxmox restarted)

All CTs boot and work OK.

I've installed fresh Debian 11 - no boot - just stopped on the "booting screen"
Boot loop for existing linux VMs
I've restored one VM from backup - the same boot loop.

I've installed proxmox 7.2 again on other ssd, restored VM from backup and... all work ok.
After upgrade this 7.2 to 7.4 all stop to work...


I've noticed that vm boot when KVM harware virtualisation is off but vms don't go to login prompt and boot again.

 

[fiona]

Let's move the discussion here from the announcement thread to not clutter it too much.
Unfortunately, I still wasn't able to reproduce the issue locally. I even changed the haos installer script to not use efitype=4m (which it seems to do nowadays) to better match your configuration.

What kind of CPU does your host have?

Hi! It seems I have the same issue after upgrade to 7.4
I can't start any Linux VM on proxmox 7.4 (windows one starts as usual) All Linux machine goes to grub and probe all available slots - endless loop

I've installed fresh Debian 11 - no boot - just stopped on the "booting screen"
Boot loop for existing linux VMs
I've restored one VM from backup - the same boot loop.

Could you also share the configuration of the Debian 11 VM?

 

[jacha]

Let's move the discussion here from the announcement thread to not clutter it too much.
Unfortunately, I still wasn't able to reproduce the issue locally. I even changed the haos installer script to not use efitype=4m (which it seems to do nowadays) to better match your configuration.

What kind of CPU does your host have?



Could you also share the configuration of the Debian 11 VM?

After further testing, it seems I have found a culprit.
When I reconfigure my vm's network devices to all be on the same vmbr, the vm starts up without further problems.
setting it back to using multiple different vmbr eg vmbr0, vmbr1 again, makes the vm unbootable.
Regards Jacha

 

[bryq]

Let's move the discussion here from the announcement thread to not clutter it too much.
Unfortunately, I still wasn't able to reproduce the issue locally. I even changed the haos installer script to not use efitype=4m (which it seems to do nowadays) to better match your configuration.

What kind of CPU does your host have?



Could you also share the configuration of the Debian 11 VM?

Host: Dell Wyse Z90D7 Zx0 AMD G-T56N 16GB ram
Unfortunetly I've deleted Deb11 VM but I'm installing it again now. I let you know when it is ready.


OK I got it.
pve-edk2-firmware=3.20220526-1: booting and works
new pve: stuck at the boot grub screen

root@proxmox:~# qm config 108
balloon: 512
boot: order=scsi0;ide2;net0
cores: 1
ide2: backupVM1:iso/debian-11.6.0-amd64-netinst.iso,media=cdrom,size=388M
memory: 1024
meta: creation-qemu=7.2.0,ctime=1679916099
net0: virtio=56:99:40:59:32:BD,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: backupVM1:108/vm-108-disk-0.qcow2,iothread=1,size=32G
scsihw: virtio-scsi-single
smbios1: uuid=4207284f-0837-4fde-9eae-700f9db72648
sockets: 1
vmgenid: 9593e9ab-cddf-4335-a081-f62a37779c02

 

[fiona]

Host: Dell Wyse Z90D7 Zx0 AMD G-T56N 16GB ram
Unfortunetly I've deleted Deb11 VM but I'm installing it again now. I let you know when it is ready.


OK I got it.
pve-edk2-firmware=3.20220526-1: booting and works
new pve: stuck at the boot grub screen

Thank you for testing! Will try again to reproduce it. But the VM below is not even using OVMF to boot, so AFAIK, pve-edk2-firmware should be completely irrelevant. That is very strange. Are you sure it really depends on that package or did you change anything else? Is it maybe only stuck the first time you try to boot it even if you don't change anything in between?

root@proxmox:~# qm config 108
balloon: 512
boot: order=scsi0;ide2;net0
cores: 1
ide2: backupVM1:iso/debian-11.6.0-amd64-netinst.iso,media=cdrom,size=388M
memory: 1024
meta: creation-qemu=7.2.0,ctime=1679916099
net0: virtio=56:99:40:59:32:BD,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: backupVM1:108/vm-108-disk-0.qcow2,iothread=1,size=32G
scsihw: virtio-scsi-single
smbios1: uuid=4207284f-0837-4fde-9eae-700f9db72648
sockets: 1
vmgenid: 9593e9ab-cddf-4335-a081-f62a37779c02

 

[bryq]

Thank you for testing! Will try again to reproduce it. But the VM below is not even using OVMF to boot, so AFAIK, pve-edk2-firmware should be completely irrelevant. That is very strange. Are you sure it really depends on that package or did you change anything else? Is it maybe only stuck the first time you try to boot it even if you don't change anything in between?

Yes you're right - no action between change pve edk. I recorded video, you can see it here: Youtube

 

[gruzdev]

Yes you're right - no action between change pve edk. I recorded video, you can see it here: Youtube

I also have a Dell Wyse Z90D7 Zx0 AMD G-T56N.
Same problem.

 

[gruzdev]

But after today's update, the web interface stopped running altogether. Ssh works, but vm do not start.

 

[bryq]

I've also noticed full cpu utilisation sinse 7.4 upgrade. All VMs down but host cpu almost 100%




When run:

systemctl restart systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

it seems get back to normal (with VM and CTs running):

 

[fiona]

I've also noticed full cpu utilisation sinse 7.4 upgrade. All VMs down but host cpu almost 100%

View attachment 48528
View attachment 48529

When run:

systemctl restart systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

it seems get back to normal (with VM and CTs running):

View attachment 48530

We had other reports in the past about udiskd using a lot of CPU: https://forum.proxmox.com/threads/udisksd-using-lots-of-cpu.62967/ It might not behave nicely in all situations and is not installed by default.

 

[fiona]

Yes you're right - no action between change pve edk. I recorded video, you can see it here: Youtube

In the video, you show the HomeAssistant VM. My question was about the Debian VM, because that one is not using OVMF.

I understood that there is some issue with your existing HomeAssistant VM and the new pve-edk2-firmware package. What version of HomeAssistant did you install back when you created the VM? Which version is currently installed in the VM?

 

[bryq]

In the video, you show the HomeAssistant VM. My question was about the Debian VM, because that one is not using OVMF.

I understood that there is some issue with your existing HomeAssistant VM and the new pve-edk2-firmware package. What version of HomeAssistant did you install back when you created the VM? Which version is currently installed in the VM?

HA is up to date.


I thing that it might be correlated with hardware platform (CPU?) - similar issue is reported by gruzdev - exactly the same platform.

 

[fiona]

I thing that it might be correlated with hardware platform (CPU?) - similar issue is reported by gruzdev - exactly the same platform.

If that is the case, it will be close to impossible for us to find out what the problem is. You could try to report the issue upstream, but to have a real chance, you would need to bisect for the offending commit (by building and testing with different versions of the source code yourself).

EDIT: But the Debian 11 issue will be yet a different one, because no OVMF is used.

 

[bryq]

If that is the case, it will be close to impossible for us to find out what the problem is. You could try to report the issue upstream, but to have a real chance, you would need to bisect for the offending commit (by building and testing with different versions of the source code yourself).

EDIT: But the Debian 11 issue will be yet a different one, because no OVMF is used.

Maybe I could provide any logs?

 

[fiona]

Maybe I could provide any logs?

Unfortunately, OVMF logs are not enabled in the release version.

What you could still try is re-create the EFI disk for the VM. Make sure you have a backup first! Or you could try if a fresh install of HomeAssistant works and move your data if that's the case.

 

[bryq]

Unfortunately, OVMF logs are not enabled in the release version.

What you could still try is re-create the EFI disk for the VM. Make sure you have a backup first! Or you could try if a fresh install of HomeAssistant works and move your data if that's the case.

As I said before, when fresh install it does not work.


One more try
when I hit esc while booting on pve-edk2-firmware=3.20220526-1 I go into 'bios' as below:

but on the new one (pve-edk2-firmware=3.20230228-1) I only get (screen freez):

 

[dml3334]

Hi.

I have exactly the same issu. I am trying to install HAOS 9.5 in a fresh pve 7.4-3 with the post-installation phase

bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/misc/post-pve-install.sh)"

answering yes to everything

and the script to actually install HAOS

bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/vm/haos-vm.sh)"

I cannot pass the GRUB screen. It





And, if I try to enter the OVMF Bios to disable the Secure Boot Option, as it is recommended in many places, just to try, I cannot enter the OVMF menu. I get the following screen, instead:




I have the package pve-edk2-firmware: 3.20230228-1 installed.

How can we solve this? Thanks!