Can't login via root user

Hello.

I use 32.6.1 Release on Xavier NX module.

Manual from developer guide:

$ tar xf ${L4T_RELEASE_PACKAGE}
$ cd Linux_for_Tegra/rootfs/
$ sudo tar xpf …/…/${SAMPLE_FS_PACKAGE}
$ cd …
$ sudo ./apply_binaries.sh

After these operations, I’ve created default user:

./tools/l4t_create_default_user.sh -u demo -p demo --accept-license

After system has booted, I can login to the system with login demo and password demo.
But when I try to login with root, it fails:

Ubuntu 18.04.5 LTS tegra-ubuntu ttyTCU0
tegra-ubuntu login: root
Login incorrect

How can I use root login?

This is the design of Ubuntu, and it is not a bug or flaw (it is, however, often irritating). This is considered better security that commands must use “sudo”. You can for example:
sudo ls
(this runs as root)

You can drop into a root shell based on your environment:

sudo -s
...do things...
exit

You can login as actual root via:
sudo su

It is also possible to unlock the root account after adding a password to it. My favorite is that on my development hardware that has Ubuntu (not the main system) I enable root login over ssh only, not locally, but I force it to use only keys, with no password available for ssh login.

If you are interested in things like unlocking root or setting up keys for ssh (useful in all kinds of remote issues), let me know.

Thank you for explanation.

I know the way, how to use root login via SSH.
But our client wants to use local root login.

I tried to set password for root, but result is the same: login incorrect
Screenshot from 2024-05-01 10-59-52

Could you please advise, how to unlock local root account?

Setting the password is only half of this. You also have to unlock root. Even if the account is locked you can set a password, and the “sudo passwd root” succeeding says sudo is indeed working correctly. The unlock is the part you have not completed (and there would be a separate ssh setup for net login, but it is very strongly advised that root is the first account remote network hacks attempt, so key-based auth for remote root is the only reasonable answer to that).

To unlock root:
sudo passwd -u root

After that local login would be available to root, but to emphasize, ssh login is a different step.

I’ve added this additional step, but root account is still unlocked.

Screenshot from 2024-05-02 10-07-04

I tried to reboot OS, it did not help.

Could you please advise me more on this issue?

It says “login incorrect”. I suspect there is something else going on. Can you try login via serial console to root?

What do you mean?
All my actions were from UART serial console via minicom.

Thanks for that information, I did not know which login method you used.

Are your regular user logins via serial console? In serial console, as your regular user, do you have any issue using sudo? It sounds like only root unlock is failing, but I want to be certain.

From your host PC, where you run minicom, what do you see from this:
echo $LANG
(I’m curious if there is a character set translation issue)

What do you see from this:
sudo passwd -S root

echo $LANG
en_IL

HOST PC side
sudo passwd -S root

root L 03/07/2022 0 99999 7 -1

Yes, regular user, and don’t have any problems with sudo.
Maybe, this additional information may help.
I can root login via ssh (after enabling PermitRootLogin yes):
Screenshot from 2024-05-03 11-39-55

I wonder, is your echo $LANG different when run from the Jetson, different from the host Linux PC? I could see a character language translation causing issues. However, the account is still locked. This never unlocked. The “L” would be “U” if it were unlocked.

Try again, make sure it doesn’t indicate failure; we’ll do it like this to be more certain:

# All of this is logged in directly, NOT via ssh.
sudo -s
passwd -u root
passwd -S root
exit
# (now try logging in directly as root)

I do strongly suggest switching to private/public key authentication for ssh to root.

Sorry for the delayed answer.

HOST PC:

echo $LANG
en_IL

Jetson via UART console:

echo $LANG
en_US.UTF-8

What does it mean, can it cause my root login issue?

And about your suggested commands:

Screenshot from 2024-05-06 09-51-55

Character encoding is actually one of the more complicated topics. Whenever two systems talk to each other, and when they agree on the character set, then it is easy to get them to work together. As soon as they differ you must agree on how to translate.

Many UTF-8 systems have the ASCII subset in common. Characters within that subset won’t be an issue. But let’s pretend that one UTF-8 has an accent mark, and the other does not; or that accent mark is represented with a different binary code. Then copy of that character for login password would either be a translation of the copy, or an outright wrong character. If your password has an issue with a character that might not be common to both, then it could be the issue, but not having root unlocked first would always cause failure.

Your last screenshot shows root is now available via password. This would be command line password. ssh has other requirements (it is possible to make root available to just ssh or just local console, but not both; or both, or neither).

If on that same login prompt you log in as your regular user, does that work? There is no reason a logged in user cannot again log in to the same login. I don’t see it asking for a password though, so is it asking you for a password and failing, or is the use of the name “root” failing immediately?

Yes, I’ve created default user demo. And don’t have any problems with it.

The behavior is strange.
System asks for login.
I put root.
System doesn’t ask for password, waits about 3 seconds, and output Login incorrect. And asks login again.
Another interesting moment.
After 1 minute, system outputs Login timed out after 60 seconds.
Screenshot from 2024-05-07 10-59-14

I’ve found the solution.

I added ttyTCU0 to /etc/securetty and root login works fine.

Thank you for support and explanations of Linux related issues.

Glad you noticed that! Yes, root is a special account. It has added security for each login method.

1 Like