flash TK1 board on Host PC Ubuntu 16.04

Robotics & Edge Computing Jetson & Embedded Systems Jetson TK1
1

Hello,
We build our system on Host PC Ubuntu 14.04 and tar the image as ***.tar.gz.
It’s OK to untar this ***.tar.gz and flash the image to our TK1 board on other Host PC Ubuntu 14.04.
But when we download this ***.tar.gz to a Host PC Ubuntu 16.04 and untar this ***.tar.gz then flash the image to our TK1 board.
There are somethings strange on the TK1 board system.
1.when we open a application window, the tool bar of this window keep show(refer to 2.png) and disappear(refer to 1.png) repeated. So the window look like keep beating.
2.system won’t mount USB disk automatically when we plug in a USB disk.
(maybe there will be other strange things we don’t find now)

Then on a Host PC Ubuntu 16.04 I mount the decompressed image in a Host PC Ubuntu 14.04 through NFS.
And copy this image to Host PC Ubuntu 16.04 then flash this image to our TK1 board.
It’s OK as we flash the image in a Host PC Ubuntu 14.04.

Therefore it seems it’s the process of untar on Host PC Ubuntu 16.04 that cause the issue I mentioned in the begining.
So I want to find out what’s the difference of untar on Host PC Ubuntu 14.04 and Host PC Ubuntu 16.04.
I do this experiment:

  1. on Host PC Ubuntu 14.04:
$ sudo tar jxpf Tegra124_Linux_R21.4.0_armhf.tbz2
$ cd Linux_for_Tegra/rootfs/
$ sudo tar jxpf ../../Tegra_Linux_Sample-Root-Filesystem_R21.4.0_armhf.tbz2
$ cd ..
$ sudo ./apply_binaries.sh
$ cd ..
$ sudo tar jcpf Linux_for_Tegra_1404.tar.gz Linux_for_Tegra

and transfer “Linux_for_Tegra_1404.tar.gz” to Host PC Ubuntu 16.04

  1. on Host PC Ubuntu 16.04:
$ sudo tar jxpf Tegra124_Linux_R21.4.0_armhf.tbz2
$ cd Linux_for_Tegra/rootfs/
$ sudo tar jxpf ../../Tegra_Linux_Sample-Root-Filesystem_R21.4.0_armhf.tbz2
$ cd ..
$ sudo ./apply_binaries.sh
$ cd ..
$ sudo tar jcpf Linux_for_Tegra_1604.tar.gz Linux_for_Tegra

put “Linux_for_Tegra_1404.tar.gz” and “Linux_for_Tegra_1604.tar.gz” to a new folder on Host PC Ubuntu 16.04.

$ sudo tar jxpf Linux_for_Tegra_1404.tar.gz
$ stat Linux_for_Tegra/rootfs/usr/bin/crontab
     File: 'Linux_for_Tegra/rootfs/usr/bin/crontab'
     Size: 26620           Blocks: 56         IO Block: 4096   regular file
   Device: 802h/2050d      Inode: 49939634    Links: 1
   Access: (2755/-rwxr-sr-x)  Uid: (    0/    root)   Gid: (  107/ crontab)
   Access: 2018-12-21 10:36:44.184215657 +0800
   Modify: 2015-04-02 06:59:37.000000000 +0800
   Change: 2018-12-21 10:36:44.184215657 +0800
    Birth: -
   
$ sudo rm -rf Linux_for_Tegra
$ sudo tar jxpf Linux_for_Tegra_1604.tar.gz
$ stat Linux_for_Tegra/rootfs/usr/bin/crontab
     File: 'Linux_for_Tegra/rootfs/usr/bin/crontab'
     Size: 26620           Blocks: 56         IO Block: 4096   regular file
   Device: 802h/2050d      Inode: 48895489    Links: 1
   Access: (2755/-rwxr-sr-x)  Uid: (    0/    root)   Gid: (  103/systemd-network)
   Access: 2018-12-21 10:40:12.155241694 +0800
   Modify: 2015-04-02 06:59:37.000000000 +0800
   Change: 2018-12-21 10:40:12.155241694 +0800
    Birth: -

One thing I found in this experiment is that when we tar the Linux_for_Tegra on Ubuntu 14.04 and untar it on Ubuntu 16.04, some files’s groud id would be modified. (or tar on Ubuntu 16.04 and untar it on Ubuntu 14.04)
(the ground id will keep the same if tar on Ubuntu 14.04 and untar it on Ubuntu 14.04,
tar on Ubuntu 16.04 and untar it on Ubuntu 16.04)

For example, it should be in the TK1 board system:

$ ls /usr/bin/crontab -l
-rwxr-sr-x 1 root crontab 26620 Apr  1  2015 /usr/bin/crontab

But it becomes this when we flash the image on Host PC Ubuntu 16.04

$ ls /usr/bin/crontab -l
-rwxr-sr-x 1 root fuse 26620 Apr  1  2015 /usr/bin/crontab

