Let linux-image depends linux-dtb

[hzyitc]

Description

For bootable/workable kernel, dtb is necessary.

How Has This Been Tested?

• Build
• Run apt show linux-image-current-meson to check whether dtb is a dependency.
• Run apt purge --autoremove linux-image-current-meson to check if dtb will be removed automatically.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[rpardini]

This directly conflicts with previous strategy, which is to merge dtb and image packages into a single one.
To be fair, the image package already contains the DTBs, just not in /boot, instead, in the standard Debian location.

[SteeManMI]

This directly conflicts with previous strategy

For reference here is the jira link: AR-1608

The question is, do we wait until/if that task gets done or fix what is currently broken.
If there are two packages (as there are today) they should be dependent. So this fixes the current situation, but doesn't move us in the ultimate direction we wanted to go.

[rpardini]

Merging the two packages was already decided AFAIK, and solves the same problem, except it would break GRUB systems. If we want to have a interoperable package, we would need to change the dtb- directory name.
Sincerely I'd look at how kernel-PPA does it/doesn't do it and replicate it.

[amazingfate]

Debian just package the dtbs in linux-image: https://packages.debian.org/bookworm/arm64/linux-image-6.1.0-10-arm64/filelist
I think we can delete the linux-dtb package because it is just packaging the same file at /usr/lib/linux-image*.

[rpardini]

Debian just package the dtbs in linux-image: packages.debian.org/bookworm/arm64/linux-image-6.1.0-10-arm64/filelist I think we can delete the linux-dtb package because it is just packaging the same file at /usr/lib/linux-image*.

Yeah, our linux-image deb already has the DTBs in /usr/lib for a while now.

The linux-dtb package serves only to also have those in /boot/dtb-X, for compatibility with 1) vendor/legacy u-boots which can only FAT boot /boot partitions, and most importantly 2) all of our u-boot bootscripts.
Unfortunately, both the default Debian and Ubuntu grub.d scripts will mistake /boot/dtb directory/symlink for a valid DTB file and die in a fiery way when using GRUB.

I can't see a way around this until we've some Armbian board-side utility that can manage and deploy the correct initrd/uInitrd, image/uImage, and dtb placement, considering all the upgrade complexities, and handling some special cases (for example: current/edge kernel using one DTB, and legacy kernel using a different DTB; but many more "special" needs exist). Some kind of a mix between u-boot-menu, the grub.d stuff, and flash-kernel. See discussion in #5087

[amazingfate]

I don't know why debian packages dtbs in /usr/lib. To my understanding dtb files are used before root partition is mounted so they have to be in /boot, just like kernel images.
I just sent a pr to debian upstream to see if they will change that.

[rpardini]

I just sent a pr to debian upstream to see if they will change that.

Yeah, as I expected, ... This needs to be done by the firmware support scripts ... (which, for Debian, is mostly flash-kernel). I think we should invest in the discussion in #5087 and come up with our own scripts. Once that is done and after a few release cycles, we could just drop the linux-dtb package.