Bug#1102690: A higher version (...) is still installed, no reflashing required

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Johannes Schauer Marin Rodrigues (2025-04-25 08:00:44)
> I patched flash-kernel with the changes from this MR:
> https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/41
> 
> I can confirm that this patch stack fixes the problem that I had and which
> can be demonstrated with above reproducer. Thus, I'm tagging this bug with
> "patch".

we are now shipping flash-kernel patched with the commits from above MR in the
MNT Debian repository. All my tests so far of upgrading flash-kernel together
with the kernel have come back successful so far:

[...]
Setting up flash-kernel (3.109+reform20250425T080214Z1) ...
Using DTB: freescale/imx8mq-mnt-reform2.dtb
flash-kernel: deferring update (trigger activated)
[...]
Setting up linux-image-6.12.22-mnt-reform-arm64 
(6.12.22-1+reform20250425T080214Z) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.12.22-mnt-reform-arm64
Using DTB: freescale/imx8mq-mnt-reform2.dtb
Installing 
/usr/lib/linux-image-6.12.22-mnt-reform-arm64/freescale/imx8mq-mnt-reform2.dtb 
into /boot/dtbs/6.12.22-mnt-reform-arm64/freescale/imx8mq-mnt-reform2.dtb
Taking backup of imx8mq-mnt-reform2.dtb.
Installing new imx8mq-mnt-reform2.dtb.
flash-kernel: deferring update (trigger activated)
/etc/kernel/postinst.d/reform-qcacld2:
Starting background process to update reform-qcacld2 driver package (for Wi-Fi) 
to match kernel version.
/etc/kernel/postinst.d/zz-flash-kernel:
Using DTB: freescale/imx8mq-mnt-reform2.dtb
Installing 
/usr/lib/linux-image-6.12.22-mnt-reform-arm64/freescale/imx8mq-mnt-reform2.dtb 
into /boot/dtbs/6.12.22-mnt-reform-arm64/freescale/imx8mq-mnt-reform2.dtb
Taking backup of imx8mq-mnt-reform2.dtb.
Installing new imx8mq-mnt-reform2.dtb.
flash-kernel: deferring update (trigger activated)
[...]
Processing triggers for initramfs-tools (0.147) ...
update-initramfs: Generating /boot/initrd.img-6.13.11-mnt-reform-arm64
Using DTB: freescale/imx8mq-mnt-reform2.dtb
Installing 
/usr/lib/linux-image-6.13.11-mnt-reform-arm64/freescale/imx8mq-mnt-reform2.dtb 
into /boot/dtbs/6.13.11-mnt-reform-arm64/freescale/imx8mq-mnt-reform2.dtb
Taking backup of imx8mq-mnt-reform2.dtb.
Installing new imx8mq-mnt-reform2.dtb.
flash-kernel: installing version 6.13.11-mnt-reform-arm64
Generating boot script u-boot image... done.
Taking backup of boot.scr.
Installing new boot.scr.
Processing triggers for libc-bin (2.41-7) ...
Processing triggers for man-db (2.13.0-1) ...
Processing triggers for libglib2.0-0t64:arm64 (2.84.1-2) ...
No such key “scheme” in schema “org.gnome.gedit.preferences.editor” as 
specified in override file 
“/usr/share/glib-2.0/schemas/20_reform.gschema.override”; ignoring override for 
this key.
[...]
Processing triggers for flash-kernel (3.109+reform20250425T080214Z1) ...
Using DTB: freescale/imx8mq-mnt-reform2.dtb
Installing 
/usr/lib/linux-image-6.13.11-mnt-reform-arm64/freescale/imx8mq-mnt-reform2.dtb 
into /boot/dtbs/6.13.11-mnt-reform-arm64/freescale/imx8mq-mnt-reform2.dtb
Taking backup of imx8mq-mnt-reform2.dtb.
Installing new imx8mq-mnt-reform2.dtb.
flash-kernel: installing version 6.13.11-mnt-reform-arm64
Generating boot script u-boot image... done.
Taking backup of boot.scr.
Installing new boot.scr.

