Today I use l4t_quick_start_guide.txt instructions step by step to reflash my jetson-tk1 by Tegra124_Linux_R21.4.0_armhf.tbz2 and Tegra_Linux_Sample-Root-Filesystem_R21.4.0_armhf.tbz2 except that my host Linux was Debian instead of Ubuntu (which I think should not matter at all) every thing were ok during the process but I have faced two major issues (I have repeated two time):
First: After restart the boot process on jetson started correctly but finally the gui doesn’t show (only a blank screen was shown)
Second: I connected to the jetson via network with ssh and logged in with ubuntu but unfortunatly ubuntu user was not suder and I do not find any working password for root user. so I could do nothing especial.
What should I do now and what I have done wrong.
I use Fedora, so you are correct that Debian should not matter. The only case where Ubuntu is actually required is if you are using Ubuntu packages (JetPack uses Ubuntu packages).
If you can log in via ssh, then the flash itself succeeded. I’m not sure what you mean about ubuntu was not sudoer, but can you run “sudo -s” and password “ubuntu”? This would give a root authority shell.
One of the more common issues if GUI fails is that the “apply_binaries.sh” step was not done prior to flash. This applies some hardware access files to the sample rootfs. The serial console should work even if GUI fails…are you able to use the 9-pin serial connector (via NULL-modem cable) to log in from another machine as well?
Once logged in (via ssh or serial console), do you get anything other than “OK” for files from the command:
sha1sum -c /etc/nv_tegra_release
thanks for the reply
for any command that I use sudo with ubuntu user I get the following error message:
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
and for now I have done more than 4 times of reflash and I am sure about performing apply_binaries.sh before reflashing
And the result of
sha1sum -c /etc/nv_tegra_release
was completely OK
/usr/lib/xorg/modules/drivers/nvidia_drv.so: OK /usr/lib/xorg/modules/extensions/libglx.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_video.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvwinsys.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvomx.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvtestio.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvmm.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvodm_imager.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvtestresults.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvapputil.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvmm_utils.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvrm_graphics.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvos.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_image.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvddk_vic.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvomxilclient.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libglx.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvmm_camera_v3.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvmm_parser.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_audio.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvodm_query.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_utils.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvtnr.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvmm_contentpipe.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libjpeg.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvddk_2d_v2.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvdc.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libtegrav4l2.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvparser.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvsm.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvavp.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvtvmr.so: OK /usr/lib/arm-linux-gnueabihf/tegra/libnvrm.so: OK
for now I just don’t have rs232 to usb but I don’t think the user privilege could be different if logging in from network ssh or serial tty
This may actually be more simple than it sounds. The permissions of /usr/bin/sudo are copied from the sample rootfs…this means your sample rootfs was possibly unpacked without root permissions. Anyone can unpack any tar file…but for security, a non-privileged user cannot unpack a root file as a way to circumvent putting root modifications on a system when they are not really root. I believe you probably unpacked the sample rootfs without being root (or root authority via sudo). The system would not tell you it was translating ownership to non-root, it would simply do so silently.
Completely remove the content on your host of rootfs. Unpack and reinstall the sample rootfs into this using sudo or logging in as root first. Run the apply_binaries.sh as root as well (or via sudo). Re-flash.
FYI, there are stages in the install script where loopback devices, if they exist, work fine as non-root…but in cases where loopback devices or device special files must first be created, then root suddenly becomes required for that stage as well…for one person who has those files already, it will look like root is not required…but for other people in nearly the exact position, only root will succeed. All of this is related to creating or manipulating the loopback mounted device, including populating most of its content via the sample rootfs.
I have tested twice more once carefully to use sudo with extraction commands and once I have logged in with root and do the whole instructions again. but both fails. and again no gui and no suder privilege for ubuntu user.
I think you are correct about translating ownership of files. but using root or sudo do not solve it. I may use a live edition of ubuntu on usb to do the whole procedure to see what I get. but I think if it’s because of host OS (in my case debian) the developers should really consider this problem as a major bug.
If you use a virtual machine install, this too has caused odd problems. Is the host a regular linux installation, or does it use a VM or something special?
I’ve tested flash many times from Fedora (I do not have Ubuntu available) of all versions of TK1 L4T. In no case have I run into the sudo permission issue when using root for unpacking. Assuming there was no download issue, and no unpack or loopback mount issue, R21.4 works quite well…so something unusual is going on. Something difficult to spot, but unlikely an issue of the flash software itself.
There may be one other twist in the security story which gets in the way on the host…SElinux. I don’t know if you are familiar with SElinux, but file permissions are not the end of the story on all Linux distributions. SElinux is the addition of permissions via “role”, and not just permissions. Normally you would expect if a user has read/write/execute permission, then that attribute would not be blocked. However, SElinux labels exist which are not visible with “ls -l”. An example might be that a file in the web server directory tree is expected to be edited by a web administrator, and that root would be considered unusual and so root would be denied…or the reverse…a web administrator gets hacked, and tries to edit an ssh file, but is denied because the SElinux label thinks it is unusual for a web admin to alter ssh. Marking a file as SUID root (which is what this file uses) could be considered a security violation to be blocked.
SElinux has several levels on which it can be installed, varying in whether it simply makes loud noises in logs to say it doesn’t like something, or enforcing roles on critical parts, or enforcing every single role to the letter. I do not know what your Debian system is enforcing, but this could account for issues in unpacking files on the host, or in loopback mount. There may be a security log on your host which could be monitored while unpacking or flashing which gives a hint.
Just for testing, cd into your host’s L4T installer rootfs usr/bin/ and note the permissions in “ls -l sudo”. Then while logged in to Jetson, cd to /usr/bin/ and “ls -l sudo”…see what permissions this shows. Are they the same? Are they SUID root? They should be…if one of them is not then this is the failure point.
Also, are you able to see any dmesg output when logged in via ssh? There could be some other note, such as the newer L4T version not understanding the monitor query despite having understood from a prior version…but the sudo issue says there is something more going on.
Bingo, actually I don’t use a virtual machine but your help take me straight to the problem. However, It 's long time that I didn’t use windows OS but I keep my external hard disk NTFS frommatted, so that I could use it in other PCs without any problem and it is so long that I forget about it’s format. I do the instruction in my ext4 partition and now every thing works perfect. I think it would be worth noting this issue in the quick instructions.
Thank you so much, that is what a community mean.
This is actually one of the issues of the VM installs…if the file system does not support native linux file attributes, it can’t set them up right. This has caught more than one person off-guard.