flash-kernel breaks when locally built RPI kernels are installed.

[satmandu]

I have been repackaging the Raspberry Pi Foundation's official kernels for some time with this script:

https://gist.github.com/satmandu/a507c59d84737f6d29ff353395819d51

I could always install these kernels before and have flash-kernel not break.

The updates to flash-kernel in lunar cause it to fail, with a "dpkg-query: no packages found matching" message.

What's the best way to handle this? The kernel packages always end up built with naming such as linux-headers-6.1.20-v8+_all.deb and linux-image-6.1.20-v8+_arm64.deb.

I use this in /etc/flash-kernel/db:
# To override fields include the Machine field and the fields you wish to
# override.
#
# e.g. to override Boot-Device on the Dreamplug to sdb rather than sda
#
#Machine: Globalscale Technologies Dreamplug
#Boot-Device: /dev/sdb1
Machine: Raspberry Pi 4 Model B
Machine: Raspberry Pi 4 Model B Rev 1.1
Machine: Raspberry Pi 4 Model B Rev 1.2
Machine: Raspberry Pi 4 Model B Rev 1.4
Machine: Raspberry Pi Compute Module 4 Rev 1.0
Machine: Raspberry Pi 400 Rev 1.0
Machine: Raspberry Pi 400 Rev 1.1
Machine: Raspberry Pi *
Kernel-Flavors: any
#Method: pi
#DTB-Id: bcm2711-rpi-4-b.dtb
#U-Boot-Script-Name: bootscr.rpi
#Required-Packages: u-boot-tools

ProblemType: Bug
DistroRelease: Ubuntu 23.04
Package: flash-kernel 3.106ubuntu14
Uname: Linux 6.1.20-v8+ aarch64
ApportVersion: 2.26.0-0ubuntu2
Architecture: arm64
CasperMD5CheckResult: unknown
Date: Fri Mar 24 11:55:21 2023
ImageMediaBuild: 20211013
ProcEnviron:
 LANG=C.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=screen.xterm-256color
 XDG_RUNTIME_DIR=<set>
SourcePackage: flash-kernel
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.flash-kernel.db: 2022-03-29T10:53:48.654542

[satmandu (satadru-umich)]

This is the message I am seeing:

Setting up flash-kernel (3.106ubuntu14) ...
Using DTB: bcm2711-rpi-4-b.dtb
flash-kernel: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.142ubuntu1) ...
Processing triggers for flash-kernel (3.106ubuntu14) ...
Using DTB: bcm2711-rpi-4-b.dtb
Installing /etc/flash-kernel/dtbs/bcm2711-rpi-4-b.dtb into /boot/dtbs/6.1.20-v8+/./bcm2711-rpi-4-b.dtb
Taking backup of bcm2711-rpi-4-b.dtb.
Installing new bcm2711-rpi-4-b.dtb.
dpkg-query: no packages found matching
dpkg: error processing package flash-kernel (--configure):
 installed flash-kernel package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 flash-kernel
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

[Heinrich Schuchardt (xypron)]

Thank you for reporting the problem.

For analysis your script looks a bit complicated.

Starting from a Ubuntu Lunar preinstalled image:

- add your /etc/flash-kernel/db
- for a single Linux kernel version run dpkg -i linux-image*v8+.deb linux-modules*v8+.deb

Does this work or fail?

Please, provide the full log.

Best regards

Heinrich

[satmandu (satadru-umich)]

Typescript log attached of running the install steps on a fresh lunar image.

[satmandu (satadru-umich)]

Is there anything else I can do to help debug this?

[satmandu (satadru-umich)]

The problem is I suspect this change to the functions file between flash-kernel_3.106ubuntu8.1 and flash-kernel_3.106ubuntu14, as this is where the "dpkg-query: no packages found matching" error comes from.