The above is how it's supposed to look like, right? And at the end,
flash-kernel runs and installs the correct kernel *even though* this
installation request had a different kernel in it. But, as expected, it
installs the highest installed version.

Success, right?

Thanks!

cheers, josch

signature.asc
Description: signature

Processed: Re: Bug#1102690: A higher version (...) is still installed, no reflashing required

[Debian Bug Tracking System]

Processing control commands:

> tag -1 + patch
Bug #1102690 [flash-kernel] A higher version (...) is still installed, no 
reflashing required
Added tag(s) patch.

-- 
1102690: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102690
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1102690: A higher version (...) is still installed, no reflashing required

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + patch

Quoting Johannes Schauer Marin Rodrigues (2025-04-13 23:28:32)
> It seems that, if flash-kernel gets upgraded together with the kernel, then
> flash-kernel is not run at the end of the installation and thus, the old
> kernel stays referenced in /boot/boot.scr. Steps to reproduce:
> 
> $ debvm-create -r unstable -- \
> http://snapshot.debian.org/archive/debian/20240401T00Z/ \
> --aptopt='Acquire::Check-Valid-Until "false"' \
> --dpkgopt=force-confold \
> --include flash-kernel,u-boot-tools \
> --setup-hook='mkdir -p "$1"/etc/flash-kernel' \
> --setup-hook='printf "Machine: linux,dummy-virt\nKernel-Flavors: 
> any\nBoot-Script-Path: /boot/boot.scr\nU-Boot-Script-Name: 
> bootscr.uboot-generic\nRequired-Packages: u-boot-tools\n" > 
> "$1"/etc/flash-kernel/db' \
> --setup-hook='echo linux,dummy-virt > "$1"/etc/flash-kernel/machine'
> [...]
> $ debv-run
> [...]
> root@testvm:~# echo "deb 
> http://snapshot.debian.org/archive/debian/20250401T00Z/ unstable main" >> 
> /etc/apt/sources.list && apt update && apt full-upgrade --yes
> [...]
> Setting up linux-image-6.12.21-cloud-arm64 (6.12.21-1) ...
> I: /vmlinuz is now a symlink to boot/vmlinuz-6.12.21-cloud-arm64
> I: /initrd.img is now a symlink to boot/initrd.img-6.12.21-cloud-arm64
> /etc/kernel/postinst.d/initramfs-tools:
> update-initramfs: Generating /boot/initrd.img-6.12.21-cloud-arm64
> W: No zstd in /usr/bin:/sbin:/bin, using gzip
> W: /sbin/fsck.ext4 doesn't exist, can't install to initramfs
> flash-kernel: deferring update (trigger activated)
> /etc/kernel/postinst.d/zz-flash-kernel:
> flash-kernel: deferring update (trigger activated)
> Setting up linux-image-cloud-arm64 (6.12.21-1) ...
> Setting up flash-kernel (3.108) ...
> debconf: unable to initialize frontend: Dialog
> debconf: (No usable dialog-like program is installed, so the dialog based 
> frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
> 79.)
> debconf: falling back to frontend: Readline
> debconf: unable to initialize frontend: Readline
> debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the 
> Term::ReadLine module) (@INC entries checked: /etc/perl 
> /usr/local/lib/aarch64-linux-gnu/perl/5.40.1 /usr/local/share/perl/5.40.1 
> /usr/lib/aarch64-linux-gnu/perl5/5.40 /usr/share/perl5 
> /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.40 
> /usr/share/perl/5.40 /usr/local/lib/site_perl) at 
> /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 8.)
> debconf: falling back to frontend: Teletype
> Setting up dmsetup (2:1.02.205-1) ...
> Setting up libdevmapper1.02.1:arm64 (2:1.02.205-1) ...
> Setting up libcryptsetup12:arm64 (2:2.7.5-1) ...
> Setting up systemd-cryptsetup (257.4-7) ...
> Processing triggers for debianutils (5.21) ...
> Processing triggers for libc-bin (2.41-6) ...
> Processing triggers for systemd (257.4-7) ...
> Processing triggers for initramfs-tools (0.147) ...
> update-initramfs: /boot/initrd.img-6.12.21-cloud-arm64 has already been 
> updated since Sun Apr 13 21:19:34 2025.
> root@testvm:~# grep -a 6.12.21 /boot/boot.scr
> root@testvm:~# grep -a 6.7.9 /boot/boot.scr
>setenv fk_kvers '6.7.9-cloud-arm64'
> 
> So bottom line: if I upgrade flash-kernel together with the kernel, then
> flash-kernel will not put the new kernel into /boot/boot.scr. This is of 
> course
> fatal when at the same time that the new kernel got installed the new kernel
> (the one still referenced by /boot/boot.scr) got removed.
> 
> I hope having this easily reproducible will help you figure out what's going
> on.

