flash-kernel: database references 'armmp' kernel flavor which is called 'generic' in Ubuntu
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
flash-kernel (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
[Impact]
The generic ARM kernel flavor in Debian is called 'armmp' (for ARM multi-platform) but in Ubuntu it's called 'generic' as it is on other architectures. As a result, there are many, many entries in the flash-kernel database maintained by Debian that list 'armmp' as the supported kernel flavor, and which are supported by the Ubuntu kernel but are not supported by the Ubuntu flash-kernel package.
Mapping 'armmp' to 'generic' in the flash-kernel code would let these boards handle kernel upgrades cleanly. (NB: Ubuntu has no installer support for any of these boards.)
[Test plan]
Attempt to install a new kernel on an affected board.
[...]
Couldn't find DTB imx6q-cubox-i.dtb on the following paths: /etc/flash-
Installing into /boot/dtbs/
cp: cannot stat '': No such file or directory
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
[...]
Install flash-kernel from -proposed.
[...]
Setting up flash-kernel ($version) ...
Using DTB: imx6q-cubox-i.dtb
Installing /lib/firmware/
-i.dtb
Taking backup of imx6q-cubox-i.dtb.
Installing new imx6q-cubox-i.dtb.
flash-kernel: deferring update (trigger activated)
Processing triggers for flash-kernel ($version) ...
Using DTB: imx6q-cubox-i.dtb
Installing /lib/firmware/
Taking backup of imx6q-cubox-i.dtb.
Installing new imx6q-cubox-i.dtb.
flash-kernel: installing version 5.4.0-122-generic
Generating boot script u-boot image... done.
Taking backup of boot.scr.
Installing new boot.scr.
[...]
[Where problems could occur]
If a user has bootstrapped an Ubuntu system that uses the Ubuntu userspace but a Debian kernel, their kernel flavor will be armmp and this change will regress that user's support for upgrading their kernel, resulting in a stopped upgrade. However, running Ubuntu on a Debian kernel is entirely unsupported; and for a user to have done this in the first place would require some sort of manual package management since you can't sanely add the main Debian repositories to the apt sources of an Ubuntu system. So while it is possible for someone to configure a system this way, and this SRU would regress such a system, I do not believe that should block this SRU.
Adding code to map kernel flavors just adds complexity.
The database is only used to choose the device-tree name. Only if the device-tree name depended on the kernel flavor we would need a 'Kernel-Flavors:' entry to choose the right device-tree.
Does such a case exist at all?
There is not a single case of duplicate values of 'Machine:' entries.
So the best solution is to simply ignore the kernel flavor.
Best regards
Heinrich