Hi all,
I’ve done a goof and messed up /etc/sudoers when I was editing it (yes, I’ll use visudo next time).
Now I have no access to sudo. Whoops. Now I’m trying everything I can so that I don’t have to reflash my TX2!
Any way that I could get to root in my current state, to fix the sudoers file?
If I remembered correctly, there is a step during the TX2 installation where we have to mount the drive as root inside the bootloader. Is there any way to go back to that?
I also haven’t defined a password for root before… Is there a default root password? So I can run the su command to get to root on the console?
To preserve the existing install when root access is gone would basically require cloning the root partition, mounting it on you host under loopback to repair the file system (you could copy the sample rootfs sudoers file on top of the loopback version if careful to maintain permissions), and then flash again reusing the clone instead of generating a new image. This takes significant time since a clone takes longer than a flash (perhaps hours depending on partition size).
Ubuntu by default locks the root account. Only sudo can access root. I tend to use ssh keys for automatic login among my Jetsons over ssh, for which I typically unlock the root account, set up keys, then lock it out again…leaving direct key access to root without local password login (part of the account is still locked). I advise to only do this on a private network with no outside world access.
If interested in cloning you first have to get a modified flash.sh. You can mouse copy-and-paste this version:
[url]https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/post/5111893/#5111893[/url]
Actual clone command:
[url]https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/post/5110183/#5110183[/url]
Note that the alternate flash.sh adds the “-G” option. Otherwise this flash script functions the same as the original (probably this version will be provided in the next L4T release).
More information about clones is here…this is for a TK1 instead of TX2, but mostly the information applies:
[url]http://elinux.org/Jetson/Cloning[/url]
Thanks for the information!
I ran your clone command from your TX2 cloning discussion link, and got the my_backup.img. Now I am trying to mount it to repair the file system.
What is the proper way of doing the loopback mount for the cloned image?
I tried to run
sudo mount -t ext4 -o loop my_backup.img /mnt
like what the ELinux guide says for Jetson Cloning, but I get an error saying “wrong fs type, bad option, bad superblock on /dev/loop0”.
Running
dmesg
says “EXT4-fs (loop0): VHS: Can’t find ext4 filesystem”.
ehm
if we connect a Jetson in Force Recovery Mode to a Host ,we can use its filesystem as a drive with read-write access, as it seems to me. That hypothetically allows us to make changes and to restore root access, as it seems to me.
Your mount command should be correct, but there is a surprise with some of the clone commands. There may be both a “.img” file and a “.img.raw” file. If that is the case, then you need to use the “.raw” file (you can delete the “.img” and rename the the “.raw” to just “.img” prior to flash). The raw image is uncompressed, the img image is “sparse” (compressed). You cannot mount or directly manipulate a sparse/compressed image without some magic (something I run out of too often).
The “-S” parameter of a flash uses syntax such “-S 28GiB”. The exact byte size of the uncompressed image should be evenly divisible by 1024 until it reaches that size, e.g., in this example 28GiB case the uncompressed raw image would be “2810241024*1024” (30064771072) bytes in size…if you instead divide by 1024 the correct number of times you can verify the image size is valid. The sparse file will be much smaller if the file system isn’t filled up.
may be something like chroot /mnt/Jetson_partition could be used like in the instruction microHOWTO: Reset a forgotten root password using a live distribution
quote:
chroot into the root partition
The chroot command allows you to move the filesystem root to some subdirectory of the current root. In this case you want to move it to /mnt/recover:
chroot /mnt/recover
passwd
This effectively makes you the root user of the system to be recovered. For example, the file that was /mnt/recover/etc/passwd now appears as /etc/passwd. Any commands you execute will use binaries from the hard drive, not the live distribution.
The catch there is that he probably needs sudo to chroot, and sudo won’t work until the chroot is done.
Btw, recovery mode allows writing a region of bytes, but it does not understand a file system…you’d have to dd the specific byte offsets, hex edit the dd, then write those bytes back to the same spot. The advantage of clone is that the host PC does understand file systems, so you can change things using normal commands instead of byte-for-byte edits of raw binary data.
ehm, initially it was an instruction on how to recover root access[password] from a livecd.
If he have root access to Host OS and he mount Jetson in Force Recovery Mode that might grant him permissions to chroot.
the same instruction states:
It is possible to achieve the same effect by directly editing the password file. This is significantly more risky than using the passwd command, but may prove useful if you can edit files but are unable to execute binaries.
The file you need to edit is /etc/passwd. Each line is a colon-separated list of fields, the first two of which are the username and password for an account. Here is a sample:
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
In each of these four entries of this example the password field is set to ‘x’, meaning that the encrypted password can be found in /etc/shadow. If you replace the ‘x’ (or whatever else is in the second field) with the empty string then no password will be needed:
it seems that they say that editing the line to root::0:0:root:/root:/bin/bash will let use root with empty password
However, when booting in init 1/ single mode was impossible to explain to user, I used to use the livecd chroot method to reset root password over the internet.And It worked, as far as I remember.
The crucial point there is write or execute access which root of Host OS should be able of.
Linuxdev: If we have a Host OS and do mount a drive to it with a linux disrtibution which we have forgotten root password for - we still can do chroot under the Host OS presuming we have a root access for Host OS. Can not we?
Corresponding resources:
- rhel - How can we change root password? - Unix & Linux Stack Exchange
That excludes cases with encrypted partitions installations, though.
As Host OS any Ubuntu loaded with Jetpack could be used , as it seems to me, for the chroot operation.
Thanks for all your help!
Fixed the sudoers file and reflash it back onto the TX2
Now happily sudo-ing away again :-) and a backup image as a bonus
You could have edited the file without reflashing, if the jetson was connected via the mini usb to the Host OS and being in the force recovered mode!
Was already in the middle of reflashing when I saw your post @Andrey1984
Will keep that in mind for future though :-)
In the case of a live CD you are running under an alternate operating system with direct access to the drive…and running as root. If the Jetson had an alternate boot set up for use with serial console you could conceivably do the same thing…but unless you’ve already set this up before you run into trouble you would find yourself messing with U-Boot environment variables in U-Boot command prompt in order to reach another file system. Unless you already know how to do this it is faster and easier to just clone (not only would you be preparing a new rootfs on SD card, you’d also have to learn U-Boot command line…plus you can always keep the clone for a future backup).
Anyone messing with system files on a Jetson might find it useful to prepare ahead of time with an alternate SD card to boot to, and extlinux.conf already set up to allow serial console to boot to the rescue partition. Cloning just transfers the image to your more powerful PC host (from which it is trivial to rescue)…it isn’t really all that different than a live image.
So long as the environment you mount the system from understands the encryption (e.g., you have the password) there is no reason something like a live CD wouldn’t be able to work with an encrypted file system. It’s just a case of the kernel and environment of the alternate boot supporting it.