Oh, right. You're on Mint. Forgot about that. Sorry.
Ubuntu (including, I assume, derivatives like Mint) disables the regular root by default.
My main path has been Red Hat > SuSE > Slackware > Debian, so I forgot about that little Ubuntu quirk.

If you were more comfortable at the command line, and/or had a deeper understanding about how computers work, I'd have suggested making a Slackware based live distro instead. Slackware has always been very conservative with the changes it makes to its included packages, so things generally have fewer quirks. OTOH, there's ZERO handholding for beginners in Slackware, and no GUI config tools where simple text files suffice.
Great for experienced programmers or sysadmins who don't mind getting their hands dirty.

But I realize its a bit late in the game for you to consider switching horses.

The all caps wasn't intended to be rude in this context, but only intended to emphasize importance, and I didn't know a better way of doing that. I could have used bold but would that have been better or worse? I actually do appreciate very much that you're helping me, and I'm sorry if that has been misconstrued in any way. It's just that it seemed like you still didn't understand the methods that I was attempting or why I was attempting them that way, even though I had explained them. I'm not complaining about that, because sometimes people just misunderstand things - alright, fine - I can accept that. But the reason why I write such long posts is because without enough detail it would be even easier to misunderstand or misinterpret things. So I thought it was important to write one long post that just summarized the whole issue, and draw your attention to it so that in the long run, it would save us both a lot of time and frustration, because we wouldn't keep misunderstanding each other. Alright? Again, sorry if it came across as rude, but I didn't know how else to do it. And thanks again for all your help, but as you can see, I'm still having problems, and it is rather frustrating.

I've been using adduser rather than useradd, because I think it's supposedly more compatible with Debian distributions.

I read the Arch wiki page about sudo and sudoers and that stuff, but lately I've been trying to force the root account to use the manual login rather than doing it automatically, which I think makes sudoers a moot point, at least for that particular method (and for some reason, when I'm in Cubic the default user is named "root" but then once I make the ISO and boot it, the name seems to have changed to "mint" - are these the same user or two different ones?).

I changed the password by doing moduser -p abc root, and I dont' know whether the password change necessarily worked or not, but I know that it's not requiring me to type the password when I log in, which is what I need it to do.

I didn't get the output of sudo -ll (sorry, but I could get it if I'm logged in as the root, though when I try the other method as a secondary user I can't get it because I can't access the disk to save a file, and the Internet is also disabled in the ISO, so I have no way of saving the text to get it to you - so I hadn't even thought of getting it while I'm the root user, but thanks for the tip).

There does not seem to be any user names mint while in Cubic - only a user named root, and then only mint in the booted ISO. It's almost as though it automatically changes the name or replaces the account. I'm not sure how a root user is different than an admin user, but in any case, when I log in as root/mint/whatever I seem to have unrestricted access, so I suppose it is in fact a root/sudo user.

I haven't the slightest idea how Mint would add a mint user or whether/how it would get into lightdm, or why it would alter or replace the root user with mint, but I didn't say mint doesn't have a password necessarily - I just said it automatically logs in without requiring me to type a password.

I didn't check the sudoers file but that's a good idea. I'll check that and the lightdm files and anything else that seems relevant that I can think of.

Again, I'm sorry if my tone came across as rude, but it wasn't meant to. I only meant it to signify importance. And I was trying to be as clear and concise as possible, and I even listed specific commands that I did. In fact, here's the newest thing that I tried, from the Cubic website:



I just did it again, and it sort of half fixed the problem, but not really. This time the login screen displayed (so autologin must have been disabled) but the password didn't work, and instead it wanted a user name. If I entered any random thing then it wanted a password after that, but if I typed "mint" as the user name then it logged in automatically without a password! So that's still no good. Cinnamon still crashed and reverted to Mate, but this time there were no icons on the desktop and when I right-clicked on it nothing happened. Here's how I configured it:

usermod -p abc root

mkdir /home/mint
mkdir /home/mint/.config

Then I copied the dconf directory that I had backed up into this .config directory.

rm /usr/share/initramfs-tools//scripts/casper-bottom/15autologin
rm /usr/share/initramfs-tools//scripts/casper-bottom/25adduser

I created the /etc/lightdm/lightdm.conf file as shown here:

