The plymouth login screen on my new/first Tumbleweed install only shows a single user name, and not the one I’d like it to default to. The only other option is to pull down “More …” and manually type in the desired user.
On previous installs (Leap, openSuSE, and SuSE dating back to 5.3) I’ve always tried to create two users at install: “marksuse” with all defaults, and my normal “mark” login. I do this both to have “marksuse” as a failsafe/fallback and because the “mark” login usually doesn’t work until its shell package and home directory are set up, post-install.
The Tumbleweed install seemed different from my memories of the last full Leap one I did. There didn’t seem to be a way to add multiple users or to change the user’s settings (UID, shell, $HOME). Maybe I missed something. In any case, I used the “Import User Data from a Previous Installation” option which worked to bring in both “marksuse” and “mark” from the Leap install on a different disk partition.
That might have caused the problem, but as described above I only have “marksuse” and “Other…” in plymouth. The Leap install (still bootable from GRUB) has “mark”, “marksuse”, and “Other…” and remembers the last login which it displays as the default.
How can I retroactively fix the Tumbleweed install? I’ve checked several YaST2 modules, starting with “User and Group Management”, and haven’t found anything appropriate. The Tumbleweed /etc/plymouth directory is empty, and although the Leap one has plymouthd.conf it doesn’t show anything about users in it.
Note also that I do not want to have “Auto Login”, or especially “Passwordless Logins”, as settable in the “Expert” options of “User and Group Management”. I realize this is all a small problem, and I’d ignore it on a desktop install where I log in once and stay logged in until a “needs reboot” software update or a power failure shutdown. But the Tumbleweed install is on a laptop which does get shut down and re-logged in each time.
(The forums were down for me for approx. 18 hours. Could not log in – kept getting “Unable to fetch configuration from identity provider. Please try again.” Change in authentication server and my ISP/DNS caching the old? Tried clearing browser caches, no help. I sent replies via the encoded “Reply to” email addresses in the notifications I received – not sure if those went through, but certainly not to the forum here. All very annoying given the quick and helpful replies I received here.)
Many thanks to @nrickert and @awerlang for their useful and possibly continuing help. Much progress but still no solution. To summarize …
Yes, I confused Plymouth (graphical boot output) and SDDM/lightdm/etc (graphical login screen). My apologies. (All of this tempts me to go back to booting runlevel 3 or its systemd analogue and using startx, or even better, xinit, but that would just let my Wndows/Mac associates sneer at Linux even more. So I’ll resist.)
This was an Xfce install, so yes, update-alternatives shows that lightdm is being used.
I’m hoping not to have to remove my “mark” login in YaST and recreate it, although in the end that might be the easiest path. With the proper options it hopefully wouldn’t wipe out my ~markhome directory but I’d prefer not to risk it.
I still don’t understand why the Tumbleweed install doesn’t allow setting advanced options (UID, SHELL) when creating a user login, or why it can’t create multiple ones at install time, but it’s not important – I can always modify/add them later.
Yes, my “mark” UID is 500, which was the standard back when I started in SuSE’s Jurassic period. I have literally millions of files scattered across multiple machines, disks, partitions, openSUSE installs, and backup media, and very much don’t want to have to change them or deal with the nightmare of having them get out of sync for any period of time.
Here’s where it starts to get good: /etc/lightdm/users.conf has minimum-uid=1000, so I changed it to 500. No change in login screen, even after reboot.
Nothing in modern Linux is so complicated that it can’t be made even more so. At least in this case it’s documented, so following man login.defs I added an /etc/login.defs.d/80-mark.defs file with UID_MIN 500. (The man page is out of date: It’s no longer a single login.defs file but instead the modern “*.d” directory scheme with individual, init-order-stamped files.) (Yes, I understand the advantage of having a global setting that all display managers, etc. share.)
No change, even after reboot. Is there some kind of “update configuration” utility I need to run to pick up a new /etc/\*.d/\*.defs files? The @{etc_ro}/login.defs.d/*.defs r, line in /etc/apparmor.d/abstractions/authentication implies that they’re searched automatically.
No problem: I gave up and added UID_MIN 500 to the existing /etc/login.defs.d/70-yast.defs file. But once again, no change even after reboot.
That’s where I stand. I’ve probably worn out my welcome here, but is there yet another place where I need to set UID_MIN, and/or is there a YaST module that can do everything that’s required?
$ man login.defs | grep -wA 1 'UID_MIN (number)'
UID_MAX (number), UID_MIN (number)
Range of user IDs used for the creation of regular users by useradd or newusers.
This is not related to login but to user creation, this won’t help.
Yes, I had seen that in /etc/lightdm/users.conf, which led me to first try it there anyway, and then my second/mistaken attempt with /etc/login.defs.d.
Check if you have such AccountsService on your system. If you do, that’s the place to configure UIDs for login.
Thanks for this next piece of the puzzle. Yes, I have AccountsService:
YaST Services Manager shows accounts-daemon is running (as does ps). I couldn’t find anything in YaST Sysconfig Editor’s “Display manager” section about user IDs, nor any way to add a new/additional setting/variable.
I looked through all the files listed from rpm -qil accountsservice, including:
None of them had any explicit “UID”/“1000”/etc, nor was there any obvious (to me) place to add something like that in either the plain or XML-like files.
It seems that the /etc/login.defs file is used in two ways:
To control defaults when accounts are created.
To control how the accountsservice accounts-daemon responds to D-Bus queries.
So they’re claiming that /etc/login.defs (or /etc/login.defs.d/*) is being used, not directly but rather via accountsservice. Doesn’t seem to be the case.
But also:
Since ubuntu sets a user’s group (GID) to be the same value as the user’s ID (UID) I found that I had to alter both MIN_UID and MIN_GID in /etc/login.defs to get accountsservice to reveal my login to lightdm.
I’d seen that before but passed it by. Hoped for the Nth time that it would be the magic, because I’d also changed both logins to be in the classic “users” group, 100. (This Tumbleweed install is the first time I’ve seen users get their own group ID matching/equal-to their user ID.) Once again, I have millions of files with GID 100 that I don’t want to change. And I can’t understand the logic of having every user in their own group. The closest that makes sense to me is if you wanted to create “user-subgroups” where users have access to their own group’s 0640-permission files but not those in a different subgroup.
Doesn’t matter what I think. Anyway, in another desperate attempt I tried adding GID_MIN 100to /etc/login.defs.d/70-yast.defs. Still doesn’t help, even after a reboot.
I should probably take @nrickert’s advice and give up, although in my case that will mean accepting that I can’t have my login in the display manager, not changing my login and all the files. If your infinite patience allows and you have any further answers, I’m all ears. Thanks.
I’m not familiar with accountservice, Plasma/SDDM for instance does not requires it. You could try removing it, if nothing important relies on it. Then lightdm might use its own configuration.
Also I don’t think GID should matter. All my user’s GID are below 1000.
I used YaST Software Management to remove accountsservice and accountsservice-lang (miraculously nothing else depended on them so no YaST complaints) and immediately on exiting my window manager and going back to lightdm, “mark” was the first/default user (with “marksuse” optionally underneath it). Perfect! Remembers the last user logged in, and their last window manager, just like it always used to.
Thanks for your unflagging help which finally led to a solution!
BTW, have I ever posted here how much I hate D-Bus? Why use those old-fashioned UNIX configuration files when we could have a complicated message passing middleware system instead. We could call it … I don’t know, “The Windows Registry” … no, that name’s already been taken. But anyway, instead of having applications agree on locations and formats of config files they could all use the same binary tokens and complex APIs to do the same thing. Much simpler and better!
Somehow, numbers 2 and 3 of “The Zen of Python” (“Explicit is better than implicit” and “Simple is better than complex”) come to mind. I’m looking at you, Wayland. But as I said above, nobody’s interested in my cranky old opinions.
In my not so humble opinion, the Windows Registry is an architectural disaster – despite having extremely revered colleagues with the opinion that, because “everything is being held in a central database”, it’s “better” …
From a system point-of-view, “everything-in-one-place” is doomed to disaster:
Single point of failure.
Performance limited by the time needed to search for the “key needed NOW” …
When the system is really broken, it’s not possible to repair the thing from a minimal system with a simple, minimal, CLI text editor.
“Old fashioned” UNIX® configuration files are from a system administration and maintenance point-of-view loaded with the following advantages:
At system boot time they’re fast – modern disks have high read rates – directory access is fast …
Simple, fast, recursive text searches can quickly determine the current values of system parameters.
“Old fashioned” UNIX® CLI tools are fast …
Administrators who use CLI text editors typically finish system configuration tasks much faster than those administrators who rely on graphical tools to access configuration parameters in databases.
Typically a Redmond system administrator can deal with about 50 machines.
A typical UNIX® system administrator manages at least 100 machines – with the SUSE S.A. system administration tools, a system administrator can handle at least 10 times the number of machines managed in a “traditional” UNIX® system administration environment.
And, yes, we need graphical system monitoring tools because, with graphical presentations we can more easily see dynamic system performance parameter values but, that’s not system configuration.
“D-Bus was conceived as a generic, high-level inter-process communication system. To accomplish such goals, D-Bus communications are based on the exchange of messages between processes instead of “raw bytes”. D-Bus messages are high-level discrete items that a process can send through the bus to another connected process. Messages have a well-defined structure (even the types of the data carried in their payload are defined), allowing the bus to validate them and to reject any ill-formed message. In this regard, D-Bus is closer to an RPC mechanism than to a classic IPC mechanism, with its own type definition system and its own marshalling.”
The high-level inter-process communication results in huge benefits for everybody.
systemd simplifies system administration. My cheat sheets now fit on the back of few envelopes.
I regret having posted my off-topic rant about D-Bus. It was written after giving in to my frustration about having wasted two days imposing on the time and generosity of several experts here to solve one stupid little problem (that nevertheless would have driven me crazy at every login if I hadn’t). But I did, and it received responses, so I’ll continue a bit longer.
First, though, I can’t find a way to publicly flag a post in this forum software. Failing that, I’ve posted #17, above:
Hopefully that might help someone searching the same problem in the future.
Continuing on with the software philosophy discussion …
“D-Bus was conceived as a …
…
The high-level inter-process communication results in huge benefits for everybody.
I respect your opinion but we’ll have to “agree to disagree”. You’re in the majority so your way has won out.
Cars come with CAN BUS. Desktops use D-Bus:
Ironically, my main interests at this point in time are in the embedded arena, so I am somewhat familiar with CAN BUS. I haven’t used it, mainly because its PHY (electrical level) interface requirements (voltages, drive currents, capacitive loading) preclude its on-chip inclusion in the low-end MCUs I’m working with.
But as relates to this discussion, its complexities (mailbox addressing, etc) were overkill for my requirements. I instead implemented my prototype hardware using both the far simpler I2C and a custom open-source protocol that I released publicly on GitHub. Similarly, D-Bus, despite its capabilities you cite, in this current example replaces a perfectly functional, canonical UNIX implementation using configuration files with an entire software ecosystem that has been shown here to be fragile and very difficult to debug when problems do arise.
systemd simplifies system administration. My cheat sheets now fit on the back of few envelopes.
Again, agree to disagree. I don’t complain about systemd because I’ve never been bitten by it, whereas this isn’t the first time I’ve run into trouble with D-Bus. Yes, I like how fast a systemd-based implementation boots but question whether that speed couldn’t have been achieved with careful tuning/rewriting of SysV init. I’m “above my pay grade” here, but although the <whatever>-init process runs in single-user mode at boot time, can’t it still fork off multiple processes? I thought systemd’s speed came from parallel execution of init tasks, but why can’t/couldn’t SysV do that also? Shell script execution is slow? I’m sure everything init does is I/O, not compute, bound. SysV requires dozens of auxiliary programs (grep, sed, awk, etc) vs systemd having everything in a single one? Isn’t there that package that has all the common utilities in one binary executable? I know there are tools to examine and modify systemd (likewise D-Bus) and they’re certainly included in rescue systems, but that requires more to be functioning than with config files and vi or nano or some even more minimal text editor. The list goes on and on, but all of this was virulently debated 10(??) years ago with the introduction of systemd, and its subsequent almost universal adoption (at least in the mainstream distros) makes it a moot point.
MINIMUM_UID is set at compile time and cannot be changed at run-time.
<sarcasm>Well that’s just wonderful.</sarcasm> I was thinking this was a bug where accountsservices wasn’t reading (or correctly reading) its configuration files so it wasn’t communicating the correct value via D-Bus, but this says it’s a design flaw/omission. So I get all the complexity, implicitness, and resistance to debugging/analysis of the D-Bus-based accounsservices implementation and it’s still missing an important-to-me capability that the config file system it subsumes provided?
Please be aware that, I occasionally use at least one of 3 flavours of sarcasm –
Antipodean;
English – as in the “West European Islands”;
German.
If you’re working on automotive firmware then, you’re used to Embedded Real-Time system constraints –
Which are not the same Use Case as that which is typically used for Desktop or Server environments.
Embedded and Real-Time: limited hardware (CPU, Memory, Storage, Power and, everything else … ).
Each system is specific to the particular hardware instance – there’s no universal solution …
Desktop and Server: finance is the only limitation on hardware and, “one software architecture has to fit everything” …
In other words, even if you don’t see the need for something on your Desktop or Server, the rest of the world is using it on their Desktops and Servers …
I agree that open source bug reports, and particularly feature requests which you’ve implied that this is (see below), should whenever possible include a patch/fix (or funding for someone else to work on one).
Unfortunately my time for working on open source is finite and already overbooked on other projects by a large factor. (My finances preclude contributing via the second option.) I have three machines that have been running Leap for many years without any major problems that I now have to upgrade to Tumbleweed (or a non-SUSE distro) because my projects require me to move beyond Leap’s 4.x kernels, gcc 7, Python 3.6, etc.
I started this thread with one Tumbleweed problem but have since come across several more that are even worse and will likely be even harder to solve. I have a workaround for this one, so I need to move forward.
Out of curiosity, and in case I do open a report, what is your source for that statement? Is it a direct quote from documentation or code, or is it your own meta-analysis? A quick browsing through the code at the freedesktop source repo reveals:
$ find . -type f | xargs egrep -i 'minimum.*(user|id)'
./meson_options.txt:option('minimum_uid', type: 'integer', value: 1000, description: 'Set minimum uid for human users')
./src/user-classify.c: return uid >= MINIMUM_UID;
./meson.build:config_h.set('MINIMUM_UID', get_option('minimum_uid'))
which strongly implies that it is intended to be user/runtime/whatever configurable, not simply hard-coded in the application/service binary.
Again, bug vs feature, and upstream vs. openSUSE (maybe the Tumbleweed package is built from a different git tag/sha1 than the current freedesktop one?).
At least in this case it’s documented, so following