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