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