[SeatDefaults]
allow-guest=false
autologin-guest=false
autologin-user=
autologin-user-timeout=0
greeter-show-manual-login=true

Then I modified the /etc/lightdm/lightdm.conf.d/70-linuxming.conf file and put the same text into it, except that it already had a line after the [SeatDefaults] which said:

user-session=cinnamon

So I just left that there and pasted everything else after it.

I tried service lightdm restart and I think that's when it gave me a list of files that it was updating relative to lightdm, including /etc/lightdm/lightdm.conf, even though it was a new one that I added, so I took that as a good sign. It did say something about changing [SeatDefaults] to [Seat:*], but I didn't know if I should go back into the two files that I changed before and alter them again, so I didn't, but I can try it the next time if it's a good idea.

update-init-ramfs -u

By the way, there also seems to be a live-update-initramfs, but I don't know whether that would work better or not, so I didn't use it.

I didn't do this line:

apt install --reinstall linux-headers-5.4.0-26 linux-headers-5.4.0-26-generic linux-image-5.4.0-26-generic

Because above you said I only need that if it's broken or missing.

So then I went to the next step and used the regular kernel (the only one listed, actually), and booted, and that's when I got the results I described at the beginning of this post.

Did I still somehow do something wrong?

At this point I seem to be getting my hands fairly dirty, anyway, but you're right about switching horses. I don't even think Cubic would work with Slackware, and I'm almost finished! This is really the final thing that I need to fix!

I tried booting into that one again, and this time the icons displayed on the desktop (though clicking on them did nothing), and I could right-click and get a menu. I created a new document and it didn't appear, but when I opened the desktop in a folder it was there, and nothing else was there (but the only things on it were "Computer", "Home", "Trash" and mounted drives, so I think those are all just implied shortcuts anyway). Also, the desktop seems to always show the same background with no slideshow (I had configured the dconf with a slideshow), which isn't a big deal, but it's an observation of an anomaly.

But then I checked various files to see if they were configured properly:

/etc/lightdm/lightdm.conf still says exactly what I had put in it:

[SeatDefaults]
allow-guest=false
autologin-guest=false
autologin-user=
autologin-user-timeout=0
greeter-show-manual-login=true

And /etc/lightdm/lightdm.conf.d/70-linuxmint.conf still says the same thing as that file, except with the extra user-session=cinnamon just after the [SeatDefaults].

I checked /etc/passwd and it seems pretty much the same as default (root is still there at the beginning) but with the addition of a mint user at the bottom which I didn't add, so it must have happened automatically:

root:x:0:0:root:/root:/bin/bash
...
mint:x:999:999:Live session user,,,:/home/mint:/bin/bash

But when I type the user name root, and then give it the password I assigned, it doesn't work, so the only way I can log in is by typing mint, but then it doesn't ask for a password and logs in immediately.

15autologin and 25adduser within /usr/share/initramfs-tools/scripts/casper-bottom folder are both still gone, as they should be. However, there are a couple that begin with 25 (25configure_init and 25disable_cdrom.mount); I don't know whether that's a problem or not.

I did a service lightdm restart and it made me log in again, but then after Cinnamon crashed again, the desktop icons appeared correctly, and I could add files directly to it, but the slideshow still doesn't work (again, it's not a big deal, but I'm just being thorough in case it's a symptom).



Here's the sudo -ll:

Matching Defaults entries for mint on mint:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin,
pwfeedback

User mint may run the following commands on mint:

Sudoers entry:
RunAsUsers: ALL
RunAsGroups: ALL
Commands:
ALL

Sudoers entry:
RunAsUsers: ALL
Options: !authenticate
Commands:
ALL

Sudoers entry:
RunAsUsers: root
Options: !authenticate
Commands:
/usr/bin/mint-refresh-cache

Sudoers entry:
RunAsUsers: root
Options: !authenticate
Commands:
/usr/lib/linuxmint/mintUpdate/synaptic-workaround.py

Sudoers entry:
RunAsUsers: root
Options: !authenticate
Commands:
/usr/lib/linuxmint/mintUpdate/dpkg_lock_check.sh



That's all the information I have. Can you see what's wrong?

How did you come up with that? I don't know about mint but that is the wrong way to change password, on every distro I've used, unless you know how to manually encrypt a password.

