Some problems with newly installed rel 35.1 ubuntu

While investigating some device tree issues and UEFI halt on my custom carrier board system with the much generous help from wayne, I flashed it with rel 35.1 BSP and encountered the following issues:

  1. During the initial system configuration (GUI) , the setup freeze.
    After reboot it tries to perform initial system configuration again and freeze.
    I overcome that using the l4t_user_create script, but it still not valid behaviour.

  2. I can’t use sudo.
    it says:
    sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set.

  3. I noticed that my / contains symbolic links:
    bin → usr/bin/
    lib → usr/lib/
    sbin → usr/sbin/

I don’t know if all these problems connected but I have a feeling that (3) not supposed to happen and maybe its causing issue 2?

Does someone else encountered these issues and solved them?


On the host PC, was this flashed from an ext4 partition? Or did you have some other device used? For example, a thumb drive or SD card or Windows partition? Wherever you installed from (some place ending in “Linux_for_Tegra/rootfs/”), cd there, and see what you get from “df -H -T .” (the trailing “.” is important since it means “the current directory”). Non-Linux filesystems do not have any ability to understand special Linux filesystem permission types.

bsp@bsplinux1:~/Desktop/BSP/Jetpack_5_0_2_L4T_35_1/Workspace/Linux_for_Tegra$ df -T -H .
Filesystem Type Size Used Avail Use% Mounted on
/dev/nvme0n1p3 ext4 502G 403G 75G 85% /

That is valid, so I am surprised. If you cd to “Linux_for_Tegra/rootfs/usr/bin/”, then what do you see for:
ls -l sudo
(this is the source of creating the flashed image)

bsp@bsplinux1:~/Desktop/BSP/Jetpack_5_0_2_L4T_35_1/Workspace/Linux_for_Tegra/rootfs/usr/bin$ ls -l sudo
-rwxr-xr-x 1 root root 157632 Sep 7 13:43 sudo

Your sudo command misses setuid bit:

$ ls -l Linux_for_Tegra/rootfs/usr/bin/sudo
-rwsr-xr-x 1 root root 157632 Jan 19  2021 Linux_for_Tegra/rootfs/usr/bin/sudo

Its weird since I used the “regular” rootfs. I’ll change that, flash again and update

Are there any other specific crucial files that its better to make sure they are not missing the setuid bit in order for the ubuntu to operate well?

The default rootfs has it:

$ tar tvf tegra_linux_sample-root-filesystem_r35.1.0_aarch64.tbz2 | grep bin/sudo
lrwxrwxrwx 0/0               0 2021-01-19 06:21 usr/bin/sudoedit -> sudo
-rwsr-xr-x 0/0          157632 2021-01-19 06:21 usr/bin/sudo
-rwxr-xr-x 0/0           64264 2021-01-19 06:21 usr/bin/sudoreplay

The question is why your sudo misses the bit.

I can confirm that both problems are solved:

  1. I have valid sudo
  2. the system configuration is not stuck.

Thank you @user100090 for the help. much appreciate it!
and Thank you @linuxdev as well

For reference (also mentioned by @user100090), to others looking at this thread, the above is the failure point.

The final image flashed to the Jetson (including metadata like file permissions) will be a nearly exact replica of what is in “Linux_for_Tegra/rootfs/”. Some points about how this can be wrong on the Linux host PC:

  • If the content is ever unpacked to a non-Linux filesystem, then such errors are mandatory since other filesystems, e.g., NTFS or VFAT, have no concept of this permission (SUID or SGID), and the permissions are filtered out in such cases.
  • If the content is not unpacked by root (with sudo), then such permissions are lost because only root has the authority to do this.
  • Less obvious, some people will copy filesystems from one place to another, and eventually end up with the files at “Linux_for_Tegra/rootfs/”; sometimes tools used to copy will translate things like a user account name due to differences in which accounts exist on the host PC versus the Jetson, and copy of metadata will only be valid if the copy is forced to use numeric UID and GID (and only root can do this even if the right tool is used). An example of a good way to copy individual files is via rsync with sudo and forcing numeric UID and GID.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.