framework: explicitly add linux-image-armbian to armbian-bsp-cli pkg dependencies #9071
Conversation
WalkthroughUpdated Debian control metadata in two packaging scripts: added Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–30 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Disabled knowledge base sources:
📒 Files selected for processing (1)
🧰 Additional context used🧠 Learnings (14)📓 Common learnings📚 Learning: 2025-09-27T21:47:58.020ZApplied to files:
📚 Learning: 2025-09-27T21:50:04.845ZApplied to files:
📚 Learning: 2025-09-27T21:49:55.796ZApplied to files:
📚 Learning: 2025-09-27T21:50:15.915ZApplied to files:
📚 Learning: 2025-11-02T20:49:56.719ZApplied to files:
📚 Learning: 2025-04-30T16:16:47.150ZApplied to files:
📚 Learning: 2025-11-10T22:05:40.490ZApplied to files:
📚 Learning: 2025-06-25T03:42:09.086ZApplied to files:
📚 Learning: 2025-05-05T12:35:07.143ZApplied to files:
📚 Learning: 2025-08-21T08:10:59.502ZApplied to files:
📚 Learning: 2025-06-24T10:08:40.313ZApplied to files:
📚 Learning: 2025-12-12T23:10:00.819ZApplied to files:
📚 Learning: 2025-09-14T06:29:18.958ZApplied to files:
🔇 Additional comments (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
This doesn't give issues when for example using armbian-config to switch kernels, does it? I mean it uninstalls one (and that's where this dependency may hurt?) and then installs the new one. |
switching kernels will most likely fail. This could fail already at build stage if bsp is installed before kernel. If there is (by default in some stages / cases) no armbian repo at build stage, installing this package will try to install 1st linux-image (generic from debian or buntu) it will found. If this breaks anything mentioned, lets put this on a side. What is the benefit, except doing it right way? |
|
So I admit this has only been tested [by me anyway] with my APA branch, and I may not have attempted booting an image from this branch that used bookworm [non-APA]. It's 6AM local time so I'll have to try this later.
But even so, your concern re a generic kernel should be an ordering problem in the image build, no? Either install bsp-cli at the same time as the chosen kernel or before bsp-cli. This can be looked at also.
The impetus for this change [and I'm *not* going to argue, right now, if this change can standalone] was that linux-image couldn't go into armbian-common, but it was insisted [not by me] that the kernel had to be non-removable at runtime.
Sent from myPhone.
|
Understand. There is no rush - before we are doing changes: key people that are maintaining the project has to be happy and aligned - we need to start meetings on the topic as current chat & PR comm is not sufficient at speed. Changing relations in key packages must be fully tested for all possible perspectives, useful would be to build test automation in front. We have enough of problems already ... All PR-s should be carefully weighted but sadly we have limited capacity and I often merge blindly. Then I feel like an idiot when bad code gets in as I merge because I didn't have time to check deeply ...
It is possible that it works, but it can also break. If nobody looked from this (all) perspective(s), suspicion is legit. Armbian tool - from user and developer perspective - has to work the same way - this has to be our common high level goal and I think we have a consent in this.
bsp is board support package that also carries common stuff, which can safely be moved to some common package. It obviously need kernel package, but the same goes for all other packages. There is no Linux without Linux. Since we have more kernels per board, different way of switching and the way it is handled now, works. Even not done the best way. Perhaps we rahter understand packages provided by framework (kernel,uboot,headers, firmware pkg and bsp) as "board firmware" that is added to user space rootfs. This is how system was designed. Armbian remain with one foot in embedded and with other foot in general purpose Linux world. I believe Debian packages relations can play in our favor and I remain skeptical on corner cases. |
|
https://paste.armbian.com/fecufohuvu here is a build log from branch #9000, for I'm sure that @leggewie can test #9071 with all of the scenarios he can think of. |
|
If you want to force only a single kernel to be installed the solution is for Armbian linux kernel packages to Conflicts on linux-image, I guess. And there are ways to prefer certain kernels over others. This is solvable. At the same time, it would be beneficial to revisit the reasons that Armbian needs this restriction of having only one kernel installed at the same time. The solution as proposed here is still clearly correct. One part of a BSP is the kernel, so the BSP package needs to ensure the presence of a kernel. FWIW, I can imagine minimal Armbian container images for testing purposes that do not have a BSP package installed and in turn no kernel. For quite a long time, I meant to write up some documentation for how to test stuff in a VM or container for bug triage without flashing and shuffling µSD cards all the time. I appreciate the thought going into what could still go wrong with the current setup. Clearly, there is still more work to do. |
|
Why only one? there are cases where we potentially might break the Highlander Rule, but I imagine you'd need it to be GRUB or some other option with a menu. Haven't seen that with |
Assuming that this policy of "strictly having only 1 kernel installed at the same time" is being enforced by armbian-config then this is already again the wrong place and it doesn't actually work. In that case, there's nothing preventing another kernel being installed via the usual tools like dpkg, apt or aptitude. Making these policies more explicit and their existence more widely known in the community is just one of the benefits of the work we currently have around the APA transition. Scrutinizing the needs and proper implementation of these policies has obvious benefits as it makes armbian more robust and maintainable for users and devs alike. I understand that in general, limitations in booting via uboot (most common for armbian) vs. grub (arguably most common in upstream Debian/Ubuntu) are at the core of having this policy. But can you please explain why it was chosen to remove the kernel first before installing another? Obviously, that can go bad if the lights go out just when the old kernel was uninstalled. Why not have them conflict but allow for brief transition periods where two kernels are installed? Lastly, it appears that Armbian in general needs to / wants to prevent upstream kernels from being installed. I suggest to have armbian kernels identified as a virtual package linux-image-armbian or armbian-linux-image and adjust dependencies accordingly. |
And who would have known, the current kernel packages already provide linux-image-armbian, so that's in place and already usable. I believe Armbian does not support systems with a non-armbian kernel. I will make the corresponding change in APA as well as this PR to reflect this. |
exclude non-armbian kernels from fulfilling the dependency as there is no guarantee these kernels are in fact bootable on the SBC in question
the BSP package is priority required not optional as it is required to boot https://www.debian.org/doc/manuals/debian-faq/pkg-basics.en.html#priority
we do not want the user to install an upstream kernel package
rpardini
left a comment
There was a problem hiding this comment.
I can't fathom why this is even being considered?
One can have multiple kernels installed. every Debian system can.
Fact the "boot.scr" boot method (which is just one of many possible) limits to a single bootable kernel does not justify crippling everything for everyone.
One actionable example is EXT=u-boot-menu (extlinux), not to mention grub, etc.
Congrats! So, we're actually not even clear what the current Armbian policy is. Good thing we are having this discussion to understand the background and existence or absence of such a policy. My assumption based on previous conversations was that the peculiarities of SBC meant that the ability of Debian to have several kernels installed and boot from did not necessarily transition to Armbian and SBC. Ricardo challenged that assumption and maintains that Armbian is no different to Debian in this regard. So, to move forward and adjust this PR appropriately, we need answers to the following questions.
|
|
I'd venture two things:
a) this may all qualify as ghafla/bikeshedding/distraction. This doesn't feel like our highest priority, it just feels approachable.
b) perhaps the armbian-bsp package is the wrong place to put it, and it rather should be the board-specific BSP depending on e.g. linux-image-sunxi64. Not that we can't have both [the generic pkg and the board-specific pkg with slightly different granularities of dependency]
Sent from myPhone.
|
I agree with @tabrisnet that the BSP package should depend on a kernel package
carved out from #9000
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.