I patched flash-kernel with the changes from this MR:
https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/41

I can confirm that this patch stack fixes the problem that I had and which can
be demonstrated with above reproducer. Thus, I'm tagging this bug with "patch".

Can we merge that MR now? :)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1102690: A higher version (...) is still installed, no reflashing required

[Johannes Schauer Marin Rodrigues]

On 2025-04-22 05:29, Vagrant Cascadian wrote:

On 2025-04-12, Vagrant Cascadian wrote:

On 2025-04-12, Johannes Schauer Marin Rodrigues wrote:
Luckily, running flash-kernel manually fixed the issue. But had I not 
noticed
that /boot/boot.scr still contained a version of a kernel that I had 
just

removed, my system would've become unbootable.


Presuming this isn't some bizarre fluke, then this bug is likely 
present
in most versions of flash-kernel, as that code has not been touched 
for

at least a 2-5 years...

I vaguely recall a bug or merge request coming from Ubuntu that might 
be

related...


Does this by chance help at all:

  
https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/41


It is about partially installed kernels,


Is it? The LP issue says that it's about "if the kernel and flash-kernel 
packages are updated at the same time" or in the MR text "prevent 
flash-kernel from "missing" runs when both it and the kernel are 
upgraded in a single run of apt." -- that sounds *exactly* like the 
issue I observed.



but perhaps might fix this as a
side-effect?


I'm traveling today so I cannot test this right now. Luckily the 3 
commits apply cleanly on top of 3.109 so I'll later build myself a 
patched flash-kernel and see if this fixes the issue given my reproducer 
from earlier.


This is certainly worth looking into at some point ... although maybe a 
bit too large changeset during the bookworm freeze right now...


We are again deep into the freeze but it seems that Ubuntu has already 
tested these patches in Jammy. We can also give them more testing by 
adding them into the MNT repos on top of the patches with which we 
already are patching flash-kernel there.


Thanks!

cheers, josch

P.S.: I totally forgot to create a MR now that the dtb of my A311D 
Reform has been upstreamed: 
https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/68

Bug#1102690: A higher version (...) is still installed, no reflashing required

[Vagrant Cascadian]

On 2025-04-12, Vagrant Cascadian wrote:
> On 2025-04-12, Johannes Schauer Marin Rodrigues wrote:
>> Luckily, running flash-kernel manually fixed the issue. But had I not noticed
>> that /boot/boot.scr still contained a version of a kernel that I had just
>> removed, my system would've become unbootable.
>
> Presuming this isn't some bizarre fluke, then this bug is likely present
> in most versions of flash-kernel, as that code has not been touched for
> at least a 2-5 years...
>
> I vaguely recall a bug or merge request coming from Ubuntu that might be
> related...

Does this by chance help at all:

  https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/41

It is about partially installed kernels, but perhaps might fix this as a
side-effect?

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1102690: A higher version (...) is still installed, no reflashing required

[Johannes Schauer Marin Rodrigues]

Hi,

this problem is not MNT Reform-specific. I just reproduced it with
linux-image-cloud-arm64 in QEMU via debvm.