+get_kernel_status() {
+ # get_kernel_status(query_ver)
+ # return the dpkg package status of kernel version $query_ver
+ local query_ver="$1"
+ local ver path pkg
+ linux-version list --paths | while read -r ver path; do
+ if linux-version compare "$ver" eq "$query_ver"; then
+ pkg=$(
+ LANG=C.UTF-8 dpkg-query --search "$path" 2>/dev/null |
+ awk -F ": " -v path="$path" '$2==path { print $1; }'
+ )
+ LANG=C.UTF-8 dpkg-query --show --showformat '${db:Status-Status}' "$pkg"
+ break
+ fi
+ done
+}
+

I will debug more, but this is what I see:
linux-version list --paths | while read -r ver path; do echo $ver $path ; done
6.1.12-v8+ /boot/vmlinuz-6.1.12-v8+
6.1.13-v8+ /boot/vmlinuz-6.1.13-v8+
6.1.14-v8+ /boot/vmlinuz-6.1.14-v8+
6.1.16-v8+ /boot/vmlinuz-6.1.16-v8+
6.1.19-v8+ /boot/vmlinuz-6.1.19-v8+
6.1.20-v8+ /boot/vmlinuz-6.1.20-v8+
6.1.21-v8+ /boot/vmlinuz-6.1.21-v8+
6.1.23-v8+ /boot/vmlinuz-6.1.23-v8+

[satmandu (satadru-umich)]

export path=/boot/vmlinuz-6.1.23-v8+
LANG=C.UTF-8 dpkg-query --search "$path"
dpkg-query: no path found matching pattern /boot/vmlinuz-6.1.23-v8+
ls /boot/vmlinuz-6.1.23-v8+
/boot/vmlinuz-6.1.23-v8+

Well there's the problem maybe... let me think about how to work around this...

[Dave Jones (waveform)]

@satmandu My apologies, I keep meaning to get back to this bug because I suspect you're absolutely correct and that my addition of get_kernel_status is to blame. Unfortunately I'm swamped with last minute release stuff at the moment, but I'll try and have another look once lunar's out!

[satmandu (satadru-umich)]

@waveform, sorry to bother late in the release calendar. It isn't urgent, I'm just trying to work around it on my end, but I can manually downgrade the function file until this is addressed cleanly.

This issue is due to my changing of a file path in the DEBIAN/postinst hook portion of my kernel install:

version=$kver
image_path=/boot/vmlinuz-\$version

# Install kernel (This avoids an issue if /boot is fat32.)
mount -o remount,rw /boot 2>/dev/null || true
cp /usr/share/rpikernelhack/vmlinuz-"$kver" \$image_path

But this is due to a potentially fat32 boot partition not being supported for installs of files by dpkg.

It is explicitly suggested to use a postinst hook to install on such partitions here:

https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_the_filesystem_requirements_by_dpkg.3F

So ideally, the get_kernel_status function would handle dpkg-query not finding the kernel in the originally installed location.

[Launchpad Janitor (janitor)]

[Expired for flash-kernel (Ubuntu) because there has been no activity for 60 days.]

[satmandu (satadru-umich)]

@waveform is it fair to say that 3.107ubuntu1 resolves this issue?

[satmandu (satadru-umich)]

This appears to still be an issue in 3.107ubuntu1...

[satmandu (satadru-umich)]

Downgrading to the lunar version of /usr/share/flash-kernel/functions allowed me to finish the upgrade to mantic from lunar.

[satmandu (satadru-umich)]

This is still an issue as of 2024-February-6...

Downgrading fixes the issue.

[Michał Fita (michal.fita)]

One thing that bothers me regarding this report is that Kernels built for Raspbian don't need `flash-kernel` as they install themselves in right place, where their bootloader is capable to pick them up. So, if you're building from unmodified sources, you not only conflict with `flash-kernel`, but these packages probably do something in `/boot` directories that's not supported on FAT32 based `/boot` partition Debian/Ubuntu uses by default.

Your porting should remove Raspbian specific features from them, and port right method of `/boot` populating into the `flash-kernel`.

[satmandu (satadru-umich)]

I think that's a fair criticism. I'd note that the current bookworm-based Raspberry Pi OS now mounts the fat32 partition at /boot/firmware just like Ubuntu. Let me see if I can update my package build script to accommodate that.