Migrated QEMU VM failed to start because OVMF_CODE.4MB.fd was not found on Debian Bookworm

Incus
,
1

After migration to Incus from LXD via the lxd-to-incus tool, a VM failed to start up with the following error:

qemu-system-x86_64:/run/incus/XXX/qemu.conf:46: Could not open '/usr/share/OVMF/OVMF_CODE.4MB.fd': No such file or directory

The host system is Debian Bookworm, Incus was installed via Bookworm backports. I worked around the issue via (notice the slight difference ‘_’ vs ‘.’ in the filename):

ln -s /usr/share/OVMF/OVMF_CODE_4M.fd /usr/share/OVMF/OVMF_CODE.4MB.fd

I wonder if I could have fixed this more robust somewhere in the config of the VM?

2

One trick you could have used is to set security.csm=true and then unset it.
That should result in the firmware tracking for the instance to get reset.

2 Likes
3

I gave it a try and - not surprisingly :wink: - it does the job:

incus config set dobby security.csm=true
incus config set dobby security.csm=false

And afterwards the VM starts up fine without the symlink described above.

Thanks!

1 Like
4

The set unset helped me just now on Noble zabbly LTS ppa and incus 6.0.4 and today my qemu vm wouldn’t start with:

qemu-system-x86_64:/run/incus/c1/qemu.conf:46: Could not open '/usr/share/OVMF/OVMF_CODE_4M.ms.fd': Permission denied

Reporting this after a quick web research that this had been fixed in December?

5

My guess is that the fix only affects (=fixes) new installations?

6

No idea, incus has been running since last year with that VM, i did switch to zabbly ppa LTS last Month and had no problem until this Morning.

7

Ah right, when moving from the distro packages over to the Zabbly one, there’s a good chance that you need to go through:

  • incus stop NAME
  • incus config set NAME security.secureboot=false
  • incus config unset NAME security.secureboot
  • incus start NAME

Basically the reason for it is that each VM keeps a reference to what firmware was used to generate its NVRAM as switching firmware may lead to unreadable NVRAM causing firmware settings to be lost. The issue in your case is that the file that the firmware file the VM is looking for no longer exists on your system as that was the one provided by Debian’s ovmf/edk2 package which got removed when you switched over to the Zabbly package.

1 Like