Quoting Johannes Schauer Marin Rodrigues (2025-04-13 08:46:21)
> > Presuming this isn't some bizarre fluke, then this bug is likely present in
> > most versions of flash-kernel, as that code has not been touched for at
> > least a 2-5 years...
> > 
> > I vaguely recall a bug or merge request coming from Ubuntu that might be
> > related...
> 
> I will try to reproduce this issue later using Debian kernels. My hunch is,
> that the problem is that a new kernel version got installed at the same time
> that flash-kernel got upgraded. Because at the time that 6.12.22 is installed,
> flash-kernel should have been run but instead we see this in the log:
> 
> flash-kernel: deferring update (trigger activated)
> 
> And then the only other flash-kernel related message is:
> 
> Setting up flash-kernel (3.109+reform1)
> 
> So maybe this is about the order of triggers? Instead of "deferring update",
> flash-kernel should've been run at the point of "Setting up
> linux-image-6.12.22", no?

It seems that, if flash-kernel gets upgraded together with the kernel, then
flash-kernel is not run at the end of the installation and thus, the old kernel
stays referenced in /boot/boot.scr. Steps to reproduce:

$ debvm-create -r unstable -- \
http://snapshot.debian.org/archive/debian/20240401T00Z/ \
--aptopt='Acquire::Check-Valid-Until "false"' \
--dpkgopt=force-confold \
--include flash-kernel,u-boot-tools \
--setup-hook='mkdir -p "$1"/etc/flash-kernel' \
--setup-hook='printf "Machine: linux,dummy-virt\nKernel-Flavors: 
any\nBoot-Script-Path: /boot/boot.scr\nU-Boot-Script-Name: 
bootscr.uboot-generic\nRequired-Packages: u-boot-tools\n" > 
"$1"/etc/flash-kernel/db' \
--setup-hook='echo linux,dummy-virt > "$1"/etc/flash-kernel/machine'
[...]
$ debv-run
[...]
root@testvm:~# echo "deb 
http://snapshot.debian.org/archive/debian/20250401T00Z/ unstable main" >> 
/etc/apt/sources.list && apt update && apt full-upgrade --yes
[...]
Setting up linux-image-6.12.21-cloud-arm64 (6.12.21-1) ...
I: /vmlinuz is now a symlink to boot/vmlinuz-6.12.21-cloud-arm64
I: /initrd.img is now a symlink to boot/initrd.img-6.12.21-cloud-arm64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.12.21-cloud-arm64
W: No zstd in /usr/bin:/sbin:/bin, using gzip
W: /sbin/fsck.ext4 doesn't exist, can't install to initramfs
flash-kernel: deferring update (trigger activated)
/etc/kernel/postinst.d/zz-flash-kernel:
flash-kernel: deferring update (trigger activated)
Setting up linux-image-cloud-arm64 (6.12.21-1) ...
Setting up flash-kernel (3.108) ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
79.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the 
Term::ReadLine module) (@INC entries checked: /etc/perl 
/usr/local/lib/aarch64-linux-gnu/perl/5.40.1 /usr/local/share/perl/5.40.1 
/usr/lib/aarch64-linux-gnu/perl5/5.40 /usr/share/perl5 
/usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.40 
/usr/share/perl/5.40 /usr/local/lib/site_perl) at 
/usr/share/perl5/Debconf/FrontEnd/Readline.pm line 8.)
debconf: falling back to frontend: Teletype
Setting up dmsetup (2:1.02.205-1) ...
Setting up libdevmapper1.02.1:arm64 (2:1.02.205-1) ...
Setting up libcryptsetup12:arm64 (2:2.7.5-1) ...
Setting up systemd-cryptsetup (257.4-7) ...
Processing triggers for debianutils (5.21) ...
Processing triggers for libc-bin (2.41-6) ...
Processing triggers for systemd (257.4-7) ...
Processing triggers for initramfs-tools (0.147) ...
update-initramfs: /boot/initrd.img-6.12.21-cloud-arm64 has already been updated 
since Sun Apr 13 21:19:34 2025.
root@testvm:~# grep -a 6.12.21 /boot/boot.scr
root@testvm:~# grep -a 6.7.9 /boot/boot.scr
   setenv fk_kvers '6.7.9-cloud-arm64'

So bottom line: if I upgrade flash-kernel together with the kernel, then
flash-kernel will not put the new kernel into /boot/boot.scr. This is of course
fatal when at the same time that the new kernel got installed the new kernel
(the one still referenced by /boot/boot.scr) got removed.

