Public bug reported:

I wanted to request that ipxe-qemu-256k-compat inherits the MIR from ipxe where 
it was absed on.
Since we knew this will show up we prepared (but were unable to open a bug 
until the new queue was passed), thereby this MIR is a bit special and does not 
hold the usual template.

- IPXE (among other things) generates roms which are used by qemu
- The size of these roms changed, and to get migrations working we need a 
compat package containing some old roms (details see

- src:ipxe will contain the newest version as usual (in Main already, a merge 
to new version is prepared for Bionic)
- there will be a copy+rename+reduce-content of the older src:ipxe uploaded 
under a new name being src:qemu-256k-compat
     - this is what will go to new queue and then needs an ack to go in main 
- This should be no (significant) extra effort for you because
     - the source of src:qemu-256k-compat is identical to the src:ipxe package
     - both are needed until any pre-Bionic is out of support
     - so we support this very same code for the same time anyway

Around that a few discussions that I want to document here:
# Discussion 1 - tyhicks
> Just to be sure that I'm clear, we'll have two copies of the same
> version of the IPXE source. In the case of a vulnerability in IPXE,
> we'll need to fix it in both source packages?

In case of a vulnerability in the src in xenial you'll have to fix:
- src:ipxe in xenial-artful
- src:ipxe-256k-compat in Bionic and later (same change as it is the same 

> Will there only be two IPXE source packages in Bionic? In other words,
> will you drop src:qemu-256k-compat in Bionic+1?

We can drop src:ipxe-256k-compat when we drop Xenial.
Since it is the same source and the same time of support that should
be small amount of extra work.

#Discussion 2 - sarnold

[...] This went on for a while discussing alternatives at what point we
can drop the new -compat src package. It ended with Seth Concluding

I think VM migrations are different enough from release upgrades that
it's fair to consider them seperately.

We documented that we allow VM migration from LTS to LTS+2 on -- it sounds
like this decision was made with due deliberation, so I don't want to
disrupt it without good reason.

Is it a realistic upgrade path for a private cloud running one LTS to
install new LTS+2 nodes and skip LTS+1? What does upgrading a private
cloud look like? A "small" cloud with just libvirt and virsh could
certainly be upgraded this way. Having to install an LTS+1 compute node
just to migrate through on the way to LTS+2 compute nodes feels like an
arbitrary and artificial limitation.

Duplicating these ipxe roms in 18.04 LTS *and* 20.04 LTS is unfortunate.
But the gain in flexibility may outweigh the maintainance costs. In any
event we don't have to make a final decision on 20.04 LTS until 2020.

At this point I think I'm on board with the duplicate source packages.

** Affects: ipxe-qemu-256k-compat (Ubuntu)
     Importance: High
         Status: Fix Committed

You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

  [MIR] ipxe-qemu-256k-compat

To manage notifications about this bug go to:

ubuntu-bugs mailing list

Reply via email to