Hi,
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:
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.
I can’t use sudo.
it says:
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set.
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.
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)
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.