I hope having this easily reproducible will help you figure out what's going
on.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1102690: A higher version (...) is still installed, no reflashing required

[Johannes Schauer Marin Rodrigues]

Quoting Vagrant Cascadian (2025-04-13 05:42:01)
> On 2025-04-12, Johannes Schauer Marin Rodrigues wrote:
> > $ apt-cache policy linux-image-arm64
> > linux-image-arm64:
> >   Installed: 6.12.19-1+reform20250322T135019Z
> >   Candidate: 6.12.22-1+reform20250411T222458Z
> ...
> > $ sudo apt full-upgrade
> ...
> > Removing linux-headers-6.12.16-mnt-reform-arm64 
> > (6.12.16-1+reform20250219T175041Z) ...
> ...
> > flash-kernel: A higher version (6.12.19-mnt-reform-arm64) is still 
> > installed, no reflashing required.
> ...
> > Setting up linux-image-6.12.22-mnt-reform-arm64 
> > (6.12.22-1+reform20250411T222458Z) ...
> ...
> > Installing 
> > /usr/lib/linux-image-6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
> >  into 
> > /boot/dtbs/6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
> ...
> > Setting up flash-kernel (3.109+reform1) ...
> 
> So, at this point, you had 6.12.19 and 6.12.22 installed, 6.12.16 was
> removed ... and flash-kernel was just updated ... without re-running the
> flash-kernel scripts for 6.12.22 ... although the "Installing
> /usr/lib/linux-image-6.12.22...reform.dtb" was from (the older?)
> flash-kernel, no?

Oh wait, is this maybe tripping up flash-kernel? The "Installing
/usr/lib/linux-image-6.12.22...reform.dtb" messages come from the kernel hook
script of the reform-tools package (also in Debian main). That hook script
copies the dtbs of MNT platforms into /boot/dtbs/. This is necessary so that:

 - when you move your /boot to a different platform, it will already have the
   required dtbs in /boot
 - making the /boot partition bit-by-bit reproducible across system images for
   all the MNT SoMs

Is it possible that flash-kernel gets confused that there are already files in
/boot/dtbs/ that it did not install itself?


> > $ uname -a
> > Linux kodi 6.12.19-mnt-reform-arm64 #1 SMP Debian 
> > 6.12.19-1+reform20250322T135019Z (2025-03-22) aarch64 GNU/Linux
> 
> And because flash-kernel was not run for 6.12.22, you end up booted to
> 6.12.19?

Yes.

> Presuming this isn't some bizarre fluke, then this bug is likely present
> in most versions of flash-kernel, as that code has not been touched for
> at least a 2-5 years...
> 
> I vaguely recall a bug or merge request coming from Ubuntu that might be
> related...

I will try to reproduce this issue later using Debian kernels. My hunch is,
that the problem is that a new kernel version got installed at the same time
that flash-kernel got upgraded. Because at the time that 6.12.22 is installed,
flash-kernel should have been run but instead we see this in the log:

flash-kernel: deferring update (trigger activated)

And then the only other flash-kernel related message is:

Setting up flash-kernel (3.109+reform1)

So maybe this is about the order of triggers? Instead of "deferring update",
flash-kernel should've been run at the point of "Setting up
linux-image-6.12.22", no?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1102690: A higher version (...) is still installed, no reflashing required

[Vagrant Cascadian]

On 2025-04-12, Johannes Schauer Marin Rodrigues wrote:
> $ apt-cache policy linux-image-arm64
> linux-image-arm64:
>   Installed: 6.12.19-1+reform20250322T135019Z
>   Candidate: 6.12.22-1+reform20250411T222458Z
...
> $ sudo apt full-upgrade
...
> Removing linux-headers-6.12.16-mnt-reform-arm64 
> (6.12.16-1+reform20250219T175041Z) ...
...
> flash-kernel: A higher version (6.12.19-mnt-reform-arm64) is still installed, 
> no reflashing required.
...
> Setting up linux-image-6.12.22-mnt-reform-arm64 
> (6.12.22-1+reform20250411T222458Z) ...
...
> Installing 
> /usr/lib/linux-image-6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
>  into 
> /boot/dtbs/6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
...
> Setting up flash-kernel (3.109+reform1) ...

