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