Comment 33 for bug 1918427

On Thu, Mar 18, 2021 at 10:11 AM Ryan Harper <email address hidden> wrote:
>
> * 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?

I see no reason for it to be, and I would like to see it removed. For
ARM virtual machines (which I consider, possibly incorrectly, the
primary consumer of cloud images), the only standard way to boot the
kernel-on-disk is booting in EFI mode w/ GRUB.

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

GRUB should be installed on EFI systems. flash-kernel should be
installed on non-EFI systems.
It should be safe to install them both in either case, but one of them
is going to be useless.

> > 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).

OK, agreed. Maybe we start by just ripping that out.

>
> 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?

Yes.

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

Today it is, but I would like that to stop.

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

Yes - the kernel. I've fixed that in hirsute (see my previous reply),
and we should probably SRU back to earlier releases.