Sdk manager unsuitable for offline installation

[ahepner]

while using the SDK manager 2.0.0.11402 we were unable to successfully finish flashing and installation of a jetson xavier development kit.

some of the problems we encountered have to do with problematic docker image, but most are counter intuitive to the problem and offline installation is suppose to solve.

an offline installation, as far as i see it - is supposed to be helpful for situations where a machine hasn’t been connected to the internet prior, for porting the installation between machines and such scenarios where machines can’t or won’t connect to the internet or with bulk production where consistency is required

the docker image a perfect solution since it bundles all per-requisites in order for the SDK Manager to work.

Alas, the package unzip, seems to be missing from the image so the installation couldn’t proceed.
only after manuallly updating the docker image were we able to proceed.
hopefully this was fixed in the last versions, if not - i implore any NVIDIA employee reading this to include this package in the docker image since it’s not self-contained.

from here now, the problems i present are for any type of sdk manager installation:

furthermore, though an offline installation does suppose to have access to previously downloaded dependencies, we assumed the content of the SDKM Downloads folder would be enough.
Alas, the manager tries to fetch board and package information and store it in .nvsdkm in the home directory.
a hidden directory which is not mentioned anywhere but to painstakingly following the trail of thre error messages in the console.

finnaly, after successfully flashing the base linux image, the installation of the Jetson Runtime Components and the Jetson SDK Components would utterly fail.

the reason is because the installation constantly tries to access online repositories to download dependencies for all the packages that are under sdkm Downloads.
while one would have assumed that since there is an option to “Download only” in the sdk manger, and an OFFLINE option, that all everything required will be downloaded to the path that we are explicit required to input/confirm - it seems it leaves much to be desired.

I’ve yet to test this with a more recent version of the SDK Manager but it seems that they mostly aimed at newer hardware.

if this was remedied, please do inform, if not please fix this and add proper documentation for offline installation.

[DaveYYY]

Can you please make a summary of your request/issue?

[ahepner]

Thx for the quick reply.

In Summary:

1. make sure unzip is a part of the docker image (this is a quick fix, or may already been fixed)
2. make it so the data in the ~/.nvsdkm is present in the Downloads path, and fetched from ther/ copied there and used as a fallback in case there is no ~/.nvsdkm
3. have all the dependencies of the packages installed by the SDKM, also downloaded to the Downloads path as example - when installing nvidia container runtime, docker.io, runc and various others (i added a list of packages from a full online installation we did a while ago dpkg_l_fresh_full.txt (293.1 KB), most of them are not a part of the sample_rootfs and are not downloaded to the Downloads path)

in simple words, we’d expect when we run the SDKM once in download only mode while being online and other times in offline mode - that all dependencies for the installation configuration we’ve used when we were online will actually be downloaded and to be contained in a single, easily portable path

[DaveYYY]

Are you following steps here but SDKM still tries to access online repos when the host PC is offline?
https://docs.nvidia.com/sdk-manager/offline-install/index.html

[ahepner]

of course, we followed the manual. We did so in both GUI mode as well as CLI

it’s easily reproduceable - just select download only after selecting all HOST, Target and SDK options.
once finished, disconnect the HOST from internet and try to fully flash a jeton with all mentioned options.

base flash will work, afterwarfs it will fail due to dependencies

[DaveYYY]

Thanks for reporting.
We’ll see if we can reproduce this issue locally and check it internally.

[DaveYYY]

Hi,

I think this is expected as we have the following description in the page:

Some software components require additional dependencies which SDK Manager installs from Ubuntu package repositories (using apt commands). Consequently, the host must have access to Ubuntu package repositories to resolve these dependencies during an installation.

So this offline mode is meant to be used in a way that you don’t need to download most of the packages, but not completely without Internet connection.

[ahepner]

Now seriously, either the sdk manager allows for full offline installation, or the option shouldn’t exist.
this response is borderline insulting.

I pointed an issue, a real world issue and the answer isn’t serious.

The Apple like argument “you at holding it wrong” is invalid.

An offline mode that requires a partial internet connection is fundamentaly broken.

If the sdk manager can download the packages during installation, I’m sure you can figure it out how to save them as well.

Or are you expecting us to reverse engineer the sdk manager to find out where and when does it download dependencies?

The notion of requiring an internet connection is for an initial installation. But no, the sdk requires internet connection every time a kit is flashed and that unhelpful

[linuxdev]

This doesn’t mean a lot, but might be useful to know: The flash part of the install, if JetPack/SDK Manager has installed the driver package and sample rootfs (the basics which should always be present), then no network is required for that part of it. This is the actual flash step.

Once flash completes a Jetson will self-reboot. Upon reboot first boot account setup starts to allow an admin user to log in. One is no longer flashing at that point, this is a fully running system despite having started in recovery mode and having previously been flashing. Once that login is available, JetPack/SDKM will attempt to install optional software via ssh; this is the step that needs networking. I don’t know, but it is perhaps possible to tell JetPack/SDKM to download that content to the host PC while there is networking, and then to later use this offline if those optional packages are on the host PC (never tried). Maybe, do not know.

However, you can easily flash on command line with a completely disconnected network. On command line you need neither host-to-Jetson networking, nor host-to-Internet networking, nor Jetson-to-network networking. That’s because command line flash does not make installation of optional packages. Adding those extra packages after flashing on command line would require to add networking and use the correct apt-get commands to install them.

If you’ve ever added content to the sample rootfs content (which is the “Linux_for_Tegra/rootfs/” content), then this will “just be available” without any special steps. One nice trick is that if you’ve ever set up a Jetson the way you like, you can then clone it, and either copy content from the clone to rootfs/, or mount a loopback clone on rootfs/ temporarily (which will alter the clone slightly for boot content, but the rest is verbatim). You can even use rsync to update the sample rootfs from a set up Jetson to host PC if you have networking. From then on it is just a command line flash without needing JetPack/SDK Manager and with no network requirements.