Rebasing from Silverblue 41 to Kinoite 41 leaves you with a broken SDDM

[BuonHobo]

Describe the bug
After rebasing from Silverblue 41 to Kinoite 41, I rebooted and got stuck on a black screen with just an underscore. This is probably right when SDDM should start instead.

To Reproduce
Please describe the steps needed to reproduce the bug:

1. Rebase from SB41 to Kinoite 41
2. reboot

Expected behavior
The system boots into the sddm screen

Screenshots
\

OS version:

State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● fedora:fedora/41/x86_64/silverblue
                  Version: 41.20240913.n.0 (2024-09-13T08:18:54Z)
               BaseCommit: 7204cf99672ef324401f6c27caff00ae1ca7fbdd64d7c107303c750b5ff249e7
             GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1
      RemovedBasePackages: gnome-software gnome-software-rpm-ostree 47~beta-1.fc41
          LayeredPackages: cascadia-code-fonts ddcutil tailscale

  fedora:fedora/41/x86_64/kinoite    <------------------- This is the broken KDE image
                  Version: 41.20240913.n.0 (2024-09-13T08:28:52Z)
               BaseCommit: 52b6e60012624c361f4075c1f907846b1ec0061ad70e281f6db58e26fba33654
             GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1
          LayeredPackages: cascadia-code-fonts tailscale

Additional context
Apparently this is caused by sddm not having an entry inside the /etc/shadow file. I tried to fo into /sysroot/ostree/deploy/fedora/deploy/609cb8e6313871180f6f98b1a84f0a2b83b97e7a3703d4aeab569223125b9a4e.0/etc (I know it is the Kinoite deployment because sddm.conf is there) and the shadow file indeed has no entry for sddm.

[BuonHobo]

I tried to solve it by running this, but it didn't work.

buonhobo@desktop:/sysroot/ostree/deploy/fedora/deploy/609cb8e6313871180f6f98b1a84f0a2b83b97e7a3703d4aeab569223125b9a4e.0/etc$ sudo cat ../usr/etc/shadow | grep sddm | sudo tee -a /etc/shadow

(Notice that I'm inside the Kinoite deployment, you can verify that by checking for the sddm.conf file)

---

Even though that did not help, I checked the logs and it definitely has something to do with the sddm user:

Sep 13 21:19:23 fedora unix_chkpwd[1456]: could not obtain user info (sddm)
Sep 13 21:19:23 fedora unix_chkpwd[1457]: could not obtain user info (sddm)
Sep 13 21:19:23 fedora audit[1453]: USER_ACCT pid=1453 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='op=PAM:accounting grantors=? acct="sddm" exe="/usr/lib/systemd/systemd-executor" hostname=? addr=? terminal=? res=failed'
Sep 13 21:19:23 fedora (systemd)[1453]: PAM failed: Authentication service cannot retrieve authentication info
Sep 13 21:19:23 fedora (systemd)[1453]: user@981.service: Failed to set up PAM session: Operation not permitted
Sep 13 21:19:23 fedora (systemd)[1453]: user@981.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
Sep 13 21:19:23 fedora systemd[1]: user@981.service: Main process exited, code=exited, status=224/PAM
Sep 13 21:19:23 fedora systemd[1]: user@981.service: Failed with result 'exit-code'.
Sep 13 21:19:23 fedora systemd[1]: Failed to start user@981.service - User Manager for UID 981.

[travier]

Can you post the output of sudo grep sddm /etc/passwd /etc/group /etc/shadow /etc/gshadow from the deployment that shows the error?

[BuonHobo]

I solved it, the command I ran in my previous comment DID work, but I'm stupid and I was trying to rollback into the Kinoite deploymentt without realizing that doing that will rollback /etc as well.
All I did was adding the entry in /etc/shadow and then rebase again, that worked.

Not sure if it's still useful, but here's the output of sudo grep sddm /etc/passwd /etc/group /etc/shadow /etc/gshadow

buonhobo@desktop:/sysroot/ostree/deploy/fedora/deploy/f6764dae987b69cf9d79a43c50186ec3986ded009347dfc8c125a8cf50412b80.0/etc$ sudo grep sddm /etc/passwd /etc/group /etc/shadow /etc/gshadow
/etc/shadow:sddm:!:::::::

[travier]

I'll keep this open for a while as I don't know exactly why this happened to me as well. I've never seen it in testing however. It might be related to the Silverblue -> Kinoite rebase.