On 03/14/2018 10:56 AM, Fabian Grünbichler wrote: > small nit below, I'll take a look at the edk2 package itself later > > On Tue, Mar 13, 2018 at 04:29:25PM +0100, Thomas Lamprecht wrote: >> We're able to just change it's path as we use the FD_SIZE_2MB option >> to build OVMF in the new pve-edk2-firmware package, which was the >> earlier implicit size of our current used OVMF BLOB. >> >> Incoming live migrations have their OVMF_CODE image in a RAMBlock[1], >> and only load the new image on a warm reboot, or, naturally, an full >> stop-start cycle. >> >> Signed-off-by: Thomas Lamprecht <t.lampre...@proxmox.com> >> --- >> >> If this would get applied already we need an version bump so that the >> pve-qemu 'Break: qemu-server (<= 5.0-23)' works. >> >> This can be seen as a RFC for now... >> >> PVE/QemuServer.pm | 4 ++-- >> debian/control | 1 + >> 2 files changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm >> index a26b2ab..2d27b74 100644 >> --- a/PVE/QemuServer.pm >> +++ b/PVE/QemuServer.pm >> @@ -38,8 +38,8 @@ use Time::HiRes qw(gettimeofday); >> use File::Copy qw(copy); >> use URI::Escape; >> >> -my $OVMF_CODE = '/usr/share/kvm/OVMF_CODE-pure-efi.fd'; >> -my $OVMF_VARS = '/usr/share/kvm/OVMF_VARS-pure-efi.fd'; >> +my $OVMF_CODE = '/usr/share/OVMF/OVMF_CODE.fd'; >> +my $OVMF_VARS = '/usr/share/OVMF/OVMF_VARS.fd'; > > /usr/share/pve-edk2-firmware please - the package is not called "OVMF" > after all ;) >
No, I conflict/provide OVMF and I used its exact paths, mirroring the Debian upstream packaging behaviour. If you dislike providing OVMF and act like a complete separate package, then yes, the path would need to be changed. _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
