L4T version confusion

I try to avoid flashing a new OS if possible, because I fear it will kill the customizations I already did.
JetPack L4T 3.0 docs say L4T is 27.1

head -n 1 /etc/nv_tegra_release
says R27 (release), REVISION: 0.1
Is this 27.0.1 that I see quoted here?

~/NVIDIA-INSTALLER on the TX2 contains Tegra186_Linux_R27.0.1_aarch64.tbz2, hinting a 27.0.1 too.

The installer version info seems useless as it can’t have any version of the target until it is connected (in recovery mode).

Thanks for bringing some consistency to the naming scheme!

JetPack has its own version, and is a front end to the installation and flash software. Version 3.0 is the most recent JetPack front end.

The sample rootfs is purely Ubuntu…most recently Ubuntu 16.04 LTS. “Linux for Tegra” (L4T) is the Ubuntu when the NVIDIA-specific hardware acceleration and access files are added…for example, the driver to the GPU or the Tegra chip version of the USB controller are not available within stock Ubuntu…the apply_binaries.sh step during a manual flash does that overlay of the NVIDIA-specific files onto the sample rootfs within the rootfs subdirectory and turns Ubuntu into L4T.

The current sample rootfs is version 27.1 L4T, which overlays Ubuntu 16.04 LTS, and can optionally be flashed via JetPack 3.0.

Thanks for the explanation Ubuntu vs. L4T!

“JetPack has its own version”
Sure. Shouldn’t have mentioned JetPack. Was a distraction.

What I was really getting at was the unconventional REVISION format, which isn’t exactly clear.
Woulda been too easy to use major.minor.revision.build?

The flashing was as I feared: It wiped the whole thing and all the customizations I had done.

From the specs I had hoped to get a full-blown machine, but then it began to occur to me:
ARM architecture, cross-compilation and apparently only very partial Ubuntu apt update mechanism. (GPU and other drivers)


If you get to a point where you want to flash, but want to archive a copy of the original, you can clone the rootfs first. The clone can be loopback mounted and used as a source to rsync into the new system (useful for things like home directory sync for GUI settings, or “/etc” for things like ssh keys and other “/etc” changes).

When you go to flash you can save an old “bootloader/system.img.raw” to re-use…this too can be loopback mounted, edited, so on…clone and system.img.raw are the same thing at different points in time. The actual flash comes from the sparse/compressed version, system.img, but if you copy the system.img.raw to that name, this also works (original flash did not use sparse files, non-sparse still works if it is named system.img). The flash.sh option to re-use system.img is “-r”. The reason this is interesting for your case is because you can also rsync between loopback mounted images…if you migrate from something like R27.0.1 to R27.1 you can’t re-use the existing clone, but you can rsync to update parts of a clone or old system.img.raw into another clone or system.img.raw of different version.

Once I get things where I want I create a clone. I also back up certain files for overlay onto any revision…my ssh keys, networking, and logins for example remain constant regardless of major version flash.

Thanks for trying to point out a solution for the clumsy TX system update, but I wouldn’t want to know what can go wrong with my limited Linux knowledge.

Guess your forum name is linuxdev for a reason.

Until there is a KISS solution for the rest of us I’ll simply keep my customizations to a minimum.