* dann frazier <[email protected]> [2021-03-19 12:16]:
> On Fri, Mar 19, 2021 at 10:01 AM Ryan Harper <[email protected]>
> wrote:
> >
> > * dann frazier <[email protected]> [2021-03-18 16:30]:
> > > On Thu, Mar 18, 2021 at 12:25 PM Ryan Harper <[email protected]>
> > > wrote:
> > > >
> > > > * dann frazier <[email protected]> [2021-03-18 12:11]:
> > > > > On Thu, Mar 18, 2021 at 10:25 AM Ryan Harper
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > * dann frazier <[email protected]> [2021-03-17 20:30]:
> > > > > > > On Tue, Mar 16, 2021 at 10:05 AM Ryan Harper
> > > > > > > <[email protected]> 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.
Does flash-kernel hook into initramfs updates via the
/etc/kernel/{pre,post}inst.d/flash-kernel ? like initramfs-tools does?
I suspect most of what flash-kernel does would be triggered via kernel
postinst hooks.
>
> > 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.
--
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:
In Progress
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 : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
