Please RM armhf binaries

[Dave Jones]

LP: #2060214 (FTBFS) was eventually resolved by disabling failing tests on armhf to enable migration. Unfortunately, mtd-utils is the facility used by flash-kernel (on several boards, as it's used in the "generic" method) to flash boot artifacts to their destination.

Given that failure to flash these successfully risks subsequent boot failure (of a nature that is particularly difficult to resolve on certain armhf boards), and given that we're now not certain that the mechanism will operate correctly on armhf, please remove mtd-utils (and its dependency, flash-kernel) from armhf in noble.

[Dave Jones (waveform)]

Additional context:

flash-kernel has several methods of "flashing" boot artifacts (bootloaders, kernel, initrd, etc.) on various boards. Flashing may actually mean flashing EEPROM (typically done via some other utility, in many cases mtd-utils -- mtd incidentally is "Memory Technology Device", often EEPROM), or may simply mean file-system copies (as in the raspi where most boot artifacts just sit on a FAT partition).

Hence, if mtd-utils fails the scenarios range from "everything still works fine" all the way down to "bricked board". Given the potential range of outcomes, that the tests (but only the tests) indicate something is wrong, and that we have no other means of determining the outcome, I would prefer an abundance of caution and to simply prevent flashing in the first place.

Additional mitigation:

This only affects images that have deb-based boot artifacts like a bootloader and kernel. Container images are not affected, nor are snap-based images. After contacting hardware enablement, and certification we can't find anyone actually producing an armhf image this cycle (for noble) that contains such artifacts.

[Dave Jones (waveform)]

$ reverse-depends src:mtd-utils
Reverse-Recommends
==================
* 0xffff [armhf] (for mtd-utils)
* python3-binwalk (for mtd-utils)

Reverse-Depends
===============
* flash-kernel [arm64 armhf] (for mtd-utils)

Packages without architectures listed are reverse-dependencies in: amd64, arm64, armhf, i386, ppc64el, s390x

$ reverse-depends -b src:mtd-utils
Reverse-Testsuite-Triggers
==========================
* swupdate (for libubi-dev)
* swupdate (for libmtd-dev)

Reverse-Build-Depends
=====================
* swupdate (for libubi-dev)
* swupdate (for libmtd-dev)

[Dave Jones (waveform)]

Potentially affected images:

As noted above this potentially affects *any* armhf image with boot artifacts that require flashing (that are deb based). This potentially affects our older Pi server armhf images (which, although they don't use mtd-utils, do use flash-kernel). However, we're not producing Pi server armhf images this cycle and it is my understanding that do-release-upgrades has a quirk to prevent upgraders on that architecture.

It does not affect our Pi desktop images, which have never been armhf based.

This change potentially affects any flavours which produce such images. However, there has never (to my knowledge) been an official flavour with an armhf desktop image for the Pi.

Further mitigation ideas:

flash-kernel *could* be modified to merely recommend mtd-utils and still operate on platforms where mtd-utils itself isn't used for flashing boot artifacts (such as the Pi) but obviously this complicates the dependency situation (and seeds) on those platforms that *do* require mtd-utils.

[Dave Jones (waveform)]

We now have some better confidence that the failure is purely test-suite based, and shouldn't affect the operation of the binary itself. Marking won't fix and leaving the armhf tests disabled until such time as they can be fixed properly (or removed).