Let `linux-image` depends `linux-dtb`
Description
For bootable/workable kernel, dtb is necessary.
How Has This Been Tested?
- [X] Build
- [X] Run
apt show linux-image-current-mesonto check whetherdtbis a dependency. - [X] Run
apt purge --autoremove linux-image-current-mesonto check ifdtbwill be removed automatically.
Checklist:
- [ ] My code follows the style guidelines of this project
- [X] I have performed a self-review of my own code
- [X] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [X] My changes generate no new warnings
- [ ] Any dependent changes have been merged and published in downstream modules
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.
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.
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.
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*.
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 https://github.com/armbian/build/pull/5087
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.
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 https://github.com/armbian/build/pull/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.