I’ve tested akuster/meta-odroid@sumo…thud and can confirm that the fix lies somewhere in there. Considering the bug doesn’t exist on @hardkernel’s even older images, the regression seems to have been introduced in meta-odroid:sumo (which was being built off of hardkernel until thud , I believe).
meta-odroid:thud is compatible with sumo , but can’t be pulled into this repo until there is some patch re-work. There are some compile-time problems with both layers trying to write the boot image, and meta-balena 's config checks are throwing warnings because of the kernel bump. I will get to this after Christmas, but would love some help.
@balena-os, what is the timeline on balena-os/meta-balena#1313? thud compatibility on the meta-balena-* side would do away with this instantly.
meta-odroid is flying ahead with 4.19 LTS support with just one dev. I have been so impressed with balena to-date on the tooling end, but in the middle of a time-critical development cycle this is really crushing us, we’ve committed to this stack happily, but I’m now sensing that balena is focused on listing as much semi-functional board compatibility as possible rather than getting true support for a subset of boards beyond Pis. I’m only realizing now that I can’t find any test cases for balena kernel images.
This may be a very simple fix, I don’t mean to come off as condescending or unappreciative, but we’ve committed months to this platform for a large scale production run and I really hope a critical malfunction of one of your more powerful supported boards would be a priority. This issue seems to have gone unnoticed through the entire development of this image. The above referenced moby/moby#26150 is two years old. Surely someone would have noticed that this board was running at a third of its processing power if there was any hardware QA happening? There are a year’s worth of one-line-fix issues in meta-resin-odroid. I’m sorry to be blunt, but these are the questions I have to ask myself as I’m evaluating balena for a 1k+ node deployment.
The product in question is extremely dependent on consistent functionality of the underlying OS, and as Linus would say, there are no userspace bugs.
I fell in love with balena. I will stick with it. I’ll switch our entire architecture to another supported board if I have to, redesign our enclosures, thermal management, etc., we pivoted our entire stack when we realized how good of a fit this would be. I just want to voice my concern that this issue has existed for so long, unnoticed, and that there is no published LTS plan (see trello, the roadmap is completely out of sync with product release by >6 months in some instances), and your minimum SLA is $16k/year. Where is the focus? Hobbyist boards or a revolutionary IaaS provider?
If balenaCloud and OS are beta products, please, please advertise them as such. People (myself included) are building products, and eventually businesses on the assumption that this will scale with them. There seems to be a lot of flux and not a lot of direction.