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

    From Johannes Schauer Marin Rodrigues@21:1/5 to All on Sat Apr 12 08:40:02 2025
    XPost: linux.debian.maint.boot

    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
    ===========================================


    $ uname -a
    Linux kodi 6.12.19-mnt-reform-arm64 #1 SMP Debian 6.12.19-1+reform20250322T135019Z (2025-03-22) aarch64 GNU/Linux
    $ apt-cache policy linux-image-arm64
    linux-image-arm64:
    Installed: 6.12.22-1+reform20250411T222458Z
    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
    100 /var/lib/dpkg/status
    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
    $ dpkg -l | grep linux-image
    ii linux-image-6.12.17-mnt-reform-arm64 6.12.17-1+reform20250303T085515Z arm64 Linux 6.12 for 64-bit ARMv8 machines (MNT Reform)
    ii linux-image-6.12.19-mnt-reform-arm64 6.12.19-1+reform20250322T135019Z arm64 Linux 6.12 for 64-bit ARMv8 machines (MNT Reform)
    ii linux-image-6.12.22-mnt-reform-arm64 6.12.22-1+reform20250411T222458Z arm64 Linux 6.12 for 64-bit ARMv8 machines (MNT Reform)
    ii linux-image-arm64 6.12.22-1+reform20250411T222458Z arm64 Linux for 64-bit ARMv8 machines (MNT Reform) (meta-meta-package)
    ii linux-image-mnt-reform-arm64 6.12.22-1+reform20250411T222458Z arm64 Linux for 64-bit ARMv8 machines (MNT Reform) (meta-package)
    $ 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.
    $ 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'


    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.

    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

    Thanks!

    cheers, josch

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johannes Schauer Marin Rodrigues@21:1/5 to All on Sat Apr 12 09:20:01 2025
    XPost: linux.debian.maint.boot

    Hi,

    Quoting Cyril Brulebois (2025-04-12 08:42:33)
    Johannes Schauer Marin Rodrigues <josch@debian.org> (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
    --==============911499403356940334=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmf6EakACgkQ8sulx4+9 g+ElCg/9G0FobL8iyO/xvOPYmb9qmsWlteG/tOrkQBjhZoptaV5zxvuGLKijHQgX zDz5MNSZbjGRDE09IZOe+BUGDN3WUDIoE++c9q2/qXMi9JWC//u6SpK+D/QdXRkV 5y3kbGhRx+je5JW0CrufsAnJ4mlby1hUUDmTQkUV5hbDiXVkzASDZnxW7GH9Omzd R/Bq84ngi0jBIUqyZwJ/LF8o5U7gjHMiuFx7Z+pMZXu3kYLrtbyDLn0tp+uo+8TI gDsUg9TJoK1gqFM94jmrp6ztSlC7uLNv4LpxmT3AO9JzP3+I3thqFh2OGZarPjbr 2IG4vHe17EmUgR2OBge5HyoztbFPDNdri81QotmWnIk+/Lmk4ghJLODW8vIQ62yP a9j1ex00iASzSXglY1TL+v8LgNmI1q/YDN69euMl2Lcmy/XVoswBvY//au+tWAQS 56aGPS+IMt+QaHnGdNxnSgU0jwLZNwwk0dH6SCVqJ5fEH1QDmFGZA468qNLRHz8R SslOF+M1gPi6KYFqNCjgjtbOXuFBovFtcoV66T2c+TaX1SGcIxDL2lLByl0hJDTZ lJpmFTbzoYPgfkTSNGpsC25atyOVWOp1oBizCYiDcobTns1JHnppZDj0xfG56KW+ RA/nJut5qEaXCQtvIXnSOpHw6+ytNkwsoiSfTk9FKLCzb8RSVOU=
    =Cj2V
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vagrant Cascadian@21:1/5 to Johannes Schauer Marin Rodrigues on Sun Apr 13 06:00:01 2025
    XPost: linux.debian.maint.boot

    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

    -----BEGIN PGP SIGNATURE-----

    iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZ/syiQAKCRDcUY/If5cW qoOpAQCUmP4XTW9LkxQL7fcotVdDdpFmdXLnZJwH5CpWhP4lOwEA2A/1eKvzYLi7 yhOZ2gKAJwrCnPvr/iOgyMHY2WrmkAI=
    =C4QJ
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johannes Schauer Marin Rodrigues@21:1/5 to All on Sun Apr 13 23:40:01 2025
    XPost: linux.debian.maint.boot

    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/20240401T000000Z/ \
    --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/20250401T000000Z/ 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
    --==============h32517134369381727=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmf8LHsACgkQ8sulx4+9 g+FyUg/+MB7JqHaiWrqUDINXXXRwfLIaaqBSG1gQBv0n1YgIEt0357q3oc3bSZ+C wzswbEomgTL+Oy1J38JY8RxXGOX11+ePP0nRGjjkXj0qiXNJFZxUORZmKl5fkauT 7cHmnGOlWfhNHhH/AdXAXbQvmvEjesjHCorkpm2tEMSC3cuElDk2U6jlXcuV1Dby t+eC6w1taumAz9+Wb0/LEM1HYwFKPUqfNtwwjZCxf1tFT8ut/TcKbO2FsHP754Ht +lGjzlbPWgxQgcJhgud9OoyyFDPEV5d8kPjmbiGSd+Eett3A03GOQe5/XHnDhhS6 ToNtVdqocYhlpyDyPlXPIF2SbrWt5h/kBpILr5Tlce1M3ek9Tb45h7mj80ifUH/N etST4IECodEktk7d6c7qBkIREMMMYioLh2WnYTPVUAqs8/J9czNmeBbFkPjk7SAC UcwiFePYmZlPQMeKoz+UWCjc4qBPOJ3SANy0ln4EebnaZtNesPSRJ9YOXkl/11XP wjNtalVZq4RStli456bayc0B9quF3NGq0McVt0ArDXwEIX10PyDc73zdGaQ8wZav qd0qdCcxQVU03R5aC/dhBHVj6HqGjXEWOCqp4kVsWS3+sIvYZzYeTndQy92hF2po SjKKzAq5b5aNSi7AxcknckIL6V7S+cIZLo4gQKbgd7kAZ+ckWO4=
    =i/2s
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johannes Schauer Marin Rodrigues@21:1/5 to Vagrant Cascadian on Tue Apr 22 07:00:01 2025
    XPost: linux.debian.maint.boot

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johannes Schauer Marin Rodrigues@21:1/5 to All on Fri Apr 25 08:10:02 2025
    XPost: linux.debian.maint.boot

    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/20240401T000000Z/ \
    --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/20250401T000000Z/ 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
    --==============56288030077903062=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmgLJQcACgkQ8sulx4+9 g+EhmRAAl/1mucDI/mxxOWjuoq9nbEFirejTRzHv5PbXSNMZHEkzJi19RpASl7Bs j7MNCvm/KIfXZecxH3Qa/11R+Z4sAuXKy5rmXl84eTbZZyUR47S5OSi3OJnR/pbu z1B9Z4WX30SEdeTL4aIxB8qK3CXi05p5chgGod7queIoQnIKxYb+7AgdDtWzOIwk JU9Zc34kjHd2i1B9OQWOTch/pI9LA4iortEOf9oghyhU8JTGWy81z8vcDPCe9pwi 7I1vlCU4XFF4ER7hBJEyHhHIUl5tufCTefMMUlLTrv3+gaIBXA8/YIHIntfyJsvo P7O2RaY3QY44ABxLMwmIoqh+nthJ0Rm1dBhP7oOpiy+gmW/JaaNJwKuFMTwl1TKb PFi6lge+FFaJW3P/BPvj63qDduhub6eizpmAwj660aHfDdc7gOvOOWsyDy6MOWuC X9Ta7KSFwgsM22gfeN0UfgJb0ShAyvVCFcGjaAwbANDTFN2XlPNOG0G5wLcLNROY pbzCdmhybHX7mT3n7LgohrFafNbJDr30CuHS6XDvjT3TXISG97dO7r1ZHpfNv/Am 2afHVfKu9h55b515+mYBzPQdeaE3URrmxB9m42oktoQUdacXL23WlLJNu1Elc1Aw y9yhCyQTP1FKeMxVyPFPCDnegcC8HM3VFfU5bY1oHQjWKEHgWDg=
    =YQC0
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johannes Schauer Marin Rodrigues@21:1/5 to All on Fri Apr 25 13:30:01 2025
    XPost: linux.debian.maint.boot

    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
    --==============†90359096377434374=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmgLcKkACgkQ8sulx4+9 g+EI9g//Rh51wyvzAuDBPOZyMhCJD06QXenDkzSMaqpNSIf8wO6s62Ky2Verb0fy 81JlnH1L8lKBVibWnUN2W8vYBYmAgUNqZ9R96i2tTT/crBlXs3oc1+W0pYp5RTer Oe4xO/KTc4IKH7TKxARW8B4SmuaZbeNeugOcxQq0P+DV6z6omnRWXXUpZJ4V96KQ Chuie3PqN4hUiCsXk2VNOORrmfPz15Nzldf+1arsUreJTOTeM9OO7rZADhZAVoZ2 NpvFFe09VohIVDIHpuGE25lP+qr9TUO63ggdhjVbHFPXqMrVlO6E4y4W7QUr5o8a cpYVUq/7gL3jQ/dRD/BEm0n3Yc9Vg3cHJVpneFXm+/21LS3o5CFPF8NuinZNRLCc hDSU3/FYiZm7+hCl8CpoS1HqbY5yAuqIvaQzXrOFjWeIuOoHN15SV0bvbbpQbMnP diqZNG8Yceojw6KZ20nxQMW3K8/T28ZAMDnU2Fesvf8vknE9Ty9Rt/yapwTfZ4HE +c13yhB8NN2Pw2LdozU4YXzI2BuMyzOrgeegy3/XEQJR3mQZlNbYlDVJAkMP2lAj FHAhrjdJbOKRAyhDSWRdLrwUdarqH3cXsVBPe6LaFlDNMl9PLFzqA4ikN5HH1YYx VuKn0Hd2Ke69AzKZ6+Rwm4i4AcDqK8uK6DWPCyOfNf3ZNg8eAvA=
    =gZ9q
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)