[pve-devel] [PATCH qemu-server] use pve-edk2-firmware to load ovmf

[Fabian Grünbichler]

On Wed, Mar 14, 2018 at 11:14:57AM +0100, Thomas Lamprecht wrote:
> 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.lamprecht at 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. 

seems like I forgot about this ;)

the only non-qemu reverse-depends on "ovmf" is "mkosi" which only has a
recommends, and which (at least at first glance) does not use the ovmf
images directly at all.

I think we could just drop the provides and conflicts in this case and
move the files accordingly - if Debian ever gets other packages
depending on OVMF we don't break them accidentally (especially since the
version scheme is different, potentially breaking versioned
dependencies), and the one that matters to us is provided by us anyway,
so the paths are fully under our control there as well.

but this is not a hard requirement at all, I just noticed it in passing