On Fri, Mar 19, 2021 at 1:31 PM Ryan Harper <1918...@bugs.launchpad.net> wrote:
>
> * dann frazier <1918...@bugs.launchpad.net> [2021-03-19 12:16]:
> > On Fri, Mar 19, 2021 at 10:01 AM Ryan Harper <1918...@bugs.launchpad.net>
> > wrote:
> > >
> > > * dann frazier <1918...@bugs.launchpad.net> [2021-03-18 16:30]:
> > > > On Thu, Mar 18, 2021 at 12:25 PM Ryan Harper
> > > > <1918...@bugs.launchpad.net> wrote:
> > > > >
> > > > > * dann frazier <1918...@bugs.launchpad.net> [2021-03-18 12:11]:
> > > > > > On Thu, Mar 18, 2021 at 10:25 AM Ryan Harper
> > > > > > <1918...@bugs.launchpad.net> wrote:
> > > > > > >
> > > > > > > * dann frazier <1918...@bugs.launchpad.net> [2021-03-17 20:30]:
> > > > > > > > On Tue, Mar 16, 2021 at 10:05 AM Ryan Harper
> > > > > > > > <1918...@bugs.launchpad.net> 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
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1918427
Title:
curtin: install flash-kernel in arm64 UEFI unexpected
Status in cloud-images:
Confirmed
Status in curtin package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Fix Released
Bug description:
I used APM Mustang which flash-kernel supported in u-boot mode.
But I used it with UEFI environment.
It will cause fatal error when I used ARM64 ubuntu live server ISO to install
system.
In code[1], this will not install `flash-kernel` for APM Mustang because of
UEFI.
So that means code[2] will not disable `flash-kernel` in target system, only
disable `update-initramfs`.
When curtin execute to `install_kernel` stage, code[3,4] will not install
`flash-kernel` either.
But in code[5], it will install `linux-generic`.
`linux-generic` has a long dependency tree and it will get `flash-kernel` in
Recommended field.
Apt by default will install Recommended package before kernel is installed.[6]
So it will still execute `zz-flash-kernel` and `flash-kernel` when installing
kernel.
But system didn't create any `initrd.img` ever because curtin disable
`update-initramfs` in code[2].
This will cause that `flash-kernel` cannot find `initrd.img.<kvers>` and fail
when installing it.
This issue didn't effect all ARM64 UEFI platform because `flash-kernel`
didn't support them and skip.[7]
I'm not sure which is best solution for this.
But I think we should apply PR-27 in `flash-kernel`[8] for enhancement and
fix curtin process with this patch both.
If we only apply PR-27, it should work fine as well because it will be
skipped when detecting UEFI
and install `flash-kernel` before `disable_update_initranfs` in ARM platform
without UEFI.[9]
[Patch-1,2,3] might have side effect.
Picking one patch for curtin should be enough.
But I need your advice for this to determine which one is better for curtin.
There are two categories
1. avoid installing flash-kernel if no need, [Patch1,2]
2. always install flash-kernel in arm/arm64 and make sure it be installed
before code[2] [Patch3]
(I will attach patch in reply.)
Thanks a lot
Regards,
Date
[1]
https://github.com/canonical/curtin/blob/master/curtin/deps/__init__.py#L57-L58
[2]
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L1693-L1699
[3]
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L365-L370
[4]
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L311-L327
[5]
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L372-L374
[6] https://github.com/Debian/apt/blob/master/apt-pkg/init.cc#L132
[7]
https://salsa.debian.org/installer-team/flash-kernel/-/blob/master/functions#L787
[8] https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/27
[9] curtin will insert `flash-kernel` into `REQUIRED_EXECUTABLES` when system
is arm/arm64 without UEFI.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
