I have multiple legacy VM's that do not boot on the latest version, but ran fine on a recent but previous version. V7.3-6
Previous Version: V7.2-3, same machine, booted and at login prompt.
They are identical machines, the newer server is restored from a backup. To check the backup I restored that to the old server and that still boots ok.
The problem seems to be that the newer 1.16 SeaBIOS seems to have forgotten how or can't be bothered to boot.
So after a lot of faff I tried 1.15 from the older machine and its not that, I successfully got it to start with that (see screen shot), but same issue.
I could not easily install 7.2-3 over the 7.3-6, although I'm pretty certain that would have worked, it would then mean that I might install a security update and then find my machines don't boot.
All the VM's that don't boot are all the same kernel - which is an antique.
The VM's do no not boot from a boot disk, rather kernel and initial ram disk and for that you don't specify a boot device, you do it via the arguments:
I checked that /mnt/pve/replica/boot/vmlinuz-2.6.24-23-server is accessible and that its md5sum matches that of the machine it does work on. I also checked that the disks are mountable and md5 those, but you don't need anything to boot the kernel. And it doesn't boot.
I have a bunch of others with different kernel versions on 7.3-6 and they are perfectly happy.
So it looks like something has got broken in the latest builds and its not SeaBIOS. If you want to reproduce all you'll need is the kernel and initram files.
I'd like to get to the bottom of it because it makes it hard for me to trust Proxmox updates if someday probably way after an update was installed my machines are unbootable, thats serious - especially if there isn't an easy way for me to uninstall the updates. Even Micro$oft let you do that, and you can have a snapshot for the whole OS.
Previous Version: V7.2-3, same machine, booted and at login prompt.
They are identical machines, the newer server is restored from a backup. To check the backup I restored that to the old server and that still boots ok.
The problem seems to be that the newer 1.16 SeaBIOS seems to have forgotten how or can't be bothered to boot.
So after a lot of faff I tried 1.15 from the older machine and its not that, I successfully got it to start with that (see screen shot), but same issue.
I could not easily install 7.2-3 over the 7.3-6, although I'm pretty certain that would have worked, it would then mean that I might install a security update and then find my machines don't boot.
All the VM's that don't boot are all the same kernel - which is an antique.
The VM's do no not boot from a boot disk, rather kernel and initial ram disk and for that you don't specify a boot device, you do it via the arguments:
INI:
root@proxmoxy3:~# cat /etc/pve/qemu-server/209.conf
acpi: 1
args: -kernel '/mnt/pve/replica/boot/vmlinuz-2.6.24-23-server' -initrd '/mnt/pve/replica/boot/initrd.img-2.6.24-23-server' -append 'root=/dev/vda ro console=tty1 console=ttyS0,115200 3'
boot:
cores: 4
memory: 2048
meta: creation-qemu=6.2.0,ctime=1677858262
name: mxy3
net0: rtl8139=0A:35:78:D1:4A:8B,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsihw: virtio-scsi-pci
serial0: socket
smbios1: uuid=aa53c672-223d-4db8-b25d-4b83d8d14938
sockets: 1
virtio0: local-zfs:vm-209-disk-0,iothread=1,size=2G
virtio1: local-zfs:vm-209-disk-1,size=1G
virtio2: local-zfs:vm-209-disk-2,size=4G
virtio3: local-zfs:vm-209-disk-3,iothread=1,size=2G
vmgenid: a1688554-f6b8-46cc-ac36-bbb7eaa3fc60I checked that /mnt/pve/replica/boot/vmlinuz-2.6.24-23-server is accessible and that its md5sum matches that of the machine it does work on. I also checked that the disks are mountable and md5 those, but you don't need anything to boot the kernel. And it doesn't boot.
I have a bunch of others with different kernel versions on 7.3-6 and they are perfectly happy.
So it looks like something has got broken in the latest builds and its not SeaBIOS. If you want to reproduce all you'll need is the kernel and initram files.
I'd like to get to the bottom of it because it makes it hard for me to trust Proxmox updates if someday probably way after an update was installed my machines are unbootable, thats serious - especially if there isn't an easy way for me to uninstall the updates. Even Micro$oft let you do that, and you can have a snapshot for the whole OS.
