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