* dann frazier <email address hidden> [2021-03-17 20:30]:
> On Tue, Mar 16, 2021 at 10:05 AM Ryan Harper <email address hidden> wrote:
> >
> > Hi Dan,
> >
> > Could you summarize the problem with flash-kernel and this system?
> 
> Sure. flash-kernel recognizes Mustang boards and will generate uImage
> and uInitrd files for it, which are required for booting with u-boot
> firmware. However, these boards can also run in UEFI mode, which
> Date's board does. In UEFI mode, flash-kernel still knows it is on a
> Mustang and generates uImage/uInitrd files - which won't be used for
> anything in that case, they are just wasting space, but does not cause
> it to fail. This does cause problems in a curtin install though.
> Curtin has logic to divert away tools that get executed during
> initramfs hooks, to avoid failures in packaging scripts before an
> initramfs is generated. flash-kernel in particular will fail if an
> initramfs is not found on this system. Curtin tries to be smart here
> and only divert flash-kernel 1) if it is installed and 2) on systems
> that are*not* in UEFI mode, and both of these scenarios have escapes:
> 
> 1) flash-kernel could get installed post-divert. In that case,
> flash-kernel's own postinst will cause it to run and then fail. This
> happens today if you start with a cloud image w/o flash-kernel
> pre-baked because Ubuntu's kernel recommends flash-kernel, causing it
> to be installed along with the kernel. Official cloud images happen to

Hrm, so if we take a squashfs rootfs (with no flash-kernel present)
chroot into it and install the linux-image-generic package pulling in
flash-kernel this fails due to postinst of flash-kernel expecting
initramfs to already be generated?  This doesn't seem like a curtin bug.

> have flash-kernel pre-baked which avoids this issue. I think curtin
> should work whether or not the kernel recommends flash-kernel and
> whether or not curtin is pre-baked (in fact, I'd like for us to stop
> pre-baking it - the vast majoriy of ARM servers do not need it).

> 
> 2) If flash-kernel is installed, and curtin finds we're in UEFI mode,
> it chooses not to divert flash-kernel. flash-kernel will therefore run
> and fail on UEFI Mustangs.

I don't think that's true. The logic for disabling initramfs tools
always runs regardless of UEFI mode and arch.  See
curtin/commands/curthooks.py:builtin_curthooks() lines 1692- 1699

> 
> The way I've personally framed this issue is that Ubuntu should not be
> trying to install flash-kernel on ARM systems that don't require it,
> which is the reason I've added the various tasks here.
>  - cloud images shouldn't prebake it

OK

>  - the kernel should allow non-flash-kernel bootloaders to satisfy its
> recommends

OK

Thanks.  I replied to your later post without seeing this first.
This helps a lot.

>  - curtin shouldn't install flash-kernel on efi-based arm64 servers.
> It does this today, but - in what seems like a bug, only in the
> ephemeral and not the target.

Yeah; I suspect flash-kernel being pre-baked into images hid this for
some time.  As I mentioned in the other reply, I do think that lines
57-58 in curtin/deps/__init__.py which bring in flash-kerenl to the
epheramal can be removed.  And it sounds like we'd move that logic
instead to the install-missing-packages arch_packages where we ensure
s390-tools/zipl are install for s390, there we'd add the same logic to
append flash-kernel where needed for the target OS.


> 
> A separate issue is that flash-kernel should know to just exit if it's
> running on an EFI system and not bother creating the unused
> uImage/uInitrd - Date recently got a patched merged into Debian's f-k
> to do that. That would seemingly also avoid the curtin issues here,
> but only if we continue to install flash-kernel all the time.

OK.


In summary curtin will need:

move ephemeral deps.py flash-kernel to arch-packages in
install-missing-packages with the same logic guarding when to add the
dep.

It's not clear to me why curtin should work around the packaging bugs
around flash-kernel and I would suggest that flash-kernel be kept in the
cloud images until the packging deps/bugs around it are fixed.  Does
that make sense?

Ryan