Warn when a desktop profile's greeter can't log in without a regular user

[dylanmtaylor]

Feature:

Installed with broken login:

Some display managers (currently SDDM) only show users with UID >= 1000 in their user picker and don't provide a manual username entry by default. If a user selects a desktop profile that uses one of these greeters but doesn't create a regular user, they'll be unable to log in via the graphical greeter after installation.

This adds a warning after the configuration confirmation step:

The desktop profile you have selected needs a regular user created to log in.
Would you like to continue without a regular user?

The user can choose to go back and create a user, or continue.

Currently flagged greeter types:

• SDDM (LXQt, Cutefish, Hyprland)

Tested and confirmed working with root login (not flagged):

• GDM (GNOME)
• lightdm (Cinnamon, Deepin, Mate, Xfce4, Enlightenment, bspwm, i3, labwc, niri, qtile, river, sway, xmonad)

[dylanmtaylor]

This is tested and ready to go in. I haven't tested all greeters, we can add more. I didn't want to hard code to SDDM and name the function after a specific DE.

[h8d13]

Good change !

But it should be in

archinstall/archinstall/lib/global_menu.py

Line 197 in 398d6cf

def _missing_configs(self) -> list[str]:

and not stuffed in guided IMO

[dylanmtaylor]

Good change !

But it should be in

archinstall/archinstall/lib/global_menu.py

Line 197 in 398d6cf

def _missing_configs(self) -> list[str]:

and not stuffed in guided IMO

That would change the behavior though. Right now we show a warning and let the user continue anyway. If it goes into _missing_configs(), it becomes a hard block. In this particular case, I want to let users install without a regular user defined if they would like to.

[dylanmtaylor]

There was some discussion on #4330 around users who wished to do regular user creation outside of the archinstall flow. I'd like to not break that option.

[dylanmtaylor]

I think global_menu.py would be a worse place for it too, since it'd affect things like JSON-based install, which is intentionally as non-interactive as possible.

[h8d13]

I mean, where ever you put this, I do not think it has anything to do in main guided which should be just order orchestration (of the rest)

(It's easy to want to hook in that file, but should be considered elsewhere logical first) Just I think that file should stay clean of any specifics

Perhaps even at the profile level itself, similar to how seat selection is enforced for certain profiles or something more along those lines.

[dylanmtaylor]

I mean, where ever you put this, I do not think it has anything to do in main guided which should be just order orchestration (of the rest)

(It's easy to want to hook in that file, but should be considered elsewhere logical first) Just I think that file should stay clean of any specifics

Perhaps even at the profile level itself, similar to how seat selection is enforced for certain profiles or something more along those lines.

The profile level makes sense but I think that I want to avoid code duplication. It's really a greeter specific issue, not a desktop specific issue. You're probably right that we should move it from guided. I probably need to think on this some more.

[h8d13]

I was checking a bit more and really do think it should be part of global menu validation since we already have helpers such as:

		def has_superuser() -> bool:
			if auth_config and auth_config.users:
				return any([u.sudo for u in auth_config.users])
			return False                                                                        

You'd just want the equivalent but doesn't have to be sudo.

We can just add has_regularuser() or inline the check directly

Believe it would cleaner to just validate with existing validation logic so it's all in one place, missing set here is made exactly for this purpose. About it being blocking in any case, it is blocking and rightfully so or you can't log-in and have to go into a TTY :) So again I think this a good change !

On a side note: an explicit Nogreeter type would be nice, as it defaults to something per profile a user might want to change it back to none

[dylanmtaylor]

@h8d13 I moved it to the global menu file as you suggested and added the has_regular_user() helper function.

[dylanmtaylor]

#4330 did get... touchy as people wanted to be able to make the users themselves in a chroot if birth date were to be required (not planned to be merged until we hear back from Arch leadership), and this does break those DEs. But on the other hand, I'd argue there's no reason not to merge this one. The field could always be trivally nulled after install with about as much effort as adding a user, so it's a silly hill to die on.

[h8d13]

Looks much better to me :)

About users not being created, its not possible as they are used for example for audio to even be set-up.

https://github.com/archlinux/archinstall/blob/master/archinstall/applications/audio.py#L36

But that is unrelated to this PR and already in the scope (in my opinion that PR should not get merged either-way) but this one should 👍

[dylanmtaylor]

my opinion that PR should not get merged either-way

I also feel like it'd be wildly detrimental to the project to remove the ability to add non-root users.

[dylanmtaylor]

Alright, this is ready to be merged whenever.

[svartkanin]

this should be part of the AuthenticationConfiguration class rather than in here

[svartkanin]

just a small nit