Default user(s) on plymouth login screen

English Install/Boot/Login
3

When I added a second user, my login screen looks like - new user showed up automatically

Is that what your login screen looks like ?

20230510_185951-01

4

If you are using KDE Plasma (consequently SDDM as display manager), verify SDDM settings:

  • Open System settings
  • Startup and Shutdown
  • On the Login Screen (SDDM) page, click the Behavior button on the bottom-left

Take a note on the minimum and maximum user UID (sic).

What are your UIDs?

$ id mark marksuse

Make sure they fall within that range (inclusive).

5

(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 …

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

  2. This was an Xfce install, so yes, update-alternatives shows that lightdm is being used.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. Nothing in modern Linux is so complicated that it can’t be made even more so. :wink: 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.)

  8. 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.

  9. 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?

Thanks again.

6

I usually create 3 users.

For many years, I was using 600, 601 and 602 for their UID.

But I gave up. It wasn’t worth the effort. So I now use 1000, 1001, 1002.

7 
$ 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.

From https://github.com/canonical/lightdm/blob/main/data/users.conf:

# NOTE: If you have AccountsService installed on your system, then LightDM will
# use this instead and these settings will be ignored

Check if you have such AccountsService on your system. If you do, that’s the place to configure UIDs for login.

8

@awerlang wrote:

This is not related to login but to user creation, this won’t help.

Thanks for clarifying.

From lightdm/data/users.conf at main · canonical/lightdm · GitHub
If you have AccountsService installed on your system, then LightDM
will use this instead and these settings will be ignored

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:

$ rpm -qa | fgrep -i accountsservice                            
accountsservice-lang-0.6.45-lp151.6.3.1.noarch
accountsservice-0.6.45-lp151.6.3.1.x86_64
$

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:

/usr/lib/systemd/system/accounts-daemon.service
/usr/share/accountsservice/user-templates/administrator
/usr/share/accountsservice/user-templates/standard
/usr/share/dbus-1/interfaces/org.freedesktop.Accounts.User.xml
/usr/share/dbus-1/interfaces/org.freedesktop.Accounts.xml
/usr/share/dbus-1/system-services/org.freedesktop.Accounts.service
/usr/share/dbus-1/system.d/org.freedesktop.Accounts.conf/usr/share/polkit-1/actions/org.freedesktop.accounts.policy
/var/lib/AccountsService/icons
/var/lib/AccountsService/users

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.

I haven’t found much online to help. The closest was https://askubuntu.com/questions/98323/how-does-accounts-service-work-with-lightdm which claims:

It seems that the /etc/login.defs file is used in two ways:

  1. To control defaults when accounts are created.
  2. 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.

9

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.

1 Like
10

YES!!!

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.

Thanks again for solving this problem for me.

11

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.
12

“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.

13

Xfce is based on GTK.

  • Why are you using a Qt based Display Manager?

Please be aware that, for Xfce the preferred Display Manager is LightDM.

14

Cars come with CAN BUS. Desktops use D-Bus:

“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.

15

MINIMUM_UID is set at compile time and cannot be changed at run-time.

17

SOLVED!!

See post #9 in this thread:

And post #10:

18

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 …

@dcurtisfra wrote:

“Old fashioned” UNIX® configuration files are from a system administration and maintenance point-of-view loaded with the following advantages:

You do realize that I was attempting sarcasm in my comments and that you and I agree totally, or almost so, on these topics?

Xfce is based on GTK.
Why are you using a Qt based Display Manager?
Please be aware that, for Xfce the preferred Display Manager is LightDM.

???

I thought it was clear in the posts that my stock Tumbleweed/Xfce install is using LightDM. (Thanks again to @awerlang for helping me discover that).

@karlmistelberger wrote:

“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.

Probably the same thing for D-Bus.

@arvidjaar wrote:

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?

Anyone wonder why I’m not happy?

19

No.

You are barking up the wrong tree. If you believe it is so important to have, open bug report for the accountsservice project or better submit patch.

1 Like
20

OK – I’m slowly getting used to your style.

  • 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 …

21

It was a rhetorical question.

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.

But if I do file a report, should I do so upstream at freedesktop or here at openSUSE Bugzilla?

Also:

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

22

Not a problem. I should have remembered that subtleties like sarcasm don’t communicate well in written/online media, particularly when there are language barriers involved. (No offense intended – from your statements and your profile I assume English isn’t your native language, although you write in it better than many native speakers.) (One of my favorite jokes: “What do you call someone who speaks two languages? Bilingual. What do you call someone who speaks three languages? Trilingual. What do you call someone who speaks only one language? An American.”) I fall into that last category. :frowning:

Other embedded areas (not automotive), but yes, I’m painfully :wink: aware of realtime constraints. In any case …

I have no objection to the inclusion of software and systems that I personally don’t need. But in this case the implementation of one of those systems – an implementation whose architecture I philosophically disagree with – cost me and others who helped me (including you) a lot of wasted time.

In the end it looks like the problem was caused by either a bug or an unimplemented feature. But again, my philosophical objections are based on the fact that either the software doesn’t support a capability that was in the system that it was designed to replace, or if it is a bug that the architecture itself made identifying the bug very difficult.

As per my other post I need to move on to solving the further/worse problems I’m having with Tumbleweed, but again I thank you for your interest and time. And I’ll continue to monitor this thread and possibly respond to anyone who wants to continue this secondary conversation.