[Merge] ~jibel/livecd-rootfs/+git/add_multi_layered_squashfses_support:ubuntu/master into livecd-rootfs:ubuntu/master

[Jean-Baptiste Lallement]

> Thanks for the comments. I think this is basically fine now but I wanted to
> cover two slightly related things that I realize I've had in my head without
> being at all explicit about:
> 
> The first is kernel/initrd handling.
> 
> I guess for desktop you want to have the (possibly HWE, once we get to
> 20.04.2) kernel and vanilla initrd in the root layer, which curtin will copy
> onto the installed system. But the initrd that will be booted for installation
> will need to be casperized. In my understanding of how things work, this means
> that casper will be installed by lb_chroot_live-packages into any pass in
> LIVE_PASSES and then the initrd and vmlinu? will be copied out by
> lb_binary_linux-image into binary/casper and then auto/build moves them from
> there to somewhere launchpad-buildd will find them. I *think* this means that
> the squashfs for the live layer will contain the initrd but that's just a
> waste of space. (I don't know if something somewhere removes it before the
> squashfs gets made. It's certainly possible.)
> 

As an optimization and in order to save some space the initrd on the live layer could indeed be removed after having been copied by lb_chroot_live-package. That would save around 30MB of space on the image.

> For the live-server installer, we need the user to be boot either the GA or
[...]
> 
> Does that make any sense? I guess I mostly wrote it for myself in the end...
> 

Indeed, in this use case, you will have two LIVE_PASSES with the content you describe and Casper pointing to the live pass you want at boot (via ISOLINUX). We can automate the removal of initrd and vmlinuz for all LIVE_PASSES as they won’t be used in the finale ISO.
The specific tweaks for multi-kernel-modules and custom init scripts would indeed land in the world of binary hook.


> The other thing is that in very general terms I want to move towards a world
> were we don't actually use live-build. We use a very small part of it and
> frankly all it adds is confusion. Now this is obviously a long term thing and
> possibly not going to happen. But something we can do is to stop drinking its
> kool-aid right now :) So rather than, say, calling lb_chroot_live-packages,
> I'd rather we just, well, installed casper. Rather than calling
> lb_chroot_hacks (and having strange gyrations around stage files), we should
> just call update-initramfs when appropriate (this would make it much easier to
> implement your idea of always diverting update-initramfs and calling it one
> for each layer if the diverted one ran afterwards).. Rather than calling
> lb_binary_linux-image and then figuring out where *that* hid the vmlinu? and
> initrd, why not just move them where we want them directly. Etc.

I think rewriting live-build is outside of the scope of this MP. We try to ensure that the multi-layer and mono-layer builds are as close from each other as possible to avoid unexpected side-effects (unseen diverging behaviours).
A rewrite would rather include all pieces used to build an ISO, meaning livecd-rootfs, live-build, debian-cd and ubuntu-cdimage, which are all intertwined, require a local archive on disk and such. So, a way bigger scope than this MP.

-- 
https://code.launchpad.net/~jibel/livecd-rootfs/+git/add_multi_layered_squashfses_support/+merge/360878
Your team Ubuntu Core Development Team is subscribed to branch livecd-rootfs:ubuntu/master.