The correct command to use is passwd, which prompts for a password (twice), and encrypts it for you in the proper format.

EDIT: here's the result of using usermod -p here's the result of passwd: As expected, passing an unencrypted plain password to usermod -p leads to it being impossible to log in with a password.

Really? That's good to know!

But actually, it's not entirely consistent wth my experience, because I can log in even when I set the password that way, but it's because it seems to log in automatically (as root or mint), but then if I manually log in as a different user then I can do it, but then it refuses to validate the password for sudo access (or I don't have the priveleges for that, even though I set -G root and -g 0 using usermod, so I don't know what's going on there). But when I manually create a mint user (I'm trying to get ahead of the automatic creation so that I can personalize it rather than going with the default that it gives me), I set the password during the adduser, so I guess that's encrypted (in the passwd file it says "x" rather than the password itself). But that still doesn't seem to solve my problem.

Sorry I can't keep track of what's your current problem. Between all the this happened and that happened and I did this and that and so on .. somewhere you said you tried to log in as root and gave the password you assigned (how exactly? usermod -p?) and that it didn't work. I assumed you did not use adduser to add the root user..

But here is some rope for you:

1) If an account has no password, you can log in without a password. So I assume your mint user has no password.

2) If you want to observe the encrypted password, or abc, or no password, the right file to look in is /etc/shadow, not /etc/passwd. (/etc/shadow is only accessible to root, because it contains the secrets, while /etc/passwd is world readable and just contains all the non-secret account information)

3) Some distros have the root user disabled (or locked) by default. That means you cannot directly log in as them with a password, and you can only obtain their credentials indirectly e.g. via sudo or some other mechanism that grants you access. Locking is usually done by prepending an exclamation mark in front of the password hash, which you would see in /etc/shadow. passwd command can lock (-l) and unlock (-u) users for you.

4) sudo asks (by default) for the password of the user who is executing the sudo command, and not for the password of the user that sudo would run the command as. IIRC this can be changed though, and it is possible to add support for running commands with sudo without a password, if you need it.

5) If you just want to "test a password" and see if you can log in with it after changing it (or unlocking / locking whatever), I would recommend the su command, as a normal user (on some systems that user must also be in the wheel group).

6) I don't know why you're adding a user to the root group, but it's almost definitely not doing anything useful for you. If you need root permissions, being in the root group isn't going to help much. If you don't need root permissions, being in the root group would be very weird.

Thanks for the information - it clears up some things.

To summarize, I'm still trying to give the live mode custom ISO (made with Cubic) a secure login, for a user that can do sudo, but I've tried two methods and neither work:

- Using the root account allows unrestricted access, but I can't get it to force a person to type a password to log in - it just logs in automatically, even though I've done everything imaginable to try to disable auto-login!

- Making an extra user and putting it into the root group doesn't seem to work either, because even though it requires a password to log in (which is good), it also requires a password to do almost anything (even mounting/unmounting/ejecting drives), which is fine I guess, except that the password never works, which means that either the password is somehow wrong (but that wouldn't make sense, because I used it to log in), or the user just doesn't have root/sudo access (even though I added the user to the root group).

My latest idea is to add the user to the sudo group! I just found this, and checked on my HD Mint installation (which I'm running now, and works the way it's supposed to), and my current user account does in fact belong to the sudo group! The reason I didn't think to use this group earlier is because it doesn't seem to exist by default when I open the ISO in Cubic (in fact, I only noticed one group there - root). But if I create the group with the same ID (27) as it uses on my HD, and add a new user to that group, then I think (fingers crossed) it should work. Is my idea sound? I was planning on using these commands:

addgroup --gid 27 sudo
adduser xyz

Then I'll type the password or any information. Would that enable me to log in with a password but then also be able to access the sudo/root stuff once I do? As it is, without being able to do that, I can't even access my HD or any drive other than the one on which Linux is installed!

OMG, you're not going to believe this!

I actually fixed it and you wouldn't believe how easy it turned out to be! All I had to do was create a new user and assign it into its own group (the one with the same name as the user, which is created with it by default), and also the sudo group! I didn't make sudo the primary group though, but it still works great!!!

I think that's the absolutely final thing that I needed to do to get this thing working!!!!!