So, at this point, you had 6.12.19 and 6.12.22 installed, 6.12.16 was
removed ... and flash-kernel was just updated ... without re-running the
flash-kernel scripts for 6.12.22 ... although the "Installing
/usr/lib/linux-image-6.12.22...reform.dtb" was from (the older?)
flash-kernel, no?


> ===
>  REBOOT
> ===
>
>
> $ uname -a
> Linux kodi 6.12.19-mnt-reform-arm64 #1 SMP Debian 
> 6.12.19-1+reform20250322T135019Z (2025-03-22) aarch64 GNU/Linux

And because flash-kernel was not run for 6.12.22, you end up booted to
6.12.19?


> $ sudo apt remove linux-image-6.12.19-mnt-reform-arm64 
> linux-headers-6.12.19-mnt-reform-arm64
> [...]
> /etc/kernel/postrm.d/zz-flash-kernel:
> Using DTB: amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
> flash-kernel: Kernel 6.12.19-mnt-reform-arm64 has been removed.
> flash-kernel: A higher version (6.12.22-mnt-reform-arm64) is still
> installed, no reflashing required.

hrm... This makes my head spin. And not in a good way. :/


> $ grep -a 6.12.19 /boot/boot.scr
>setenv fk_kvers '6.12.19-mnt-reform-arm64'
> $ sudo flash-kernel
> Using DTB: amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
> Installing 
> /usr/lib/linux-image-6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
>  into 
> /boot/dtbs/6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
> Taking backup of meson-g12b-bananapi-cm4-mnt-reform2.dtb.
> Installing new meson-g12b-bananapi-cm4-mnt-reform2.dtb.
> flash-kernel: installing version 6.12.22-mnt-reform-arm64
> Generating boot script u-boot image... done.
> Taking backup of boot.scr.
> Installing new boot.scr.
> $ grep -a 6.12.22 /boot/boot.scr
>setenv fk_kvers '6.12.22-mnt-reform-arm64'

Ok.


> Luckily, running flash-kernel manually fixed the issue. But had I not noticed
> that /boot/boot.scr still contained a version of a kernel that I had just
> removed, my system would've become unbootable.

Presuming this isn't some bizarre fluke, then this bug is likely present
in most versions of flash-kernel, as that code has not been touched for
at least a 2-5 years...

I vaguely recall a bug or merge request coming from Ubuntu that might be
related...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1102690: A higher version (...) is still installed, no reflashing required

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Cyril Brulebois (2025-04-12 08:42:33)
> Johannes Schauer Marin Rodrigues  (2025-04-12):
> > Package: flash-kernel
> > Version: 3.109+reform1
> 
> > This problem occurred with a patched flash-kernel but you know that we only
> > patch the machines file with more entries and do not patch the scripts:
> > https://source.mnt.re/reform/reform-debian-packages/-/blob/main/patches/flash-kernel
> 
> Might want to adjust the version for the BTS though, I'd think?

I didn't want to lie about the version I'm using. Will the BTS choke in some
way if it's a version not in Debian main?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1102690: A higher version (...) is still installed, no reflashing required

[Cyril Brulebois]

Johannes Schauer Marin Rodrigues  (2025-04-12):
> Package: flash-kernel
> Version: 3.109+reform1

> This problem occurred with a patched flash-kernel but you know that we only
> patch the machines file with more entries and do not patch the scripts:
> https://source.mnt.re/reform/reform-debian-packages/-/blob/main/patches/flash-kernel

Might want to adjust the version for the BTS though, I'd think?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1102690: A higher version (...) is still installed, no reflashing required

[Johannes Schauer Marin Rodrigues]

Package: flash-kernel
Version: 3.109+reform1
Severity: serious

Hi Vagrant,

sorry for another RC bug but had I not seen this message it would've rendered
my system unbootable. The summary is, that I installed a newer kernel, then
rebooted, then removed the old kernel. Had I not paid attention, my system
would've become unbootable because flash-kernel decided not to update my
/boot/boot.scr for the new kernel version. Here are some hopefully relevant
bits from my upgrade/reboot/removal process:

