Ah, had not heard about this. Thank you. I will adjust it to the new L4T release and implement contracts.
I would like to be notified about changes like this, is there an announcements forum I can subscribe to in order to remain better updated?
Hello, Regarding announcements, the balena blog is probably the best source of information ( https://www.balena.io/blog ) and includes monthly roundups of important or otherwise interesting developments.
Wait, is the CTI Orbitty TX2 OS the same as the CTI Spacely TX2 OS?
Iām using the Orbitty, not the Spacely.
Looks like there was a miscommunication somehow. Thatās unfortunate, Iām sorry to have cause work by missing that. Hopefully itās not a big issue or the two are very similar.
Hi, I apologize for the miscommunication.
There is no new release for the CTI Orbitty TX2, so the latest production release is 2.47.0+rev5. I have created an issue to request a release that will fix the SSH dangling issue on your device type. https://github.com/balena-os/meta-balena/issues/1941
I see from the history above that you have already manually patched one device for the sshd danging issue, so I hope this is not a big problem.
However, CUDA on the released 2.47.0+rev5 should work if you update the application to the new L4T release (32.2 for v2.47 while v2.45 was using L4T 28.3).
Containers contracts as explained in the answer above is still the best recommended action to avoid this happening in the future.
You can also check the changelog at https://github.com/balena-os/balena-jetson/blob/master/CHANGELOG.md to see whether a new BalenaOS release included a L4T update, in which case it is likely that your application will need to be updated.
Should not be a big problem. Thank you for your help.
Could you point me in the right direction for updating the application to the new release?
Hopefully that only requires updating drivers and wonāt be too much overhead to get things to work again?
Hello, your app will need to unpack the right BSP archive, and of course install the right CUDA packages versions (the GB size debs), and adapt any other software that relies on CUDA libraries. This is an example of a L4T 32.4.2 app which does the BSP unpacking for xfce that could serve as inspiration
Hi, just wanted to let you know that BalenaOS v2.51.1+rev4 is now available for the CTI Orbitty TX2 too.
Best regards
1 Like
Ok, so hereās my understanding of what youāre saying:
Different versions of balenaOS will support different versions of L4T. L4T is a set of drivers, files, and tools to interface between the CUDA GPU cores and my application. However, over time support for older versions of L4T will be dropped.
So, my containers that run on balenaOS 2.45.1 may stop getting updates to NetworkManager and balena-supervisor as time goes on.
This means that I will eventually have to modify my application so that it can run on newer L4T versions if I would like the feature updates that come from future versions of balenaOS. Upgrading L4T versions can entail a lot of work:
- Upgrading CUDA versions (E.g. 9.2->10.2)
- Upgrading OS versions (E.g. Ubuntu 16.04->18.04)
- Installing and compiling new driver packages
- Adding potentially Gigabytes to the size of pushing a container update
- All the headaches of resolving driver, package, and dependency compatibility that I went through the first time I built my application
Since these sorts of changes will require completely different containers, Iāll be required to use container contracts in order to tell devices which version of a container to use. This will require me to build and maintain different application source code (and Dockerfiles) as long as I have devices running different balenaOS versions.
Do I have this correct?
If so, I would like to avoid that for as long as possible. Itās a significant workload.
When will support for older versions of balenaOS be dropped?
Am I safe to use 2.45.1+rev4 somewhat indefinitely?
Hi Connor, looking at your comments, I definitely understand your concerns. This is a large application stack, with lots of dependencies and bits and pieces. Having said that, as the application owner, you definitely need to be aware that maintaining the application could certainly require some upkeep, updates, and future migrations to newer components. Thatās simply the nature of application development.
Thinking about it more though, your use case is probably a good fit for our āESRā images (Extended Support Release). At the moment the Orbitty TX2 is not a supported device type for ESR, but I will ping the team and see if makes sense.
In the meantime, you can read about it here, to see if itās what youāre looking for: https://www.balena.io/blog/balenaos-esr-peace-of-mind-with-only-two-updates-a-year/
Definitely fair point. As a very small company, the number of things to juggle can be difficult and thereās nothing that feels like quite as much of a waste as spending days and hours writing code to combat software rot. I understand that the universe isnāt going to stand still for me, but if it were just a bit slower I could spend more time fulfilling on sales and less time coercing my code back into working order.
Would definitely be interested in hearing more about this!
Hi Conor,
someone from our team will directly reach out to you via email, to follow up on this thread and discuss how ESR works.
Georgia
1 Like