do not bother with dependencies for the split as this is for a
non-supported use-case anyway and we can point users to this fact in
the known issues section of the upgrade notes
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Keep a static build of the last version we supported them (2023.02)
for backward compat in a new separate binary package.
We can make that optional with the next major release and handle
affected VMs in pve8to9.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by limiting the phys-bits to 46 instead of 47. On Ubuntu 18.04 with
kernel 4.15, using 47 leads to a strange issue where initialization of
VirtIO devices would fail.
Reported in the community forum:
https://forum.proxmox.com/threads/127410/
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
> Continue to allow bootloaders to execute memory allocated as
> EFI_LOADER_DATA until GRUB fixes are more generally available.
> (Closes: #1025656)
-- a0be41b75c
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Commit 4cb94f20b0 ("OvmfPkg/SmbiosPlatformDxe: use PcdFirmware*") in
the edk2 submodule made the switch from hard coded values for the
SMBIOS type 0 table to using those defined in the PCD (Platform
Configuration Database). But this changed the value for the vendor
from "EFI Development Kit II / OVMF" to "EDK II" and made version and
release date "unknown". This can cause problems for hardware keys[0],
and the missing date can make Windows unhappy[1].
The PCD information can be specified during build. For the vendor,
just revert to the hardcoded value from before. This should be enough
to resolve the issue in [0]. For version and date, use sensible values
gathered from the build variables. The date format is mm/dd/yyyy while
the version is free-form according to [2], section 7.1.
[0]: https://bugzilla.proxmox.com/show_bug.cgi?id=4625
[1]: https://edk2.groups.io/g/devel/message/100922
[2]: https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.2.0.pdf
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
It is not maintained anymore and got disabled by default in upstream
commit 57783adfb5 ("OvmfPkg: Change default to disable MptScsi and
PvScsi"). Re-enable it to preserve backwards compatibility in Proxmox
VE.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
this is mostly done to secure against a future change of the default
march that may come from the x86-64-v* microarchitecture level [0]
concept that is currently being developed and by some more bleeding
edge distros even already adopted.
[0]: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
commit 862ea6e836 ("OvmfPkg: change qemu default resolution to
1280x800") made our patch that changed it to 1024x768 obsolete.
Note that QEMU is planning to change their default from 1024x768 to
1280x800 in QEMU 7.0, so that's where that new value is coming from.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Among other thing this now ships OVMF code/vars with secureboot and
MS keys enrolled, allowing Win11 final to get installed and secure
boot support in general.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
