Comment 35 for bug 1918427

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

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

I don't think possibly something flash-kernel related to the above
discussion but that may just be my own misinformation.