Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
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 "s... 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
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
* 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 "s... 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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1918427
Title:
curtin: install flash-kernel in arm64 UEFI unexpected
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
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 "s... it's ok, just chill" mechanism. Maybe a FLASH_KERNEL_SKIP=1 environment variable? > 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. -dann > -- > You received this bug notification because you are a bug assignee. > https://bugs.launchpad.net/bugs/1918427 > > Title: > curtin: install flash-kernel in arm64 UEFI unexpected > > To manage notifications about this bug go to: > https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions > > Launchpad-Notification-Type: bug > Launchpad-Bug: product=cloud-images; status=Confirmed; importance=Undecided; > assignee=None; > Launchpad-Bug: distribution=ubuntu; sourcepackage=curtin; component=main; > status=Confirmed; importance=Undecided; assignee=None; > Launchpad-Bug: distribution=ubuntu; sourcepackage=linux; component=main; > status=In Progress; importance=Undecided; assignee=dann.fraz...@canonical.com; > Launchpad-Bug-Tags: patch > Launchpad-Bug-Information-Type: Public > Launchpad-Bug-Private: no > Launchpad-Bug-Security-Vulnerability: no > Launchpad-Bug-Commenters: crichton dannf raharper tjjh89017 ubuntu-kernel-bot > Launchpad-Bug-Reporter: Date Huang (tjjh89017) > Launchpad-Bug-Modifier: Ryan Harper (raharper) > Launchpad-Message-Rationale: Assignee > Launchpad-Message-For: dannf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918427 Title: curtin: install flash-kernel in arm64 UEFI unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
* 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. 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? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918427 Title: curtin: install flash-kernel in arm64 UEFI unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
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. -dann -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918427 Title: curtin: install flash-kernel in arm64 UEFI unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
* 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? > > 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918427 Title: curtin: install flash-kernel in arm64 UEFI unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
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, > > > > > > 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
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
On Thu, Mar 18, 2021 at 10:11 AM Ryan Harper <1918...@bugs.launchpad.net> wrote: > > * dann frazier <1918...@bugs.launchpad.net> [2021-03-17 20:40]: > > On Wed, Mar 17, 2021 at 4:56 PM Ryan Harper <1918...@bugs.launchpad.net> > > wrote: > > > > > > I still don't understand: > > > > > > 1) why does which not find flash-kernel if it's present in the ephemeral > > > image (meaning it will also be present in the target filesystem > > > 2) What is the problem with flash-kernel such that you need to > > > dpkg-divert it? > > > > > > Generally, we do not want to include paths to binaries; we install > > > Ubuntu and Centos, and possibly other distros which may not have the > > > same path to this tools so I would like to understand what's not working > > > to understand why we're hardcoding paths to binaries for dpkg-divert. > > > > In my POC patch, it is because we need to divert flash-kernel before > > it is installed, *just in case* it gets installed as a dependency of > > Is flash-kernel supposed to be in the cloud-image or not? I see no reason for it to be, and I would like to see it removed. For ARM virtual machines (which I consider, possibly incorrectly, the primary consumer of cloud images), the only standard way to boot the kernel-on-disk is booting in EFI mode w/ GRUB. > Is flash-kernel supposed to be in the target OS or not? GRUB should be installed on EFI systems. flash-kernel should be installed on non-EFI systems. It should be safe to install them both in either case, but one of them is going to be useless. > > some other package (in our case it happened due to a kernel Recommends > > relationship). We therefore can't use `which` to look up the path... > > unless we continue to always install f-k in the ephemeral for the sole > > purpose of looking up its path... but that seems to making assumptions > > as well - i.e. that the ephemeral OS has the same paths as the target > > OS. > > flash-kernel runs in the target OS; if it's installed in ephemeral > environment thats a by-product of obtaining tools needed but not present > in the ephemeral environment. > > curtin/deps.py runs to ensure the ephemeral environment has the needed > tools to create whatever storage configuration curtin supports. > > In the squashfs images which do not have a kernel already installed > curtin will install linux-image-generic to make *additional* kernel > modules which may not be in the initrd that maas produces available. > I'm not sure why the maas initrd doesn't yet have zfs kernel modules but > that's typically the driver of the linux-image-generic install. > > w.r.t the dep on flash-kernel, if that is only supposed to run in the > target image, then I agree we can remove lines 57-58 in > curtin/dep/__init.py and not install the package (though it may still > get pulled in via the kernel package install). OK, agreed. Maybe we start by just ripping that out. > > Later durting curthooks stage, curtin will query the *target* os in > install-missing-packages for expected packages needed in the target OS. > > Prior to installing packages in the target OS, curtin does attempt to > divert initramfs triggering tools to prevent generating the initramfs > more than once (this happens when we install a kernel package in the > target OS and either updates or other packages trigger initramfs > rebuilds). This is designed around the assumption that the initramfs > generation tool is present in the image but not tied to the kernel > pacakge. For Ubuntu this is initramfs-tools along with some arch > specific tools. flash-kernel is the tool used on arm for non-uefi boot. > > I see a couple of options but I think I'd like to understand: > > 1) when is flash-kernel required? Curtin current expects flash-kernel > to be needed when arch is arm and when booting non-uefi. Is this still > accurate? Yes. > 2) Is flash-kernel always installed in arm cloud images used by maas? Today it is, but I would like that to stop. > 3) Is flash-kernel installed by packages due to Recommends when it's not > needed? If so, are there packaging bugs that need fixing? Yes - the kernel. I've fixed that in hirsute (see my previous reply), and we should probably SRU back to earlier releases. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918427 Title: curtin: install flash-kernel in arm64 UEFI unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
* 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, > > > > 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. > 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 > > 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. > - 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. > > 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. Does that make sense? Ryan -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918427 Title: curtin: install flash-kernel in arm64 UEFI unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
* dann frazier <1918...@bugs.launchpad.net> [2021-03-17 20:40]: > On Wed, Mar 17, 2021 at 4:56 PM Ryan Harper <1918...@bugs.launchpad.net> > wrote: > > > > I still don't understand: > > > > 1) why does which not find flash-kernel if it's present in the ephemeral > > image (meaning it will also be present in the target filesystem > > 2) What is the problem with flash-kernel such that you need to dpkg-divert > > it? > > > > Generally, we do not want to include paths to binaries; we install > > Ubuntu and Centos, and possibly other distros which may not have the > > same path to this tools so I would like to understand what's not working > > to understand why we're hardcoding paths to binaries for dpkg-divert. > > In my POC patch, it is because we need to divert flash-kernel before > it is installed, *just in case* it gets installed as a dependency of Is flash-kernel supposed to be in the cloud-image or not? Is flash-kernel supposed to be in the target OS or not? > some other package (in our case it happened due to a kernel Recommends > relationship). We therefore can't use `which` to look up the path... > unless we continue to always install f-k in the ephemeral for the sole > purpose of looking up its path... but that seems to making assumptions > as well - i.e. that the ephemeral OS has the same paths as the target > OS. flash-kernel runs in the target OS; if it's installed in ephemeral environment thats a by-product of obtaining tools needed but not present in the ephemeral environment. curtin/deps.py runs to ensure the ephemeral environment has the needed tools to create whatever storage configuration curtin supports. In the squashfs images which do not have a kernel already installed curtin will install linux-image-generic to make *additional* kernel modules which may not be in the initrd that maas produces available. I'm not sure why the maas initrd doesn't yet have zfs kernel modules but that's typically the driver of the linux-image-generic install. w.r.t the dep on flash-kernel, if that is only supposed to run in the target image, then I agree we can remove lines 57-58 in curtin/dep/__init.py and not install the package (though it may still get pulled in via the kernel package install). Later durting curthooks stage, curtin will query the *target* os in install-missing-packages for expected packages needed in the target OS. Prior to installing packages in the target OS, curtin does attempt to divert initramfs triggering tools to prevent generating the initramfs more than once (this happens when we install a kernel package in the target OS and either updates or other packages trigger initramfs rebuilds). This is designed around the assumption that the initramfs generation tool is present in the image but not tied to the kernel pacakge. For Ubuntu this is initramfs-tools along with some arch specific tools. flash-kernel is the tool used on arm for non-uefi boot. I see a couple of options but I think I'd like to understand: 1) when is flash-kernel required? Curtin current expects flash-kernel to be needed when arch is arm and when booting non-uefi. Is this still accurate? 2) Is flash-kernel always installed in arm cloud images used by maas? 3) Is flash-kernel installed by packages due to Recommends when it's not needed? If so, are there packaging bugs that need fixing? Ryan -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918427 Title: curtin: install flash-kernel in arm64 UEFI unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
On Wed, Mar 17, 2021 at 9:10 PM Date Huang <1918...@bugs.launchpad.net> wrote: > > > In my POC patch, it is because we need to divert flash-kernel before > > it is installed, *just in case* it gets installed as a dependency of > > some other package (in our case it happened due to a kernel Recommends > > relationship). We therefore can't use `which` to look up the path... > > unless we continue to always install f-k in the ephemeral for the sole > > purpose of looking up its path... but that seems to making assumptions > > as well - i.e. that the ephemeral OS has the same paths as the target > > OS. > > Hi Dann > Maybe we can test my patch in #24 Date, I'm happy to regression test a candidate patch on the xgene/u-boot and non-xgene/uefi platforms we have once Ryan or some other curtin maintainer is OK with the approach. > Or we can try to install_kernel with --no-recommends to avoid installing > flash-kernel > and move install_missing_packages after install_kernel and > enable_update_initramfs? I think the kernel recommending flash-kernel if GRUB is already installed is just a bug which is now fixed in hirsute: https://kernel.ubuntu.com/git/ubuntu/ubuntu-hirsute.git/commit/?id=95325fff0a339a2365a12417a39234e143cc284e -dann -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918427 Title: curtin: install flash-kernel in arm64 UEFI unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
On Wed, Mar 17, 2021 at 4:56 PM Ryan Harper <1918...@bugs.launchpad.net> wrote: > > I still don't understand: > > 1) why does which not find flash-kernel if it's present in the ephemeral > image (meaning it will also be present in the target filesystem > 2) What is the problem with flash-kernel such that you need to dpkg-divert it? > > Generally, we do not want to include paths to binaries; we install > Ubuntu and Centos, and possibly other distros which may not have the > same path to this tools so I would like to understand what's not working > to understand why we're hardcoding paths to binaries for dpkg-divert. In my POC patch, it is because we need to divert flash-kernel before it is installed, *just in case* it gets installed as a dependency of some other package (in our case it happened due to a kernel Recommends relationship). We therefore can't use `which` to look up the path... unless we continue to always install f-k in the ephemeral for the sole purpose of looking up its path... but that seems to making assumptions as well - i.e. that the ephemeral OS has the same paths as the target OS. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918427 Title: curtin: install flash-kernel in arm64 UEFI unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
On Tue, Mar 16, 2021 at 10:05 AM Ryan Harper <1918...@bugs.launchpad.net> 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 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. 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 - the kernel should allow non-flash-kernel bootloaders to satisfy its recommends - 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. 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. -dann -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918427 Title: curtin: install flash-kernel in arm64 UEFI unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
Hi Dan, Could you summarize the problem with flash-kernel and this system? * dann frazier <1918...@bugs.launchpad.net> [2021-03-15 18:25]: > Attached is a patch for curtin that works for me, though it could use > some cleanup. It installs flash-kernel in the same place GRUB gets > installed for EFI-based systems, which seems like the appropriate place. > Before installint it, it diverts /usr/sbin/flash-kernel so that flash- > kernel's postinst doesn't try (and fail) to flash a kernel that isn't > yet installed. There's existing code in enable_update_initramfs() that > will undo this diversion. I suspect we should refactor > disable_update_initramfs() somehow instead of duplicating this code like > I've done here. Looking at the patch, it looks like you could instead modify _update_initramfs_tools() to only return flash-kernel in the case that it's needed rather than for all aarch64. Alternatively, enable/disable_update_initramfs could take a force boolean which would perform the operation whether the tool is present or not (though I don't know if dpkg-divert cares about the presence of the binary-to-be-diverted). > > I've tested this w/ a locally-hacked squash image that has flash-kernel > purged and a PPA kernel that allows grub-efi-arm64 to satisfy the > bootloader Recommends. On an EFI-based system, flash-kernel never gets > installed. On a Moonshot m400, flash-kernel gets installed as expected. > > Once curtin has been updated with a fix like this, and MAAS has been > refreshed to include it, I think we should then be able to remove flash- > kernel from the arm64 cloud images. What's the criteria for determining if a particular arm instance requires flash-kernel or not? Ryan -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918427 Title: curtin: install flash-kernel in arm64 UEFI unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected
On Fri, Mar 12, 2021 at 10:45 PM Date Huang <1918...@bugs.launchpad.net> wrote: > > After reading log in #14, and some code from cloud-init and maas > I still cannot find any code that will let cloud-init try to install > flash-kernel wtih zfsutils-linux. > and it seems the error because squashfs didn't have any kernel installed. > So `linux-version` cannot find any kernel version to pass to flash-kernel to > process postinst script. > `Can't find /boot/vmlinuz- (see /tmp/flash-kernel-no-kernel-error.log)` > $kvers is empty. I added some debugging and found that this is what causes flash-kernel to be installed: https://git.launchpad.net/curtin/tree/curtin/deps/__init__.py?h=21.2#n57 I'm not sure what the point of that is - it probably should be removed. > and as I know, squashfs only for temp utils? > It will create an environment for curtin to install real system into disk > Am I correct? Yes, the failure in comment #14 is occurring in what we call the "ephemeral image", which only exists in memory to install an OS to the disk. Though the same image is also what is written to the disk. > Do you have any custom cloud-init config for xgene? No -dann -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918427 Title: curtin: install flash-kernel in arm64 UEFI unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1918427/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
