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.

[erlking]

hi,

i try to rebase from F41 Silverblue to Kinoite and encountered the same issue with missing sddm entry in /etc/shadow that fixed i still end up in a broken kde environment. (after logging in i only see a black screen with a frozen cursor and the system locks up)

did you made any other changes except for the sddm /etc/shadow part?

should be my log from the time i tried to login

journalctl -r | grep 12:38
Okt 31 12:38:30 homefed systemd[2311]: Starting xdg-desktop-portal-gtk.service - Portal service (GTK/GNOME implementation)...
Okt 31 12:38:30 homefed xdg-desktop-por[2593]: Failed to create settings proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.kde: Timeout was reached
Okt 31 12:38:30 homefed systemd[2311]: Failed to start xdg-desktop-portal-gtk.service - Portal service (GTK/GNOME implementation).
Okt 31 12:38:30 homefed systemd[2311]: xdg-desktop-portal-gtk.service: Failed with result 'timeout'.
Okt 31 12:38:30 homefed systemd[2311]: xdg-desktop-portal-gtk.service: start operation timed out. Terminating.
Okt 31 12:38:20 homefed systemd[2311]: dbus-:1.2-org.kde.KSplash@0.service: Failed with result 'exit-code'.
Okt 31 12:38:20 homefed systemd[2311]: dbus-:1.2-org.kde.KSplash@0.service: Main process exited, code=exited, status=1/FAILURE
Okt 31 12:38:20 homefed plasma_waitforname[2409]: org.kde.plasma.waitforname: WaitForName: Service was not registered within timeout
Okt 31 12:38:05 homefed systemd[2311]: Starting xdg-desktop-portal.service - Portal service...
Okt 31 12:38:05 homefed pam_kwallet_init[2591]: 2024/10/31 12:38:05 socat[2591] W address is opened in read-write mode but only supports read-only
Okt 31 12:38:05 homefed systemd[2311]: Starting plasma-kded6.service - KDE Daemon 6...
Okt 31 12:38:05 homefed systemd[2311]: Started plasma-kwallet-pam.service - Unlock kwallet from pam credentials.
Okt 31 12:38:05 homefed systemd[2311]: Starting plasma-ksmserver.service - KDE Session Management Server...
Okt 31 12:38:05 homefed systemd[2311]: plasma-kcminit-phase1.service: Job plasma-kcminit-phase1.service/start failed with result 'dependency'.
Okt 31 12:38:05 homefed systemd[2311]: Dependency failed for plasma-kcminit-phase1.service - KDE Configuration Module Initialization (Phase 1).
Okt 31 12:38:05 homefed systemd[2311]: Failed to start plasma-kcminit.service - KDE Config Module Initialization.
Okt 31 12:38:05 homefed systemd[2311]: plasma-kcminit.service: Failed with result 'timeout'.
Okt 31 12:38:05 homefed systemd[2311]: Failed to start xdg-desktop-portal.service - Portal service.
Okt 31 12:38:05 homefed systemd[2311]: xdg-desktop-portal.service: Failed with result 'timeout'.
Okt 31 12:38:05 homefed systemd[2311]: plasma-kcminit.service: Killing process 2545 (WaylandEventThr) with signal SIGKILL.
Okt 31 12:38:05 homefed systemd[2311]: xdg-desktop-portal.service: start operation timed out. Terminating.
Okt 31 12:38:05 homefed systemd[2311]: plasma-kcminit.service: start operation timed out. Terminating.
Okt 31 12:38:01 homefed systemd[2311]: Failed to start plasma-ksplash.service - Splash screen shown during boot.
Okt 31 12:38:01 homefed systemd[2311]: plasma-ksplash.service: Failed with result 'timeout'.
Okt 31 12:38:01 homefed systemd[2311]: plasma-ksplash.service: Main process exited, code=killed, status=15/TERM
Okt 31 12:38:01 homefed systemd[2311]: plasma-ksplash.service: start operation timed out. Terminating.

[BuonHobo]

@erlking make sure you are not making the same mistake I was making in https://github.com/fedora-silverblue/issue-tracker/issues/597#issuecomment-2350882156

You should add the entry in /etc/shadow and then rebase to 41

P.s.: No, I haven't made any other changes besides this as far as I can remember

[erlking]

Tried again the rebase and ensured that the sddm entry in /etc/shadow exists before, same result sadly. Thanks for your answer though.

[cyrneko]

Tried again the rebase and ensured that the sddm entry in /etc/shadow exists before, same result sadly. Thanks for your answer though.

Same here, just ran into this after rebasing from Kinoite 41 (from the current ISO) to the latest Bazzite and the fix sadly didn't work, /etc/shadow already had an entry for SDDM :/

[travier]

Please post some logs to help us investigate the issue.