Comment 31 for bug 1918427

* dann frazier <email address hidden> [2021-03-17 20:40]:
> On Wed, Mar 17, 2021 at 4:56 PM Ryan Harper <email address hidden> wrote:
> >
> > I still don't understand:
> >
> > 1) why does which not find flash-kernel if it's present in the ephemeral image (meaning it will also be present in the target filesystem
> > 2) What is the problem with flash-kernel such that you need to dpkg-divert it?
> >
> > Generally, we do not want to include paths to binaries; we install
> > Ubuntu and Centos, and possibly other distros which may not have the
> > same path to this tools so I would like to understand what's not working
> > to understand why we're hardcoding paths to binaries for dpkg-divert.
>
> In my POC patch, it is because we need to divert flash-kernel before
> it is installed, *just in case* it gets installed as a dependency of

Is flash-kernel supposed to be in the cloud-image or not?
Is flash-kernel supposed to be in the target OS or not?

> some other package (in our case it happened due to a kernel Recommends
> relationship). We therefore can't use `which` to look up the path...
> unless we continue to always install f-k in the ephemeral for the sole
> purpose of looking up its path... but that seems to making assumptions
> as well - i.e. that the ephemeral OS has the same paths as the target
> OS.

flash-kernel runs in the target OS; if it's installed in ephemeral
environment thats a by-product of obtaining tools needed but not present
in the ephemeral environment.

curtin/deps.py runs to ensure the ephemeral environment has the needed
tools to create whatever storage configuration curtin supports.

In the squashfs images which do not have a kernel already installed
curtin will install linux-image-generic to make *additional* kernel
modules which may not be in the initrd that maas produces available.
I'm not sure why the maas initrd doesn't yet have zfs kernel modules but
that's typically the driver of the linux-image-generic install.

w.r.t the dep on flash-kernel, if that is only supposed to run in the
target image, then I agree we can remove lines 57-58 in
curtin/dep/__init.py and not install the package (though it may still
get pulled in via the kernel package install).

Later durting curthooks stage, curtin will query the *target* os in
install-missing-packages for expected packages needed in the target OS.

Prior to installing packages in the target OS, curtin does attempt to
divert initramfs triggering tools to prevent generating the initramfs
more than once (this happens when we install a kernel package in the
target OS and either updates or other packages trigger initramfs
rebuilds). This is designed around the assumption that the initramfs
generation tool is present in the image but not tied to the kernel
pacakge. For Ubuntu this is initramfs-tools along with some arch
specific tools. flash-kernel is the tool used on arm for non-uefi boot.

I see a couple of options but I think I'd like to understand:

1) when is flash-kernel required? Curtin current expects flash-kernel
to be needed when arch is arm and when booting non-uefi. Is this still
accurate?

2) Is flash-kernel always installed in arm cloud images used by maas?

3) Is flash-kernel installed by packages due to Recommends when it's not
needed? If so, are there packaging bugs that need fixing?

Ryan