On Fri, Mar 19, 2021 at 1:31 PM Ryan Harper <email address hidden> wrote:
>
> * dann frazier <email address hidden> [2021-03-19 12:16]:
> > On Fri, Mar 19, 2021 at 10:01 AM Ryan Harper <email address hidden> wrote:
> > >
> > > * dann frazier <email address hidden> [2021-03-18 16:30]:
> > > > On Thu, Mar 18, 2021 at 12:25 PM Ryan Harper <email address hidden> wrote:
> > > > >
> > > > > * dann frazier <email address hidden> [2021-03-18 12:11]:
> > > > > > 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,
> > > > > > > > >
> > > > > > > >
> > > > > > > > 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.
> > > > >
> > > > > Maybe I'm missing something but if I install linux-image-generic
> > > > > it populates /boot with vmlinuz-$version (and a few more things)
> > > > > and /lib/modules/$version  and the kernels postinst will invoke
> > > > > update-initramfs.  The /boot/initrd.img-$version is *generated* at
> > > > > that time during the kernel's postinstall
> > > > >
> > > > > Now, in the arm case IIUC, the kernel package has a dep on flash-kernel
> > > > > being present as it's "needed" to generate the initramfs ... so how can
> > > > > flash-kernel's postinst *fail* if it is the tool that's generating said
> > > > > initramfs file?
> > > >
> > > > What flash-kernel does is generate wrapped versions of *exisiting*
> > > > vmlinuz and initrd.img files. It doesn't generate those files, rather
> > > > post-processes them.
> > > > The kernel doesn't depend on flash-kernel, it just recommends it like
> > > > it does GRUB on x86.
> > >
> > > Yes, I get that but it still looks like a packaging bug if dpkg installs
> > > flash-kernel first and /boot is not populated with existing initrds; one
> > > could easily see this happen in a debootstrap.
> >
> > Given that a failure to produce a wrapped initrd could cause a system
> > to become unbootable, it does seem to me like a hard failure here is
> > warranted. But, perhaps we could provide a "shhhh... it's ok, just
> > chill" mechanism. Maybe a FLASH_KERNEL_SKIP=1 environment variable?
>
> Agreed but with the condition that the *input* is present.  If the
> initrd file has not yet been generated then another error from
> flash-kernel seems redundant, specifically in the case where if the
> kernel package is not yet installed (and maybe this is the reasonble
> check the post-inst can do) then it's *always* going to fail.

Sorry for the late reply.
Certainly it seems like flash-kernel should exit 0 if no kernel is
installed, you could be in a chroot/container/whatever. But I don't
know if it's safe to exit 0 if a kernel is installed but no initrd is
found. It could be that we're in the middle of an install w/ initrd
generation temporarily disabled. But it could also mean that a user
has installed a local unpackaged kernel and is trying to boot it
without an initrd (either intentionally, or they just forgot to
mkinitramfs). For some platforms, like xgene-uboot, flash-kernel knows
that the firmware boot script will error out if no initrd is present.
Should it not throw an error in that case?

It feels safer to do something explicit to prevent f-k from running
(diversion, envvar, etc) rather than relying on f-k to make
assumptions about its environment.

> Does flash-kernel hook into initramfs updates via the
> /etc/kernel/{pre,post}inst.d/flash-kernel ? like initramfs-tools does?

Yes it does.

> I suspect most of what flash-kernel does would be triggered via kernel
> postinst hooks.

True, kernel postinst hooks will also do the flashing, but I don't see
how it would help the case here.

> >
> > > Is the "liveness" of the chroot what's tripping up flash-kernel?  We
> > > currently run inside a chroot which mounts /dev /proc /run and /sys; we
> > > could drop those but it also seems reasonable to have flash-kernel not
> > > expect existing initrds?
> >
> > Certainly a non-live chroot can avoid this by leading f-k to believe
> > it does not recognize the system. In fact, ISTR bind mounting certain
> > files in build chroots to trick f-k into doing nothing.
>
> Interesting.  That may be another approach; though that would be a f-k
> specific mount for curtin to swallow when installing one package; we
> might not know it's getting installed (like as a Recommends with the
> linux-image-generic) so that might not be as useful.

Agreed, and I didn't mean that to sound like a recommendation, just
explaining how I recalled that the "liveness" of the chroot matters.

  -dann