On Thu, Mar 18, 2021 at 10:25 AM Ryan Harper <[email protected]> wrote: > > * dann frazier <[email protected]> [2021-03-17 20:30]: > > On Tue, Mar 16, 2021 at 10:05 AM Ryan Harper <[email protected]> > > 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 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? > Does that make sense? +1 -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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
