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

If done so in a chroot that exposes the kernel interfaces (/proc &
/sys) that claim to be hardware that requires the initramfs to be
post-processed, yes.
I suppose f-k could be taught to detect it is in a chroot, but then
again - depending on what you are building the chroot for - you may
want that post-processing.

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

oh, you're right. I mistakenly thought it was calling
get_flash_kernel_pkgs(), which returns nothing if EFI is detected.

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

Great!

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

+1, as that appears to be where we install bootloadery things, and
that's how I categorize f-k.

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

I don't think it should - we should SRU Date's f-k change and the
kernel Recommends change. Are there other packaging issues you've
identified?

> Does that make sense?

+1

  -dann