hi, everybody! i flahsed the Jetson TK1 Board according the Quick Start Guide, and i seemed successfully. when i put ‘sudo’ at terminal, it promot “sudo : /usr/bin/sudo must be owned by uid 0 and have the setuid bit set”.
why? and how can i resolve this?
thanks!
by the way, i used the version 19.2.0 of the L4T.
My sudo permissions:
root@tegra-ubuntu:~# ls -l which sudo
-rwsr-xr-x 1 root root 111780 Feb 1 2000 /usr/bin/sudo*
Flash may have failed to set permissions correctly. If your permissions don’t have the SUID root, this may be why.
Thank you for your explaination, linuxdev!
I flash the target 4 times, the result are all same.
how can i resolve this problem.
PS:
when software center update the software automatically, a internal error reported.
thank you very much!
Did you extract the file system with tar -xpf .tbz2 ? That p is very important when you extract it - it tells it to keep permissions that were there in the tarball - to do so, you’ll need to extract the rootfs as a root user (or via sudo) otherwise it can’t keep the permissions.
On some systems, you may need to do tar --numeric-owner -xpf .tbz2 - Saw this a lot when working with ubuntu based systems from non-ubuntu based systems - mostly because some systems don’t have the same users/groups, or the users/groups don’t exist on the host system.
Hi steev, thank you very much!
I did used -xpf parameters to extract the file system via sudo.
Did you try this
This problem is caused sometimes when the permissions of the file, /usr/bin/sudo get set to 777. If you do something like chmod -R 777 /usr/, you can do this. It effectively ruins sudo. Here is the solution if this is your problem, and the accepted answer doesn’t work:
To fix:
Restart pc, press shift at boot menu.
This should bring up GNU GRUB (ie recovery mode) menu.
If this doesn’t work, just restart mid boot and choose recovery mode when prompted on next launch.
Select the line which starts with Advanced options
Select the topmost version of the OS ending with (“recovery mode”)
Press enter
In the following menu, go down to “Drop to root shell prompt”
Type the following:
mount -o remount,rw /
mount --all
chown root:root /usr/bin/sudo
chmod 4755 /usr/bin/sudo
restart
This should restore sudo privellages.
There is no grub on the Jetson, so you’d likely have to boot from an sdcard and then make the change to the eMMC filesystem.
I was afraid of that, but I’m not where I could get to the board.
For giggless did you try this in terminal:
chown root:root /usr/bin/sudo
chmod 4755 /usr/bin/sudo
I’d vote for this as well, but I have to wonder if this brings up the conundrum of how to copy a file which requires sudo root access…if sudo doesn’t work. Maybe with JTAG?
One very big reason for my wish to have an extended u-boot which allows optional booting to SD cards and such simply through a boot prompt and boot environment is to make it less risky to test changes which might break something important. If we could boot to an SD card even with a previous hosed eMMC flash, it’d be very easy to recover.
Yah, but there’s a bigger problem for idiots like me. There is no place to download the factory image. The L4t available is not the factory image nor does it have the same file system and scripts. So, in my case at least, not the op’s, even being able to boot to an sdcard or usb drive wouldn’t have helped much. If I’d have made an open box back up, like a smart person, that would have been a different story.
The L4T does have the “apply binaries” script which I think adds CODECs and/or firmware/configuration. I have not checked what the differences are, but I am curious what you’ve found.
The current L4T is listed as version 19.2, there may be a version change between that and what you have. Not long ago I picked up some nVidia embedded hardware when R16.3 was current.
The big problem (as I see it) is the L4T does indeed have apply binaries - however, if you take the sample rootfs, and boot it, run apt-get update && apt-get dist-upgrade, it upgrades the mesa libraries, which then overwrites some of the files/symlinks that the apply binaries script did. Realistically, if it was all packaged up the way that cuda is, so that you add a repository and their graphics implementation did a replaces, then it could/would be easier to work with.
Building a bootable sd card isn’t too difficult, and it’s possible to boot one without modifying anything on the board itself. I did a very quick write-up for Gentoo users but it can be easily modified for other users (basically, just replace anywhere that it says CROSS_COMPILE=armv7a-hardfloat-linux-gnueabi- with your own cross compilers - Debian/Ubuntu it will be arm-linux-gnueabihf- and I can’t recall the tuple for Fedora but if you use Fedora it’s easy to find out.
[url]http://elinux.org/Tegra/Mainline_SW/Gentoo_From_SD_Card[/url] is the write-up.
All you really need is a basic mount of the eMMC and changing the sudo permissions, but it definitely sounds like more than just the sudo binary’s permissions will be incorrect.
I’d suggest re-doing the extracting of the rootfs tarball as root on your host system, and adding --numeric-owner before the -xpf extraction.
Hi, Steev!
I tried to use the --numeric-owner befor the -xpf, but the reslut is same.
my linux version of my host pc is unbuntu 14.04, and my sequence is as following:
1.sudo mount /dev/sda3 /home/cuizhili/mydata //my <rootfs.tbz2> is place on the /dev/sda3/TegraK1
2.cd mydata
3.cd TegraK1
4.sudo tar --numeric-owner -xpf Tegra124_Linux_R19.2.0_armhf.tbz2
5.cd Tegra_for_Linux/rootfs/
6.sudo tar --numeric-owner -xpf …/…/Tegra_Linux_Sample-Root-Filesystem_R19.2.0_armhf.tbz2
7.cd …/
8.sudo ./apply_binaries.sh
9.put the tegera tk1 board into ‘recovery’ mode
10.sudo ./flash.sh -S 8GiB jetson-tk1 mmcblk0p1
11. about 2 hours later, the flasing finished.
- the tegra tk1 board automatically reboot
- reset the tegra tk1 board mannually
- input the sudo apt-get update, it promot following:
sudo :/usr/bin/sudo must be owned by uid 0 and have the setuid bit set
You could try setting the correct bits on sudo after you apply_binaries but before putting the board into recovery mode and flashing it?
check if /dev/sda3 (the mount where you extract l4t for flashing) is a linux partition. if it’s ntfs or fat, it could be that the permissions and/or owners are screwed up there.
post the output of:
ls -la mydata/Linux_for_Tegra/rootfs
Thank you all!
I can use sudo command now. My /dev/sda3 is not a linux partition. I moved the <rootfs.tbz2> to the linux partition, and extracted and flash the file to the jetson-tk1, then the sudo worked.
But there are still problems:
1, when software center updates the software automatically, the internl error occures.
2, when shut down command comes, the log out window comes.
I’m having a very similar problem, possibly the exact same problem as the last post.
I recently re-flashed my Jetson board to the 19.2 firmware. The two symptoms in the previous post are occurring. Clicking shut down goes to the log out screen, and software center won’t install software.
It appears that anything from the GUI that requires privilege escalation doesn’t work. For example, the set time screen is grayed out and clicking on “User Accounts” just crashes.
“sudo su -” from a command line works fine though.
Any ideas?
I have graphics set up, but tend to not use it. However, sometimes I do use this, but tend to start commands from a shell (even remote serial console). If you export the DISPLAY variable (export DISPLAY=:0.0), then any GUI command you run will run as the user who runs this, and display in the GUI. So for example, I always log in then do “sudo -s”, then set DISPLAY. From then on it won’t matter who the GUI uses as an ID, whatever you run from command line that is a GUI program will show up normally on the desktop and run as root. Think of it as a workaround until figuring out GUI setup.
I figured it out. The “dbus” package was corrupted, or just had bad permissions. Doing this fixed it:
sudo dpkg --remove --force-all dbus
sudo apt-get install dbus