curtin

Bug #1640519
Comment #4

Comment 4 for bug 1640519

Revision history for this message

Scott Moser (smoser) wrote on 2016-11-10:

The solution for this bug is:
a.) find the logic for when u-boot-tools should be installed and
implement that in curtin, and install u-boot-tools only when necessary.
It is possible that this is "all the time on armhf and arm64".
b.) remove u-boot-tools from maas-v2 images xenial+ (definitely zesty+)

Read on if you want more details.

If you install u-boot-tools in a system that does not use uboot to boot,
then update-initramfs will fail. update-initramfs is run by kernel
upgrade or other scenario. A workaround to that is setting a environment
variable FLASH_KERNEL_SKIP=true (or something like that) whenever you might run
update-initramfs. I personally think that is an unacceptable solution,
because effectively installation of u-boot-tools breaks your system if you
weren't using u-boot (unless you know the magic rune).

That is why 'flash-kernel' task is left open in bug
https://bugs.launchpad.net/maas-images/+bug/1337538
u-boot-tools or flash-kernel should do the right thing at runtime instead
of causing kernel upgrade failure.

I've marked the maas-images bug there as Fix-Released as we went ahead and
took the easy way out and installed u-boot-tools into the maas image as a
solution.

With xenial, though, we got rid of the specific "maas" images and made
them just re-packs of the cloud-image with the same content, and the
maas-v3 stream is actually using the squashfs image bit-for-bit.
Note, there are currently 2 differences in the maas-v2 image for xenial:
a.) maas image on arm has u-boot-tools (I had not realized that was still
the case, and this is true on both xenial and yakkety and zesty. We
should fix that by removing this package).
b.) in xenial, there is a symlink (LP: #1534205). It is no longer
necessary, but still present as we shipped with it. It can be removed,
but just takes careful verification.

To fix the failed install for bug 1640519 we are not able to install
u-boot-tools into the squashfs image that is used for lxc, as that would
mean users of a container would see failure on upgrade of some packages.

What we need to do is make curtin decide to install u-boot-tools in much
the same way as it decides to install grub-pc or grub-uefi. However, I'm
not sure exactly what logic is used to determine when you should install
that package. it is possible that its "always" on armhf or arm64, as that
seems to have worked before.

The solution for this bug is:
 a.) find the logic for when u-boot-tools should be installed and
     implement that in curtin, and install u-boot-tools only when necessary.
     It is possible that this is "all the time on armhf and arm64".
 b.) remove u-boot-tools from maas-v2 images xenial+ (definitely zesty+)

Read on if you want more details.

If you install u-boot-tools in a system that does not use uboot to boot,
then update-initramfs will fail.  update-initramfs is run by kernel
upgrade or other scenario.  A workaround to that is setting a environment
variable FLASH_KERNEL_SKIP=true (or something like that) whenever you might run
update-initramfs.  I personally think that is an unacceptable solution,
because effectively installation of u-boot-tools breaks your system if you
weren't using u-boot (unless you know the magic rune).

That is why 'flash-kernel' task is left open in bug
 https://bugs.launchpad.net/maas-images/+bug/1337538
u-boot-tools or flash-kernel should do the right thing at runtime instead
of causing kernel upgrade failure.

I've marked the maas-images bug there as Fix-Released as we went ahead and
took the easy way out and installed u-boot-tools into the maas image as a
solution.

With xenial, though, we got rid of the specific "maas" images and made
them just re-packs of the cloud-image with the same content, and the
maas-v3 stream is actually using the squashfs image bit-for-bit.
Note, there are currently 2 differences in the maas-v2 image for xenial:
 a.) maas image on arm has u-boot-tools (I had not realized that was still
the case, and this is true on both xenial and yakkety and zesty.  We
should fix that by removing this package).
 b.) in xenial, there is a symlink (LP: #1534205).  It is no longer
necessary, but still present as we shipped with it.  It can be removed,
but just takes careful verification.

What we need to do is make curtin decide to install u-boot-tools in much
the same way as it decides to install grub-pc or grub-uefi.  However, I'm
not sure exactly what logic is used to determine when you should install
that package.  it is possible that its "always" on armhf or arm64, as that
seems to have worked before.