[SRU] [HWE] Backport efibootmgr 0.12-4 to 15.04

[Mathieu Trudel-Lapierre]

[Impact]
Shipping fwupdate in 15.04 (hardware enablement tool; a firmware updater tool) requires the use of efivar > 0.16; which in turn requires a slightly newer version of efibootmgr (at least 0.12-2).

[Test Case]
- Install libefivar0.

Installing libefivar0 will attempt to remove efibootmgr, which is quite unhelpful when one has to deal with EFI boot entries. Furthermore, efibootmgr is a Dependency of grub EFI images, of which the removal would likely be catastrophic to booting the system.

[Regression Potential]
Issues in efibootmgr would show up as the inability to configure new (or modify old) EFI boot entries; for example inability to install a boot image on some specific disks.

efibootmgr is critical to the proper function of grub updates for EFI systems.

[Steve Langasek (vorlon)]

This is a new upstream version of efibootmgr, which has implications well beyond the new version of fwupdate that this is intended to facilitate.

Why is the breaks against 0.12-2? (vs. 0.12-1) If there is a specific distro patch in 0.12-2, then I believe we should cherry-pick that patch into vivid efibootmgr if possible, and adjust the breaks on the version of efibootmgr in vivid. If that isn't possible (because the patch doesn't cherry-pick cleanly) we will need more detailed analysis of the upstream changes between 0.11.0 and 0.12 to confirm that these are sufficently low-risk.

[Mathieu Trudel-Lapierre (cyphermox)]

I verified this and it doesn't look like there is a good reason for the Breaks against efibootmgr (and it appears to work fine in vivid with the efivar update applied). Let's not SRU this at all.

[Jared Dominguez (jared-dominguez)]

Hi, I maintain efibootmgr/efivar in Debian.

Ubuntu 14.04's efibootmgr (0.5.4-7ubuntu1) doesn't even use efivar, so you don't need to worry about dependencies there.

If you're concerned about 15.04's efibootmgr (0.11.0-3), then you'll need to observe the restrictions in efibootmgr's debian/control as efibootmgr started depending on libefivar as of efibootmgr version 0.7.0-1. There are API changes in efivar that require that both packages be updated together (around efibootmgr 0.11 - 0.12 IIRC). This is well documented in the debian/changelogs for the respective packages as well as the git history on Alioth.

As far as the efivar version dependency change in efibootmgr 0.12-2, it has to do with the SONAME version format changing in efivar 0.20-2. This is mentioned in the debian/changelog for efibootmgr 0.12-2 and the git history on Alioth.

[Steve Langasek (vorlon)]

Hi Jared,

On Wed, Nov 04, 2015 at 12:49:19AM -0000, Jared Dominguez wrote:
> Hi, I maintain efibootmgr/efivar in Debian.

> Ubuntu 14.04's efibootmgr (0.5.4-7ubuntu1) doesn't even use efivar, so
> you don't need to worry about dependencies there.

> If you're concerned about 15.04's efibootmgr (0.11.0-3), then you'll
> need to observe the restrictions in efibootmgr's debian/control as
> efibootmgr started depending on libefivar as of efibootmgr version
> 0.7.0-1. There are API changes in efivar that require that both packages
> be updated together (around efibootmgr 0.11 - 0.12 IIRC). This is well
> documented in the debian/changelogs for the respective packages as well
> as the git history on Alioth.

> As far as the efivar version dependency change in efibootmgr 0.12-2, it
> has to do with the SONAME version format changing in efivar 0.20-2. This
> is mentioned in the debian/changelog for efibootmgr 0.12-2 and the git
> history on Alioth.

We reviewed this, and while the filename in efivar has changed, I don't
believe it's accurate to say that the soname format has changed. Inspection
of the old and new binaries with 'objdump -p' shows that the soname in both
versions is libefivar.so.0, which is expected. Provided that there haven't
been any symbols dropped between the versions (which I haven't checked but
that will be picked up by the SRU test case if there are), this Breaks:
declaration appears to actually be superfluous.

If there are API changes that result in incompatibilities, we haven't been
able to identify them yet over the course of preparing this SRU.

[Jared Dominguez (jared-dominguez)]

https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=uefi/efivar.git;a=commitdiff;h=054a52e338d460b4529b92fdd11aa07342d626ee

[Mario Limonciello (superm1)]

Given this never happened before 15.04's EOL date, closing this issue.
http://fridge.ubuntu.com/2016/01/14/ubuntu-15-04-vivid-vervet-reaches-end-of-life-on-february-4-2016/