What is the expected timeline for supporting the current Ubuntu LTS version? SDK Manager seems to function if lsb_release -r output is hacked on 20.04 to match 18.04, but supporting the current LTS without this workaround seems important.
Thanks for asking, it’s under planning, but there is no firm schedule yet.
Can you describe exactly how you did that?
Sure – I just modified
/etc/os-release and replaced
VERSION_ID value with
18.04. After that, sdkmanager happily runs.
I wouldn’t recommend that. It will let you install SDK manager but can probably also break your system’s package management, among other things.
os-release contains data that is defined by the operating system vendor and should generally not be changed by the administrator.
Probably best to wait for official support, given SDK manager installs packages on the host and Debian packages are not compatible across distos/versions even though it sometimes works and it’s possible to design packages with it in mind (eg. Chrome … or a lot of Google packages).
I didn’t propose leaving that change in place. Suppose I should have explicitly recommended reverting the change once SDK manager use is complete. That is what we’re doing.
And yes, ideally we’d use SDK Manager in a way that doesn’t require hacking the OS, but with Nvidia trailing pretty significantly behind an LTS release, we don’t have that luxury. No 18.04 or older system floating around and not worth the effort to downgrade OS.
When you change it back after installing SDKM itself, what happens when SDKM tries to update your system packages? My understanding is SDKM installs a bunch of stuff on the host as well, which is where I worry things could go badly.
Have you tried downloading the BSP and using flash.sh directly, without installing SDKM?
Re: trailing behind, yeah. I was hoping they would have updated by now. 20.04 has been availalbe to test with for quite some time. Then again I am kinda hoping they kill the product off entirely or go back to the old GTK version.
The change is needed to pass runtime check. Change is reverted following running SDKM.
I I have not tried running the underlying tools without SDKM layer. Some of our TX2s are running on 3rd party carrier boards that have to modify the flashed contents after being prepared on host machine but before being flashed. 3rd party SW is tightly coupled to SDKM behavior in order to execute this process.
I have not tried running the underlying tools without SDKM layer.
It might be worth giving it a shot. SDKM sets up the Linux_for_Tegra folder, but the tarballs linked on that page seem to have identical contents. The BSP tarball has Linux_for_Tegra, the rootfs tarball has Linux_for_Tegra/rootfs and so on.
I’m curious how this third party software is coupled. There is a sqlite3 database in ~/.nvsdkm/sdkm.db with account credentials, download locations, and so forth. If it reads from that, it might require SDKM. Othewise (eg. if it requires you run it from inside a specific Linux_for_Tegra path) you might not need it.
Thanks! Their dependency is only on the Linux_for_Tegra folder, so it sounds like that may be viable. Next time we need to flash we’ll investigate this approach further.