Merge lp://staging/~andreserl/maas-images/maas_images_signed_kernel into lp://staging/maas-images

Sorry if I was unclear - the "signed" package variants are amd64-only.

Thanks, this now looks correct.

Note that while this corrects the names odd of the packages that should be fed to curtin, the code which extracts the kernel for netbooting must also be checked to ensure it's using the right filename since these kernels provide vmlinuz.efi.signed instead of vmlinuz.

Thanks for pointing that out Steve. lp:maas-images looks for a file in /boot starting with the name vmlinuz[1]. Since the unsigned vmlinuz filename is shorter then the signed filename I suspect lp:maas-images will end up using the unsigned kernel. That will need to be fixed in order for MAAS to use a signed kernel in the ephemeral environment.

lp:maas-images will only generate a new image if a new image is posted upstream [2]. That being said is there any reason not to fix this for releases no longer supported?

[1] http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/meph2/netinst.py#L327
[2] http://cloud-images.ubuntu.com/daily/

On Fri, Nov 17, 2017 at 12:04:21AM -0000, Lee Trager wrote:

> lp:maas-images will only generate a new image if a new image is posted
> upstream [2]. That being said is there any reason not to fix this for
> releases no longer supported?

I don't think there's any reason not to fix it; I also don't see any
particular reason /to/ fix it for no-longer-supported releases.