s390x squashfs image should include s390-tools

[Joshua Powers]

I propose that the s390x cloud-images should contain the s390-tools package by default.

In working on the s390x testing for curtin we discovered that the s390-tools package was missing as we needed to be able to run zipl. After talking to xnox and cpaelzer it was suggested that this package should be in there should you want to do anything useful with a s390x as the package contains many utilities to interact and manage a system.

[Dan Watkins (oddbloke)]

So on investigation, we actually have the following issues:

- s390-tools is included in the qcow2 image, but is not in the manifest
- s390-tools is not included in the squashfs

I'm guessing you're hitting the latter, so I'm going to modify this to be about that.

[Dan Watkins (oddbloke)]

The specific issue here is that s390-tools is installed in live-build/ubuntu-cpc/hooks/032-disk-image.binary (which runs after the squashfs is generated). It should probably instead run in a chroot hook.

[Dan Watkins (oddbloke)]

xnox points out on IRC that we don't include grub et al in the squashfs for those architectures that use it, so including s390-tools might not be the right thing to do after all.

[Dimitri John Ledkov (xnox)]

s390-tools, and specifically zipl part of that package is a bootloader and only makes sense on images that are booted: e.g. for virtual machines and bare metal. It is kind of like e.g. grub2 in x86_64 world.

squashfs is used for containers.

on amd64, squashfs does not contain grub2, thus s390-tools should be installed just like other bootloaders are installed.

So no, s390-tools should not be installed in the squashfs, but instead installed just before zipl is called to make image/install bootable. How is grub2 installed in amd64 case in MAAS images?

[Dimitri John Ledkov (xnox)]

This appears to be already fixed by:
https://bugs.launchpad.net/curtin/+bug/1662346

http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/revision/460