Bundle L4T Driver Package to move to another machine

[npd1]

I’ve downloaded and modified the L4T Driver Package (BSP) and Sample Root Filesystem. Now I want to move these folders to another machine. I try to copy entire folder to an USB drive but it doesn’t work and clearly not a good method. Is there an existing tool or procedures to zip these folders like what they were at the beginning?

[linuxdev]

FYI, the file permissions and ownership must be preserved. Does your USB drive have a Linux filesystem? If it is a Windows filesystem, e.g., VFAT, then there is no possibility of this being preserved. You can see filesystems and types (with the thumb drive plugged in) via “df -H -T”. You could replace the partition with an ext4 partition as one workaround if it is VFAT or one of the FAT systems or NTFS.

Alternately, you could use a correct tar and/or rsync command to package the content’s metadata into the archive instead of a direct copy of files/directories. Then you’d copy a single archive file to the thumb drive, and unpack at the other end.

Regardless of direct copy or archive container copy you would have to be sure to use commands which exactly preserve permissions and numeric IDs.

[npd1]

Thanks @linuxdev. I will take that into consideration. I also have other questions.

1. Should I package the LinuxforTegra folder with the rootfs folder inside? Or should I package these two folders seperately?
2. Should I ever manually modify the rootfs folder?
3. What is the purpose of ./apply_binaries.sh?

[linuxdev]

I’d just package them together. Boot-related content needs to be compatible with the rootfs content (release versions). On the other hand, stock rootfs content is available for separate download. Just to clarify:

• The actual flash software is the “driver package” (named as such because it understands a recovery mode Jetson, which is in turn a custom USB device).
• If all you do is to command line flash, then you would download these:
  • Driver package.
  • Sample rootfs.
  • Then you’d:
    • Unpack the sample rootfs as root in the rootfs/ directory, thus preserving permissions and ownerships.
    • Run “sudo ./apply_binaries.sh” once to add the NVIDIA content to the sample rootfs. This is when it becomes “L4T” and not just Ubuntu. The sample rootfs is 100% pure Ubuntu, and it is distributed and licensed as such. When the end user runs “apply_binaries.sh” as root (with sudo) to add this content, it is the end user accepting the additional content to what used to be a pure Ubuntu rootfs.
    • Using JetPack/SDKM is just a front end. Using this will automatically download a matching sample rootfs and driver package, then automatically apply_binaries.sh. When done manually, then the end user has to do this. JetPack also has the ability to install optional software, which the driver package does not do, but that step only occurs after flash completes and the Jetson fully reboots. Using JetPack means you don’t need to manually unpack or install either the driver package or the sample rootfs. Regardless of whether it is done by the end user or JetPack/SDKM apply_binaries.sh only needs to run once.

During a flash the “rootfs/” content is almost an exact match to the root partition image. The “almost” part comes because arguments for the particular module and carrier board type will change a few details. Those details are reflected in flash probably adding or editing the particular kernel, device tree, and extlinux.conf configuration in the “rootfs/boot/” prior to generating an image. Everything else is untouched and used verbatim in the final flash.

So long as it isn’t one of the things being modified prior to generating a partition image it is quite useful to modify content in “rootfs/”. For example, user accounts can be added, custom aliases can be put into “/etc/skel/”, actual end user home directories can be added, ssh keys can be added, network settings can be customized, so on.

Incidentally, you can also loopback mount a raw clone to the “rootfs/”, and use that for generating a partition image. This would modify the clone’s “/boot” content, which you might not want, but otherwise it will be the clone (e.g., if you installed and ran all updates, then future flashes this way will also have those updates). If you copy a clone to “Linux_for_Tegra/bootloader/system.img”, and use the command line “-r” option to reuse the image, then you get a 100% verbatim exact match (no “/boot” content edit). You would still get the other content related to boot partitions installed.