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).
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.
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.
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.