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? > 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 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 : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
