* dann frazier <1918...@bugs.launchpad.net> [2021-03-19 12:16]: > 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?
Agreed but with the condition that the *input* is present. If the initrd file has not yet been generated then another error from flash-kernel seems redundant, specifically in the case where if the kernel package is not yet installed (and maybe this is the reasonble check the post-inst can do) then it's *always* going to fail. Does flash-kernel hook into initramfs updates via the /etc/kernel/{pre,post}inst.d/flash-kernel ? like initramfs-tools does? I suspect most of what flash-kernel does would be triggered via kernel postinst hooks. > > > 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. Interesting. That may be another approach; though that would be a f-k specific mount for curtin to swallow when installing one package; we might not know it's getting installed (like as a Recommends with the linux-image-generic) so that might not be as useful. -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs