I dont know anything about this, but I now know about LLM prompt engineering.
Forgive me for using ChatGPT but here is what it told me:
The fix you’re applying involves adding entries for cosmic-greeter and greetd in the /etc/shadow file, which is where hashed passwords and account status are stored on Linux systems.
Explanation:
-
/etc/shadow: This file contains password information for user accounts. Each line represents one user, and the fields (separated by colons :) provide information like the encrypted password, account expiration dates, and so on.
cosmic-greeter:!:::::::greetd:!:::::::
The ! in the second field means that these accounts are locked—they have no valid password for login, which is common for system or service accounts that should never log in interactively. However, the entry needs to exist to ensure the system can handle these accounts properly.
-
greetd & cosmic-greeter: These are likely the greetd (a display manager) and cosmic-greeter (a greeter interface for the login screen) components in your Fedora system.
By adding these entries, you’re ensuring that these system accounts are recognized by PAM (Pluggable Authentication Modules), which is responsible for authentication, login, and session handling.
Why this Fix Works:
The issue occurs because these accounts don’t have entries in /etc/shadow by default. When the login manager tries to launch, PAM checks for valid user entries in both /etc/passwd and /etc/shadow. Without valid entries for greetd and cosmic-greeter, the login process can fail due to authentication issues, even though these accounts should never require a password.
By adding entries in /etc/shadow, you’re ensuring PAM can handle the accounts properly, even though they can’t log in interactively (! in the password field). This prevents the system from denying the login process when interacting with these service accounts.
Normally Managed by:
-
User and Account Management Tools: Tools like useradd or system setup scripts typically manage /etc/shadow. However, for system accounts like greetd or cosmic-greeter, these accounts should be created during the installation or configuration of the display manager. Normally, these entries would be created automatically when you install the display manager or greeter.
If they are missing, this might indicate an issue with the packaging or installation scripts for greetd or cosmic-greeter. Normally, they should “just work” out of the box without needing manual intervention.
SELinux:
If SELinux is enabled, there shouldn’t be direct conflicts with /etc/shadow, but improper labeling could prevent PAM from functioning correctly. Running restorecon on /etc/shadow could help if you suspect an SELinux issue:
sudo restorecon /etc/shadow
This ensures the file has the correct SELinux context.
I think this answer is pretty great?
The issue is that we dont use Anaconda, but rebase to an image that contains different processes that have unique users.
Those users dont yet exist, so they need their entries added manually.
All that uBlue does is run those in the Containerfile
systemctl disable gdm || true && \
systemctl disable sddm || true && \
systemctl enable cosmic-greeter && \
I suppose cosmic-greeter adds these entries on its own because that is basically it and there is no mention of “greet” in the other files.
