Hi, Quoting Hans Heukenkamp (2026-11-02 11:47:18) > I can confirm this bug on a Cubietruck 3 (Allwinner A20, armhf) running > Debian 13 Trixie with a kernel from trixie-backports. > > **Affected packages:** > - flash-kernel 3.110~bpo13+1 > - linux-image-7.2.11+deb13-armmp-lpae 7.2.11-1~bpo13+1 > - initramfs-tools 0.148.4
you would usually provide this information using BTS control lines and I don't think it would be correct to mark packages like initramfs-tools to be affected by this problem. > During kernel installation, flash-kernel failed with: > > ``` > dpkg-query: no packages found matching > run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code > 1 > ``` > > The problem originates in `get_kernel_status()` in > `/usr/share/flash-kernel/functions`. You are so far just copying what I said in my original bug report. Do you intend to confirm what I said or am I missing any detail you wanted to add? > The function uses `dpkg-query --search` to identify the package owning > `/boot/vmlinuz-$version`. With the new split kernel packaging, this file is > no longer owned by a package. Instead, `linux-binary-7.2.11+deb13-armmp-lpae` > provides the kernel binary at: > > ``` > /usr/lib/modules/7.2.11+deb13-armmp-lpae/vmlinuz > ``` Yes, that's what my original report already said. Why do you repeat this? > I implemented a local workaround in `get_kernel_status()` that retains the > existing package lookup and falls back to `/usr/lib/modules/$ver/vmlinuz` if > the first lookup returns no package. Okay, what is your local workaround? Do you mind sharing your solution? Did you try out my patch? > > **Results:** > - `flash-kernel` completed successfully. > - `dpkg --configure -a` completed without errors. > - Both `flash-kernel` and `initramfs-tools` are fully configured. > - The regenerated `boot.scr` successfully booted Linux 7.2.11 on the > Cubietruck. > > The running kernel is now: > > ``` > Linux cubie 7.2.11+deb13-armmp-lpae #1 SMP Debian 7.2.11-1~bpo13+1 > (2026-10-18) armv7l GNU/Linux > ``` > > This confirms that the fallback lookup resolves the installation failure and > that the resulting kernel boots successfully on real armhf hardware. What "fallback lookup" are you talking about here? You didn't share what you actually changed and what led to a resolution of your problem. Am I talking to an LLM? cheers, josch
signature.asc
Description: signature
