Package: ovmf
Version: 2022.11-6
Severity: important
Dear Maintainer,
After upgrading from Debian Bullseye to Debian Bookworm, existing HVM
DomUs using "firmware = 'ovmf'" (specifically Windows Server 2022 and
Windows 10) can't boot anymore. Booting these systems leads to the
Windows error 0xc0000225. I wasn't able to fix this error. Booting an
installation .iso leads to the same error. Booting the installation
media with "firmware = 'bios'" leads to a normal boot.
This seems to be the effect of a change in ovmf sources, where a xen
specific platform was created in 2019:
https://lore.kernel.org/all/20190813113119.14804-1-anthony.per...@citrix.com/#t
With some help I found a workaround. I could successfully start the
Windows DomU with ovmf firmware after removing the current ovmf package
and installing a previous ovmf package from Debian repositories,
specifically version 2020.11-2+deb11u1. This strongly indicates that the
cause of this issue lies in the ovmf package.
My HVM config file:
type = "hvm"
memory = 6144
vcpus = 2
name = "kalliope"
firmware = 'ovmf'
firmware = '/usr/local/lib/ovmf/OVMF.fd'
vif = ['bridge=xenbr0,mac=XX:XX:XX:XX:XX:XX,ip=10.0.0.4']
disk = ['phy:/dev/vg0/matrix,hda,w']
device_model_version = 'qemu-xen'
hdtype = 'ahci'
pae = 1
acpi = 1
apic = 1
vga = 'stdvga'
videoram = 16
xen_platform_pci = 1
vendor_device = 'xenserver'
viridian = 1
on_crash = 'restart'
device_model_args_hvm = [
# Debug OVMF
'-chardev', 'file,id=debugcon,path=/var/log/xen/ovmf.log,',
'-device', 'isa-debugcon,iobase=0x402,chardev=debugcon',
]
sdl = 0
serial = 'pty'
vnc = 1
vnclisten = "0.0.0.0"
vncpasswd = ""
As the Windows systems are not usable anymore, Xen is significantly
reduced in functionality after the upgrade.
There is a Debian bug report which could be related, I also described my
situation there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978595
This (or at least a very similar) issue seems to be fixed in
Redhat/Fedora. A related bug report exists in
https://bugzilla.redhat.com/show_bug.cgi?id=2170930
Additional information:
I also tried building Ovmf following
https://lore.kernel.org/all/20190813113119.14804-1-anthony.per...@citrix.com/#t
, but I wasn't fully able to create a working system:
(1) Using the resulting OVMF.fd from the build process with "firmware
='/path/to/new/OVMF.fd' led consistently to a black screen in VNC or
Spice with the text "Guest has not initialized the display (yet)".
(2) Replacing the OVMF.fd in /var/lib/ovmf with the freshly built
OVMF.fd led to a slight improvement. I could then boot the Windows
Server installation .iso, but booting the Windows 10 installation .iso
lead to a crash where the TianoCore logo was visible, but nothing
happened. The two existing DomUs were still no>
However, I am not sure that I followed the procedure correctly, I might
very well have done something very wrong. Any pointers are welcome.
Thanks,
Paul
-- System Information:
Debian Release: 12.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-11-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
