Flashed TX2 and sudo failed

Following this instruction page


I flashed TX2 successfully, but when I try to use sudo, it gives:
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

Should I simply flash again with these steps:


Or is there something wrong using https://developer.nvidia.com/embedded/downloads?#?dn=jetpack-for-l4t-3-0

Assuming you flashed on command line…

When preparing for flash you must use sudo in any unpack of the sample rootfs. You must also use sudo in the apply_binaries.sh step. Additionally, the file system on the host where system images are generated must be a native Linux type…VFAT and NTFS are guaranteed to fail (see “df -H -T” to view file system types and free space).

Hi S3,

Please check your “sudo” permission.

chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo

Let us know your update. Thanks!

Thank you linuxdev and carolyuu.

I did use sudo on the second step in this instruction:
sudo ./JetPack-L4T-3.0-linux-x64.run
The host PC is native Linux, running Ubuntu 16.04.2 LTS

carolyuu, checking “sudo” permission gives this message:
chown: changing ownership of ‘/usr/bin/sudo’: Operation not permitted
I am not sure how (if I can) switch to a root user?


On your Linux_for_Tegra directory of the host there will be subdirectory “rootfs/usr/bin/”. Use “ls -l” of sudo and see what the original sudo permissions were prior to flash. If this is not “-rwsr-xr-x. 1 root root” then this was a cause.

In most variants of Linux, there’s some way to intercept the boot loader, and boot in “single” mode. (Typically, by adding the word “single” to the kernel command line.)
Once you do, you will be placed in a text-mode shell with root privileges.
There, you should be able to change the permissions back for the sudo binary.

Some of systemd does not function correctly on L4T, e.g., multi-user.target cannot be achieved via “sudo systemctl isolate multi-user.target”. I’m not sure how one would reach single user mode on L4T even if desktop Ubuntu can do this (and since root account is locked on desktop Ubuntu and I don’t have a desktop Ubuntu I’m not even sure how that works).

But…if sudo has the wrong permissions, then the cause was likely due to how the file system was unpacked and updated…in this case there will be many files which are incorrect and sudo will only be the tip of the iceberg. It is extremely probable that fixing this one issue will only lead to finding out that manually fixing permissions is extremely difficult.

Such terrible.
Very sad.

OP already said they fat-fingered that one, and accidentally dropped permissions on sudo.
(That one, and accidentally screwing up the syntax of /etc/sudoers, are the classic burns UNIX sysadmins must experience at least once to become experienced!)
However, I would expect a new flash from a new download/install/build of Jetpack to recover everything correctly.

According to your point, I checked the original permissions using “ls -l”, they are “-rwxrwxrwx 1 root root”. Is this the problem?
I also tried this https://devtalk.nvidia.com/default/topic/1012364/jetson-tx2/how-to-flashing-jetson-tx2-and-setup-network-correctly-/ and properly unpacked them, but still get the same problem.

Any suggestions?


That is a problem. It means the sample rootfs was likely not unpacked by root (only root can preserve sudo permissions). There are many other files which would also have failed, you just found the first thing most people run into when sample rootfs is unpacked incorrectly (similar issues with not using sudo during apply_binaries.sh). On JetPack you should use your regular user, and then it prompts for password…but with command line you just have to use sudo directly for rootfs and apply_binaries.sh.

If you fix just one permission there will probably be hundreds of other issues you’ll find over time…flashing again is probably required. Delete the rootfs directory content, unpack again with sudo, and apply_binaries.sh with sudo. Flash should then work. The other parts of the installation software do not require sudo.

Extra note: Make sure you are not using a non-Linux file system type, e.g., if you use a thumb drive you have to reformat before using it…VFAT and NTFS won’t work, ext4 does. Check with “df -H -T”.

Another option is that the file system you’re unpacking on has the “nosuid” option set.

If it’s a default EXT4 file system/disk local to the host, this is less likely, but if you use some kind of virtual shared drive, external disk, or NFS mount, it’s possible that this bit is set and is getting in the way.