Execute ./flash.sh jetson-tk1 mmcblk0p1 on ubuntu 12.10 and ubuntu 14.04 ....

When I was executing ./flash.sh jetson-tk1 mmcblk0p1 on ubuntu 12.10 and ubuntu 14.04 … I got different situation.
(P.S.: I use ubuntu 14.04 to be my development PC. I built my own bootloader and kernel).

If I used ubuntu 14.04 to re-flash the image, most functions are ok.
If I used ubuntu 12.04 to re-flash the image, most funcitons are not ok but some are fine.
These ‘fine’ parts are not OK if I used ubuntu 14.04 to re-flash the image.

Can anyone provide suggestion/comment about this ?


The host running flash.sh should not make any difference in how Jetson runs. All hosts using the same sample rootfs should result in consistent behavior for the Jetson being flashed. If there is a difference between the two systems and if they both used the same sample rootfs, it is usually a problem of having permissions incorrect due to not running as root or with root authority…things like device special files are unlikely to be copied without root authority.

Hi, Thanks for your kindly reply.

May I ask one more question ?
Once we had prepared our own ‘rootfs’ (or let’s say, my own ‘Linux_for_Tegra’, we would like to copy it for other side.
What I did are :

  1. using command : sudo tar cjvpf myOwnLinuxforTegar.tar.bz2
  2. Using command : sudo tar xjvpf myOwnLinuxforTegar.tar.bz2 (Decompress my compressed file on other PC)

Could you please advise if there is anything I am doing wrong ?


Those commands seem to be fine, as they should be able to preserve permissions. An odd example case for a problem would be something of the nature of a device special file not being copied as root…only root can work with device special file creation. Similarly, it was recently pointed out that sometimes Linux runs with an anti-virus scanner…apparently these also won’t allow placing device special files correctly.

Regardless of whether you have a custom or stock rootfs, you still need to run sudo apply_binaries.sh, which merges some Jetson-specific files in. One other thing which may change a custom rootfs is that some boot loader files are written into the sample rootfs at the time of running flash.sh, so if your custom rootfs has boot loader changes this too may interfere.

Beware if you create a tar file of your custom rootfs there are some file types which may not behave correctly unless care is taken. An example is again a device special file such as /dev/zero…direct copy of such a file tries to copy an infinitely large file by copying content…this can be dealt with but one needs to look closely at preserving device special files. Sockets should NOT be copied, as they are intended for creation at runtime by an application, and expected to be cleanly removed upon shutdown of the application.

I’ve also never seen an issue with SElinux, but if your host has an enforcing mode it is highly likely this would create issues with rootfs creation.