Issues within some scripts in Jetson-210_Linux_R32.6.1_aarch64.tbz2

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Hello.

I was given a task to produce rootfs & bootable images for Nano inside docker containers and noticed few issues. I’ve used https://developer.download.nvidia.com/embedded/L4T/r32_Release_v6.1/T210/Jetson-210_Linux_R32.6.1_aarch64.tbz2 as the tooling.

  1. nv_build_sample_fs.sh - this script checks the host architecture via hostnamectl. This requires dbus to be running to even give anything back but when run inside the docker container, it will not print any sort of architecture. Thus, check_pre_req() will fail.

  2. nv_build_sample_fs.sh - randomly but quite often fails with when installing packages mentioned in nvubuntu-bionic-aarch64-packages. The sample errors i still have stored, its always ```

    Unpacking humanity-icon-theme (0.6.15) ...
dpkg: error processing archive /tmp/apt-dpkg-install-QRqGCR/26-humanity-icon-theme_0.6.15_all.deb (--unpack):
 corrupted filesystem tarfile - corrupted package archive

    I’m calling the script like this: sudo TMPDIR=${TMPDIR} ./nv_build_samplefs.sh --abi aarch64 --distro ubuntu --version bionic --verbose and TMPDIR is pointing to "${WORKSPACE}/tmpbuilddir so that everything should be going into workspace directory of the jenkins slave (inside the container). I dont remember/know if dpkg honours TMPDIR, but it still feels wrong that i dont have a control where temporary files are located from CI perspective. It also feels odd that when ever the build failure happens, its been the humanity-icon-theme deb …

  3. One cannot specify rootfs location for nv_build_sample_fs.sh and l4t_create_default_user.sh like you can for apply_binaries.sh and jetson-disk-image-creator.sh and the scripts have to be executed with correct location related to the rootfs. For l4t_create_default_user.sh, things go even further since the rootfs directory HAS to be named as “rootfs” and script has to be located on the parent directory.

  4. Defining rootfs location for apply_binaries.sh and jetsom-disk-image-creator.sh use different env variables to point where the rootfs being produced is located (LDK_ROOTFS_DIR vs ROOTFS_DIR)

  5. jetson-disk-image-creator.sh - There is way to tell the partition size when creating bootable image. Size will be just slightly bigger than the files in the populated rootfs directory.

None of these are blockers at least for now, i can just fork and tweak the scripts or go with something like (hopefully) multistrap to generate the rootfs and work with image creation with something based off Jetson-disk-image-creator.sh … But would be nice to get some answers for above things if possible.

Thanks.

3

hello jani.mikkonen,

this should only reproduced with docker,
here’s developer guide for Setting Up Your File System. however, this is tested with native ubuntu-OS.

4

Hiya.

I was more of “reporting possible issues or bugs” mode than asking for documentation link. I have fully working pipeline inside docker on ubuntu 18.04 base image with tweaks required to produce rootfs and bootable image. For example: there are 4 ways to define where the rootfs is … One where rootfs folder has to inside a subdirectory of script path and it has to be named “rootfs”, another where rootfs is placed into PWD, and 2 scripts where you can pass the location via environment variables but on both cases, the env variable name is different.

Now, ofcourse (and ive already had) make patches to either fix or workaround these so as helpful as reading the friendly manual is, it doesnt really address the points above :)

Also, i didnt quite understand what you meant with “this should only be reproduced with docker”.

And finally, i left all the “docker findings” out of this and was reporting the issues that are not in anyway related to docker - those things in my list are mainly inconsistencies and/or maybe not so thoroughly thought out cases within the scripts mentioned - not docker (except, maybe using hostnamectl instead say, uname)

7

hello jani.mikkonen,

we cannot reproduce the failure.
we’re able to follow the steps in the developer guide to build rootfs with l4t-r32.6.1 successfully.
i.e. $ sudo ./nv_build_samplefs.sh --abi aarch64 --distro ubuntu --version bionic

or, you may share your command-line for reference,
thanks