This is my 2nd TX2 board, the first one didn’t experience such issue.
I flashed OS image to target board using Jetpack3.0 installer. It appears successful. However when I ssh to the target, I can not run sudo command, that’s when I found all the files under /usr/bin has owner ubuntu:ubuntu,here’s the root directory:
drwxr-xr-x 20 root root 4096 Jul 8 20:15 ./
drwxr-xr-x 20 root root 4096 Jul 8 20:15 …/
drwxr-xr-x 2 ubuntu ubuntu 4096 Jun 30 2016 bin/
drwxr-xr-x 5 ubuntu ubuntu 4096 Jul 8 02:31 boot/
drwxr-xr-x 13 root root 4900 Jul 8 20:15 dev/
drwxr-xr-x 133 ubuntu ubuntu 12288 Jul 8 20:15 etc/
drwxr-xr-x 4 ubuntu ubuntu 4096 Jan 6 2017 home/
drwxr-xr-x 22 ubuntu ubuntu 4096 Apr 1 15:29 lib/
drwx------ 2 root root 16384 Jul 8 20:11 lost+found/
drwxr-xr-x 2 ubuntu ubuntu 4096 Apr 20 2016 opt/
dr-xr-xr-x 216 root root 0 Jan 1 1970 proc/
-rw-r–r-- 1 ubuntu ubuntu 62 Mar 2 05:14 README.txt
drwx------ 5 ubuntu ubuntu 4096 Jul 8 20:15 root/
drwxr-xr-x 22 root root 800 Jul 8 20:15 run/
drwxr-xr-x 2 ubuntu ubuntu 12288 Dec 12 2016 sbin/
drwxr-xr-x 2 ubuntu ubuntu 4096 Apr 19 2016 snap/
drwxr-xr-x 2 ubuntu ubuntu 4096 Apr 20 2016 srv/
dr-xr-xr-x 12 root root 0 Jul 8 20:15 sys/
drwxrwxrwt 8 root root 4096 Jul 8 20:20 tmp/
drwxr-xr-x 11 ubuntu ubuntu 4096 May 3 2016 usr/
drwxr-xr-x 15 ubuntu ubuntu 4096 Apr 1 15:29 var/
Now the question is: How can I recover from this? Why is this happening?
uninstall/reinstalled jetpack on the host fixed the problem. Still like to know what caused this though.
I’m not sure how JetPack may prompt for password, as I use Fedora and flash only on command line. There are two steps where this can go wrong (and a condition which can make it impossible for it to work right) during manual flash (of which JetPack does this for you): When unpacking the sample rootfs you must use sudo. The apply_binaries.sh step must also use sudo.
Actual flash does not change permissions of the sample rootfs, but sudo is used there because of the need for root to create loopback devices if the loopback device is not already there and free.
Since only root can set some ownerships and permissions, this is why unpacking files and apply_binaries.sh must use sudo. The “gotcha” some people miss is that they don’t use a native Linux file system type for the flash…which implies the file system which rootfs is unpacked into is not capable of understanding or enforcing Linux file system details (such as SUID root). USB memory sticks and a VM on top of Windows would be an example of incorrect file system type since USB memory sticks arrive with VFAT file system, and Windows normally uses NTFS. Macs I think have HFS, but perhaps a Mac has a better understanding of ownership and permissions.
So…was the flash carried out from a native Linux file system type? Were the sample rootfs and apply_binaries.sh steps (or what JetPack does for you) done with sudo? I’ve never seen it fail for any reason other than these three details (technically apply_binaries.sh wouldn’t cause sudo to fail, though it would still cause system failures).
Thanks for the reply!
I think I have figured out why: a couple of months ago, I moved my host file system to a new SSD, the ownership was probably messed up then.
I’m having similar “adventures” in migrating my home partition to a new Fedora release. Looks like on Fedora not only do permissions and ownership need to be preserved, but so does SElinux labeling when policy is set to enforcing.
Pretty much everything related to unpacking or modifying the rootfs (including copy) needs to be done as root on a native Linux file system type since it contains device special files and SUID/SGID content which only root can manipulate (and non-Linux file systems have no understanding of special files or permissions). So a simple copy would have indeed caused the failure.