You can use “Linux_for_Tegra_1404.tar.gz” on a Host PC Ubuntu 16.04 to flash the Jetson TK1 Board.
You will also see the phenomenon “system won’t mount USB disk automatically when we plug in a USB disk.”
(window beating seems also related to /home/ubuntu/.config/dconf/user, so you won’t see it in this case)

My question is:

  1. Besides group id, do you know what is modified when we tar on Ubuntu 14.04 and untar it on Ubuntu 16.04.
  2. How do you tar “Tegra_Linux_Sample-Root-Filesystem_R21.4.0_armhf.tbz2”? the files’s group id seems the same
    when it is untar on Ubuntu 14.04 and Ubuntu 16.04.
  3. Is there a way we can tar the image on Ubuntu 14.04 and untar it on Ubuntu 16.04 then flash the TK1 board
    and not “system won’t mount USB disk automatically when we plug in a USB disk.”

Thanks!

2

So it sounds like this, but correct me if wrong:

  • These are stored as files, and not as a loopback mountable image.
  • You are flashing using the same L4T release, and changing only the rootfs.
  • The NFS stores only the tar archive, and not the individual files making up the tar archive.

A good answer will probably require knowing if the above is true, and also which release the system is based on for (a) non-rootfs partitions, and (b) how you arrived at an Ubuntu 16.04…if it was based on this:
https://devtalk.nvidia.com/default/topic/1036457/jetson-tk1/how-to-successfully-update-jetson-tk1-to-ubuntu-16-04/
https://devtalk.nvidia.com/default/topic/1037496/jetson-tk1/ubuntu-update-on-jetson-tk1-/post/5270975/#5270975

Also, is this a custom board, or a dev kit?

A first note is that many files of the rootfs are tied to the content of other partitions during the boot stage. If you mix and match a rootfs from one L4T release with another L4T release, then you will get some failures.

The second note is that if any individual file is ever stored on a non-native Linux file system, then boot will break. File systems like ext4 understand Linux permissions. File systems like NTFS, VFAT, and fuse are not capable of preserving file permissions of Linux, especially suid and device special files.

NOTE: Fuse is typical of a live DVD distribution. It is a file system which the copy exists on, and is not part of the file itself.

A less obvious file system issue is that the boot loader itself does not understand any ext4 64-bit extensions. The Ubuntu hosts up through 18.04 do not use those extensions by default, and so this limitation is hardly ever mentioned. However, some Linux distributions enable this. I doubt this is an issue for you because boot itself would have failed to find the partition content…it would have failed prior to ever getting to a point of testing USB. However, it is worth mentioning that at the moment of generating an image for rootfs flash the system which generates the image must not enable 64-bit extensions. If a loopback mountable image is saved, then any existence (or compliance with) 64-bit extensions follows the image. If you ever see, in “/etc/mke2fs.conf” with the ext4 section, any of these, then you have an incompatible default mkfs and must adjust:

  • metadata_csum
  • 64bit

I forget where it is listed (one of @Honey_Patouceul’s posts), but in some cases a desktop cache can cause some tool bar issues. Try deleting (or moving temporarily) that user’s directory:

~/.cache/compizconfig-1/
3

Hello,
1.These are stored as files, and not as a loopback mountable image.
<=== We don’t use loopback in this topic.

2.You are flashing using the same L4T release, and changing only the rootfs.
<=== In the beginning, we flash our image to our custom board and find the problem.
But in the experiment in #1, we flash L4T r21.4 to a dev kit and also find that:
when tar on Ubuntu 14.04 and untar on Ubuntu 16.04:
a. uid/gid of some files in rootfs are modified.
b. system won’t mount USB disk automatically when we plug in a USB disk.

3.The NFS stores only the tar archive, and not the individual files making up the tar archive.
<=== we untar ***.tar.gz on Host PC Ubuntu 14.04 first. Then on a Host PC Ubuntu 16.04, we mount through NFS
the Host PC Ubuntu 14.04 and copy the decompressed image on Host PC Ubuntu 14.04 to Host PC Ubuntu 16.04.
In this process, it doesn’t involve untar on Host PC Ubuntu 16.04. Therefore we found the problem of “tar
on Ubuntu 14.04 and untar on Ubuntu 16.04”.

Thanks!

4

One thing I did notice…tar needs “–numeric-owner” when unpacking anything (and only sudo can do this, but you did use sudo correctly). Identity you see is actually a number-to-name table lookup. The numeric ID has to be preserved since the host PC isn’t the one whose “/etc/passwd” and “/etc/group” (and shadow) are using. Without specifying numeric ID cross-system archives will get an account translation when moving to another system.

The reason a loopback image is superior is that it stores the file system, the user and group ID tables, and never does a numeric-to-name translation.

5

Hello,
In the experiment in #1, I use this command to untar “Linux_for_Tegra_1404.tar.gz” on Host PC Ubuntu 16.04:

$ sudo tar --numeric-owner -xpjvf Linux_for_Tegra_1404.tar.gz

everything is OK now.

Thanks!