$ apt-cache policy linux-image-arm64
linux-image-arm64:
  Installed: 6.12.19-1+reform20250322T135019Z
  Candidate: 6.12.22-1+reform20250411T222458Z
  Version table:
 6.12.22-1+reform20250411T222458Z 990
990 
https://source.mnt.re/reform/reform-debian-packages/-/jobs/8626/artifacts/raw/repo
 reform/main arm64 Packages
 6.12.22-1+reform20250411T055815Z 990
990 https://mntre.com/reform-debian-repo reform/main arm64 Packages
 6.12.22-1 500
500 http://deb.debian.org/debian unstable/main arm64 Packages
 6.12.21-1 500
500 http://deb.debian.org/debian testing/main arm64 Packages
 *** 6.12.19-1+reform20250322T135019Z 100
100 /var/lib/dpkg/status
$ sudo apt full-upgrade
[...]
Removing linux-headers-6.12.16-mnt-reform-arm64 
(6.12.16-1+reform20250219T175041Z) ...
Removing linux-image-6.12.16-mnt-reform-arm64 
(6.12.16-1+reform20250219T175041Z) ...
/etc/kernel/prerm.d/dkms:   
dkms: removing module reform2_lpc/1.68 for kernel 6.12.16-mnt-reform-arm64 
(aarch64)
Module reform2_lpc/1.68 for kernel 6.12.16-mnt-reform-arm64 (aarch64):  
Before uninstall, this module version was ACTIVE on this kernel.
Deleting /lib/modules/6.12.16-mnt-reform-arm64/updates/dkms/reform2_lpc.ko.xz   

Running depmod... done. 
/etc/kernel/postrm.d/initramfs-tools:   
update-initramfs: Deleting /boot/initrd.img-6.12.16-mnt-reform-arm64
/etc/kernel/postrm.d/zz-flash-kernel:   
Using DTB: amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb  
flash-kernel: Kernel 6.12.16-mnt-reform-arm64 has been removed. 
flash-kernel: A higher version (6.12.19-mnt-reform-arm64) is still installed, 
no reflashing required.
[...]

Setting up linux-image-6.12.22-mnt-reform-arm64 
(6.12.22-1+reform20250411T222458Z) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.12.19-mnt-reform-arm64   
I: /initrd.img.old is now a symlink to boot/initrd.img-6.12.19-mnt-reform-arm64 
I: /vmlinuz is now a symlink to boot/vmlinuz-6.12.22-mnt-reform-arm64   
I: /initrd.img is now a symlink to boot/initrd.img-6.12.22-mnt-reform-arm64 
/etc/kernel/postinst.d/initramfs-tools: 
update-initramfs: Generating /boot/initrd.img-6.12.22-mnt-reform-arm64  
Using DTB: amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb  
Installing 
/usr/lib/linux-image-6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
 into 
/boot/dtbs/6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
Installing new meson-g12b-bananapi-cm4-mnt-reform2.dtb. 
Installing 
/usr/lib/linux-image-6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
 into 
/boot/dtbs/6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
Taking backup of meson-g12b-bananapi-cm4-mnt-reform2.dtb.   
Installing new meson-g12b-bananapi-cm4-mnt-reform2.dtb. 
flash-kernel: deferring update (trigger activated)  
/etc/kernel/postinst.d/zz-flash-kernel: 
Using DTB: amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb  
Installing 
/usr/lib/linux-image-6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
 into 
/boot/dtbs/6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
Taking backup of meson-g12b-bananapi-cm4-mnt-reform2.dtb.   
Installing new meson-g12b-bananapi-cm4-mnt-reform2.dtb. 
Installing 
/usr/lib/linux-image-6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
 into 
/boot/dtbs/6.12.22-mnt-reform-arm64/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb
Taking backup of meson-g12b-bananapi-cm4-mnt-reform2.dtb.   
Installing new meson-g12b-bananapi-cm4-mnt-reform2.dtb. 
flash-kernel: deferring update (trigger activated)  

[...]

Setting up flash-kernel (3.109+reform1) ...

[...]


===
 REBOOT
===