[Kinoite] Plasma Login issue with rawhide rebase #684

Closed
opened 2026-02-03 22:07:36 +00:00 by boniboyblue · 28 comments

As part of the KDE 6.6 test week - I rebased my Fedora Silverblue 43 device to Kinoite Rawhide.

The update process completely perfectly normal however when I reboot the device, I'm greeted with a blank screen/UEFI boot splash until I change to tty2.

I can still start plasma using startplasma-wayland and use it as normal including locking my screen however logging out does take me back to tty2.

I then rebased to Kinoite 43 which worked as intended which led me to believe this might be an issue with plasmalogin.

Logs below that were generated if they are of any use.

21:18:33.896 UTC plasmalogin.service Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
If this causes problems, reconfigure your locale. See the locale(1) manual
for more information.
21:18:33.908 UTC plasmalogin.service [PAM] acctMgmt: Authentication service cannot retrieve authentication info
21:18:33.908 UTC plasmalogin.service [PAM] Asked to close the session but it wasn't previously open
21:18:33.908 UTC plasmalogin.service Authentication error: PLASMALOGIN::Auth::ERROR_AUTHENTICATION "Authentication service cannot retrieve authentication info"
21:18:33.909 UTC plasmalogin.service Autologin failed!
21:18:33.910 UTC plasmalogin.service Auth: plasmalogin-helper exited with 1
21:18:33.916 UTC plasmalogin.service Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
If this causes problems, reconfigure your locale. See the locale(1) manual
for more information.
21:19:05.468 UTC plasmalogin.service Error from greeter session: "Process crashed"
21:19:05.469 UTC plasmalogin.service Auth: plasmalogin-helper (--socket /tmp/plasmalogin-auth-60802b2e-1b38-4354-a913-f9c8e53d24e9 --id 2 --start /usr/bin/startplasma-login-wayland --user plasmalogin --greeter) crashed (exit code 1)
21:19:05.469 UTC plasmalogin.service Error from greeter session: "Process crashed"
21:19:05.469 UTC plasmalogin.service Auth: plasmalogin-helper exited with 1
21:19:05.489 UTC plasmalogin.service Signal received: SIGTERM
As part of the KDE 6.6 test week - I rebased my Fedora Silverblue 43 device to Kinoite Rawhide. The update process completely perfectly normal however when I reboot the device, I'm greeted with a blank screen/UEFI boot splash until I change to tty2. I can still start plasma using `startplasma-wayland` and use it as normal including locking my screen however logging out does take me back to tty2. I then rebased to Kinoite 43 which worked as intended which led me to believe this might be an issue with plasmalogin. Logs below that were generated if they are of any use. ``` 21:18:33.896 UTC plasmalogin.service Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8. Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead. If this causes problems, reconfigure your locale. See the locale(1) manual for more information. 21:18:33.908 UTC plasmalogin.service [PAM] acctMgmt: Authentication service cannot retrieve authentication info 21:18:33.908 UTC plasmalogin.service [PAM] Asked to close the session but it wasn't previously open 21:18:33.908 UTC plasmalogin.service Authentication error: PLASMALOGIN::Auth::ERROR_AUTHENTICATION "Authentication service cannot retrieve authentication info" 21:18:33.909 UTC plasmalogin.service Autologin failed! 21:18:33.910 UTC plasmalogin.service Auth: plasmalogin-helper exited with 1 21:18:33.916 UTC plasmalogin.service Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8. Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead. If this causes problems, reconfigure your locale. See the locale(1) manual for more information. 21:19:05.468 UTC plasmalogin.service Error from greeter session: "Process crashed" 21:19:05.469 UTC plasmalogin.service Auth: plasmalogin-helper (--socket /tmp/plasmalogin-auth-60802b2e-1b38-4354-a913-f9c8e53d24e9 --id 2 --start /usr/bin/startplasma-login-wayland --user plasmalogin --greeter) crashed (exit code 1) 21:19:05.469 UTC plasmalogin.service Error from greeter session: "Process crashed" 21:19:05.469 UTC plasmalogin.service Auth: plasmalogin-helper exited with 1 21:19:05.489 UTC plasmalogin.service Signal received: SIGTERM ```
Member

Metadata Update from @siosm:

  • Issue set to the milestone: Fedora Linux 44
  • Issue tagged with: kinoite
**Metadata Update from @siosm**: - Issue set to the milestone: Fedora Linux 44 - Issue tagged with: kinoite
Member

It's an unfortunately known issue that I haven't been able to figure out yet. It does not get triggered on fresh installed so there is something that breaks on update.

It's an unfortunately known issue that I haven't been able to figure out yet. It does not get triggered on fresh installed so there is something that breaks on update.
Member

I need help to debug this issue. Here is how I would proceed and how one may start looking at this:

  • Setup a F43 Kinoite system
  • Rebase to F44

in parallel:

  • Setup an F44 Kinoite system

Then take both /etc from those systems and compare it.

This might be related to https://src.fedoraproject.org/rpms/plasma-setup/blob/rawhide/f/plasma-setup.spec#_109-114.

I need help to debug this issue. Here is how I would proceed and how one may start looking at this: - Setup a F43 Kinoite system - Rebase to F44 in parallel: - Setup an F44 Kinoite system Then take both `/etc` from those systems and compare it. This might be related to https://src.fedoraproject.org/rpms/plasma-setup/blob/rawhide/f/plasma-setup.spec#_109-114.
Owner

Is there a mechanism to deal with transitions with rebases?

Is there a mechanism to deal with transitions with rebases?

quick and dirty diff, will investigate later

https://gist.github.com/renner0e/d6aa10e4457c9eab56fbfdb2d472a022

quick and dirty diff, will investigate later https://gist.github.com/renner0e/d6aa10e4457c9eab56fbfdb2d472a022
Author

Will this need a Beta Freeze Exception with the freeze tomorrow?

Will this need a Beta Freeze Exception with the freeze tomorrow?
Owner

Yes, someone needs to file a BZ against plasma-login-manager and request an FE. We have no idea right now how to fix it.

Yes, someone needs to file a BZ against plasma-login-manager and request an FE. We have no idea right now how to fix it.
Author

I'll get it raised.

I'll get it raised.

I created two VMs:

One installed from Rawhide Kinoite F44
One installed from the latest Kinoite F43.
I then rebased the F43 VM to Rawhide F44. It immediately showed the issue.

Upgraded system that is failing is having some issues with plasmalogin.service and user@967.service (uid 967 being "plasmalogin"):

Feb 16 07:40:29 fedora unix_chkpwd[1382]: could not obtain user info (plasma-setup)
Feb 16 07:40:29 fedora plasmalogin-helper[1381]: [PAM] acctMgmt: Authentication service cannot retrieve authentication info
Feb 16 07:40:29 fedora unix_chkpwd[1395]: could not obtain user info (plasmalogin)
Feb 16 07:40:29 fedora (systemd)[1392]: user@967.service: Failed to set up PAM session: Operation not permitted
Feb 16 07:40:29 fedora (systemd)[1392]: PAM PAM failed: Authentication service cannot retrieve authentication info
Feb 16 07:40:29 fedora (systemd)[1392]: user@967.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted

The problem is almost assuredly this:

# grep plasma /etc/shadow
#

IE the plasmalogin and plasma-setup users, despite being defined in /lib/passwd are not present in /etc/shadow.
On the working system they ARE present in /etc/shadow, presumably put there by plasma-setup. The problem being on the rebased system plasma-setup never ran. nothing created them, and PAM is failing.

I created two VMs: One installed from Rawhide Kinoite F44 One installed from the latest Kinoite F43. I then rebased the F43 VM to Rawhide F44. It immediately showed the issue. Upgraded system that is failing is having some issues with plasmalogin.service and user@967.service (uid 967 being "plasmalogin"): ``` Feb 16 07:40:29 fedora unix_chkpwd[1382]: could not obtain user info (plasma-setup) Feb 16 07:40:29 fedora plasmalogin-helper[1381]: [PAM] acctMgmt: Authentication service cannot retrieve authentication info ``` ``` Feb 16 07:40:29 fedora unix_chkpwd[1395]: could not obtain user info (plasmalogin) Feb 16 07:40:29 fedora (systemd)[1392]: user@967.service: Failed to set up PAM session: Operation not permitted Feb 16 07:40:29 fedora (systemd)[1392]: PAM PAM failed: Authentication service cannot retrieve authentication info Feb 16 07:40:29 fedora (systemd)[1392]: user@967.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted ``` The problem is almost assuredly this: ``` # grep plasma /etc/shadow # ``` IE the plasmalogin and plasma-setup users, despite being defined in /lib/passwd are not present in /etc/shadow. On the working system they ARE present in /etc/shadow, presumably put there by plasma-setup. The problem being on the rebased system plasma-setup never ran. nothing created them, and PAM is failing.
Author
Beta Freeze Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2440208 Beta Freeze Exception (Please vote): https://pagure.io/fedora-qa/blocker-review/issue/2037

Adding the missing entries to /etc/shadow and /etc/gshadow by hand resulted in plasma-setup running (is this correct on a rebase?) and then the login manager functioning as expected.

So it is in fact the missing /etc/shadow and /etc/gshadow entries causing the issue.

Adding the missing entries to /etc/shadow and /etc/gshadow by hand resulted in plasma-setup running (is this correct on a rebase?) and then the login manager functioning as expected. So it is in fact the missing /etc/shadow and /etc/gshadow entries causing the issue.

This may well be to do with the shadow-utils 4.19 update then. There were quite a lot of issues with that update, but one that may well be relevant here is that 4.19 no longer does SELinux context fixups when operating on a different root with -R. See e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2435621#c10 for another case where this caused issues.

This may well be to do with the shadow-utils 4.19 update then. There were quite a lot of issues with that update, but one that may well be relevant here is that 4.19 no longer does SELinux context fixups when operating on a different root with `-R`. See e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2435621#c10 for another case where this caused issues.
Member

Thanks everyone for the investigation.

Adding the missing entries to /etc/shadow and /etc/gshadow by hand resulted in plasma-setup running (is this correct on a rebase?) and then the login manager functioning as expected.

I can confirm as well that this fixes the issue on my test system.

Now I guess the question is why does those entries do not get created on the system for plasmalogin when they were created for all the other users?

Is there a mechanism to deal with transitions with rebases?

There isn't unfortunately. But we can add scripts to run on boot if we figure out how to fix it.

Thanks everyone for the investigation. > Adding the missing entries to /etc/shadow and /etc/gshadow by hand resulted in plasma-setup running (is this correct on a rebase?) and then the login manager functioning as expected. I can confirm as well that this fixes the issue on my test system. Now I guess the question is why does those entries do not get created on the system for plasmalogin when they were created for all the other users? > Is there a mechanism to deal with transitions with rebases? There isn't unfortunately. But we can add scripts to run on boot if we figure out how to fix it.
Owner

We'll need one at least for the plasma-setup thing, since otherwise it won't get disabled properly.

We'll need one at least for the plasma-setup thing, since otherwise it won't get disabled properly.
Member

Looks like the entry for plasma-setup is not created either but this one does not matter much. This points to an issue in systemd-sysusers or shadow-utils indeed.

Looks like the entry for plasma-setup is not created either but this one does not matter much. This points to an issue in systemd-sysusers or shadow-utils indeed.
Member

We'll need one at least for the plasma-setup thing, since otherwise it won't get disabled properly.

Indeed, I don't have /etc/plasma-setup-done either, but that looks like another issue. I don't know how we would create this one. Maybe we add it to all existing F42 & F43 Kinoite systems via an update.

> We'll need one at least for the plasma-setup thing, since otherwise it won't get disabled properly. Indeed, I don't have `/etc/plasma-setup-done` either, but that looks like another issue. I don't know how we would create this one. Maybe we add it to all existing F42 & F43 Kinoite systems via an update.

systemd-sysusers does nothing, since from the point of view of systemd-sysusers, the user already exists, because NSS says so (it's in /lib/passwd).

Also note this is a general issue, there's also a pcssd (something like that) user that has the same problem, which is probably a bug waiting to happen.

This is a general "the image added a user that didn't exist before" issue, the plasmalogin thing is just a symptom.

Is there a reason that the config only uses NSS extrafiles for passwd and not shadow?

Having a /lib/shadow and a /lib/gshadow file seems like it would solve the issue completely.

systemd-sysusers does nothing, since from the point of view of systemd-sysusers, the user already exists, because NSS says so (it's in /lib/passwd). Also note this is a general issue, there's also a pcssd (something like that) user that has the same problem, which is probably a bug waiting to happen. This is a general "the image added a user that didn't exist before" issue, the plasmalogin thing is just a symptom. Is there a reason that the config only uses NSS extrafiles for passwd and not shadow? Having a /lib/shadow and a /lib/gshadow file seems like it would solve the issue completely.
Member

Support for files beyond passwd & group was not in the initial version of nss-altfiles. It only got enabled in https://src.fedoraproject.org/rpms/nss-altfiles/pull-request/5. We could switch it on for shadow & gshadow but that would be a significant change this late in the cycle. This would need to happen in authselect and maybe for all bootc systems in general as well.

Support for files beyond passwd & group was not in the initial version of nss-altfiles. It only got enabled in https://src.fedoraproject.org/rpms/nss-altfiles/pull-request/5. We could switch it on for shadow & gshadow but that would be a significant change this late in the cycle. This would need to happen in authselect and maybe for all bootc systems in general as well.
Member

Unfortunately the real fix would be to move away from nss-altfiles completely but that requires work and testing as well:

Unfortunately the real fix would be to move away from nss-altfiles completely but that requires work and testing as well: - https://github.com/coreos/fedora-coreos-tracker/issues/1599 - https://github.com/coreos/rpm-ostree/issues/49
Member
Looks similar to https://github.com/bootc-dev/bootc/issues/1179
Member

At this point I see two options within reach of the beta timeline:

  1. Hackish workaround to add the missing lines to the shadow & gshadow files via a script / systemd unit triggered on boot
  2. Staying on SDDM for Kinoite until we figure out a proper fix

Option 1 would look like:

/usr/libexec/fedora-kinoite-plasmalogin-workaround

#!/bin/bash

set -euo pipefail

echo "Checking plasmalogin entries in /etc/shadow & /etc/gshadow"

if [[ $(grep -c "plasmalogin" "/etc/shadow") -eq 0 ]]; then
    echo "plasmalogin:!*:::::::" >> "/etc/shadow"
    echo "Added missing plasmalogin entry to /etc/shadow"
else
    echo "Nothing to do for /etc/shadow"
fi

if [[ $(grep -c "plasmalogin" "/etc/gshadow") -eq 0 ]]; then
    echo "plasmalogin:!*::" >> "/etc/gshadow"
    echo "Added missing plasmalogin entry to /etc/gshadow"
else
    echo "Nothing to do for /etc/gshadow"
fi

echo "Writing stamp file: /etc/.fedora-kinoite-plasmalogin-workaround"
touch > /etc/.fedora-kinoite-plasmalogin-workaround

/usr/lib/systemd/system/fedora-kinoite-plasmalogin-workaround.service

[Unit]
Description=Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite
Documentation=https://forge.fedoraproject.org/kde/SIG/issues/684
ConditionPathIsReadWrite=/etc
ConditionPathExists=/run/ostree-booted
ConditionPathExists=!/etc/.fedora-kinoite-plasmalogin-workaround
Before=plasmalogin.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/libexec/fedora-kinoite-plasmalogin-workaround

[Install]
WantedBy=multi-user.target

Edit: Updated as I as miss-clicked on the comment button too soon.

At this point I see two options within reach of the beta timeline: 1. Hackish workaround to add the missing lines to the shadow & gshadow files via a script / systemd unit triggered on boot 2. Staying on SDDM for Kinoite until we figure out a proper fix Option 1 would look like: `/usr/libexec/fedora-kinoite-plasmalogin-workaround` ```bash #!/bin/bash set -euo pipefail echo "Checking plasmalogin entries in /etc/shadow & /etc/gshadow" if [[ $(grep -c "plasmalogin" "/etc/shadow") -eq 0 ]]; then echo "plasmalogin:!*:::::::" >> "/etc/shadow" echo "Added missing plasmalogin entry to /etc/shadow" else echo "Nothing to do for /etc/shadow" fi if [[ $(grep -c "plasmalogin" "/etc/gshadow") -eq 0 ]]; then echo "plasmalogin:!*::" >> "/etc/gshadow" echo "Added missing plasmalogin entry to /etc/gshadow" else echo "Nothing to do for /etc/gshadow" fi echo "Writing stamp file: /etc/.fedora-kinoite-plasmalogin-workaround" touch > /etc/.fedora-kinoite-plasmalogin-workaround ``` `/usr/lib/systemd/system/fedora-kinoite-plasmalogin-workaround.service` ```ini [Unit] Description=Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite Documentation=https://forge.fedoraproject.org/kde/SIG/issues/684 ConditionPathIsReadWrite=/etc ConditionPathExists=/run/ostree-booted ConditionPathExists=!/etc/.fedora-kinoite-plasmalogin-workaround Before=plasmalogin.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/libexec/fedora-kinoite-plasmalogin-workaround [Install] WantedBy=multi-user.target ``` Edit: Updated as I as miss-clicked on the comment button too soon.
Member
I've made https://pagure.io/workstation-ostree-config/pull-request/734 and this can be tested with the F44 image at https://quay.io/repository/fedora-atomic-desktops-staging/kinoite?tab=tags
Member

From an F43 installation, rebasing to the F44 image with the workaround:

$ sudo rpm-ostree rebase ostree-unverified-image:registry:quay.io/fedora-atomic-desktops-staging/kinoite:44
$ sudo journalctl -e -u fedora-kinoite-plasmalogin-workaround.service
Mar 03 00:51:58 fedora systemd[1]: Starting fedora-kinoite-plasmalogin-workaround.service - Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite...
Mar 03 00:51:58 fedora fedora-kinoite-plasmalogin-workaround[1063]: Checking plasmalogin entries in /etc/shadow & /etc/gshadow
Mar 03 00:51:58 fedora fedora-kinoite-plasmalogin-workaround[1063]: Added missing plasmalogin entry to /etc/shadow
Mar 03 00:51:58 fedora fedora-kinoite-plasmalogin-workaround[1063]: Added missing plasmalogin entry to /etc/gshadow
Mar 03 00:51:58 fedora fedora-kinoite-plasmalogin-workaround[1063]: Writing stamp file: /etc/.fedora-kinoite-plasmalogin-workaround
Mar 03 00:51:59 fedora systemd[1]: Finished fedora-kinoite-plasmalogin-workaround.service - Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite.

Ugly but looks like it works.

From an F43 installation, rebasing to the F44 image with the workaround: ``` $ sudo rpm-ostree rebase ostree-unverified-image:registry:quay.io/fedora-atomic-desktops-staging/kinoite:44 ``` ``` $ sudo journalctl -e -u fedora-kinoite-plasmalogin-workaround.service Mar 03 00:51:58 fedora systemd[1]: Starting fedora-kinoite-plasmalogin-workaround.service - Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite... Mar 03 00:51:58 fedora fedora-kinoite-plasmalogin-workaround[1063]: Checking plasmalogin entries in /etc/shadow & /etc/gshadow Mar 03 00:51:58 fedora fedora-kinoite-plasmalogin-workaround[1063]: Added missing plasmalogin entry to /etc/shadow Mar 03 00:51:58 fedora fedora-kinoite-plasmalogin-workaround[1063]: Added missing plasmalogin entry to /etc/gshadow Mar 03 00:51:58 fedora fedora-kinoite-plasmalogin-workaround[1063]: Writing stamp file: /etc/.fedora-kinoite-plasmalogin-workaround Mar 03 00:51:59 fedora systemd[1]: Finished fedora-kinoite-plasmalogin-workaround.service - Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite. ``` Ugly but looks like it works.

I tested the workaround in a virtual machine created using bcvk. I can log in to the F44 deployment via a graphical user interface using the Virtual Machine Manager Flatpak from Flathub. The following output is from an SSH session into the VM for easier copy/paste.

hricky@silverblue  >_ bcvk libvirt ssh fedora-kinoite-bcvk

Last login: Thu Mar  5 16:15:36 2026 from 10.0.2.2

root@fedora:~# rpm-ostree status
State: idle
Deployments:
● ostree-unverified-registry:quay.io/fedora-atomic-desktops-staging/kinoite:44
                   Digest: sha256:3d5c32abbf9936a4d6ba011a68c6ffcdae091f63aaa024b63897cbc42aff54d1
                  Version: 44.20260302.0 (2026-03-02T23:08:44Z)

  ostree-unverified-image:containers-storage:localhost/fedora-kinoite-bcvk:43
                   Digest: sha256:bfc63380d53d760b7ccb32d783560b8b51c3051c453b2222b175184ad9745bab
                  Version: 43.20260305.0 (2026-03-05T14:19:32Z)
                   Pinned: yes

root@fedora:~# bootc status
● Booted image: quay.io/fedora-atomic-desktops-staging/kinoite:44
        Digest: sha256:3d5c32abbf9936a4d6ba011a68c6ffcdae091f63aaa024b63897cbc42aff54d1 (amd64)
       Version: 44.20260302.0 (2026-03-02T23:08:44Z)

  Rollback image: containers-storage:localhost/fedora-kinoite-bcvk:43
          Digest: sha256:bfc63380d53d760b7ccb32d783560b8b51c3051c453b2222b175184ad9745bab (amd64)
         Version: 43.20260305.0 (2026-03-05T14:19:32Z)
          Pinned: yes

root@fedora:~# journalctl --unit fedora-kinoite-plasmalogin-workaround.service --full --no-pager --pager-end 
Mar 05 16:16:43 fedora systemd[1]: fedora-kinoite-plasmalogin-workaround.service - Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite skipped, unmet condition check ConditionPathExists=!/etc/.fedora-kinoite-plasmalogin-workaround

root@fedora:~# journalctl --unit fedora-kinoite-plasmalogin-workaround.service --full --no-pager --pager-end --boot -1
Mar 05 16:01:39 fedora systemd[1]: Starting fedora-kinoite-plasmalogin-workaround.service - Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite...
Mar 05 16:01:39 fedora fedora-kinoite-plasmalogin-workaround[1087]: Checking plasmalogin entries in /etc/shadow & /etc/gshadow
Mar 05 16:01:39 fedora fedora-kinoite-plasmalogin-workaround[1087]: Added missing plasmalogin entry to /etc/shadow
Mar 05 16:01:39 fedora fedora-kinoite-plasmalogin-workaround[1087]: Added missing plasmalogin entry to /etc/gshadow
Mar 05 16:01:39 fedora fedora-kinoite-plasmalogin-workaround[1087]: Writing stamp file: /etc/.fedora-kinoite-plasmalogin-workaround
Mar 05 16:01:39 fedora systemd[1]: Finished fedora-kinoite-plasmalogin-workaround.service - Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite.
Mar 05 16:16:25 fedora systemd[1]: fedora-kinoite-plasmalogin-workaround.service: Deactivated successfully.
Mar 05 16:16:25 fedora systemd[1]: Stopped fedora-kinoite-plasmalogin-workaround.service - Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite.
I tested the workaround in a virtual machine created using `bcvk`. I can log in to the F44 deployment via a graphical user interface using the Virtual Machine Manager Flatpak from Flathub. The following output is from an SSH session into the VM for easier copy/paste. ```text hricky@silverblue >_ bcvk libvirt ssh fedora-kinoite-bcvk Last login: Thu Mar 5 16:15:36 2026 from 10.0.2.2 root@fedora:~# rpm-ostree status State: idle Deployments: ● ostree-unverified-registry:quay.io/fedora-atomic-desktops-staging/kinoite:44 Digest: sha256:3d5c32abbf9936a4d6ba011a68c6ffcdae091f63aaa024b63897cbc42aff54d1 Version: 44.20260302.0 (2026-03-02T23:08:44Z) ostree-unverified-image:containers-storage:localhost/fedora-kinoite-bcvk:43 Digest: sha256:bfc63380d53d760b7ccb32d783560b8b51c3051c453b2222b175184ad9745bab Version: 43.20260305.0 (2026-03-05T14:19:32Z) Pinned: yes root@fedora:~# bootc status ● Booted image: quay.io/fedora-atomic-desktops-staging/kinoite:44 Digest: sha256:3d5c32abbf9936a4d6ba011a68c6ffcdae091f63aaa024b63897cbc42aff54d1 (amd64) Version: 44.20260302.0 (2026-03-02T23:08:44Z) Rollback image: containers-storage:localhost/fedora-kinoite-bcvk:43 Digest: sha256:bfc63380d53d760b7ccb32d783560b8b51c3051c453b2222b175184ad9745bab (amd64) Version: 43.20260305.0 (2026-03-05T14:19:32Z) Pinned: yes root@fedora:~# journalctl --unit fedora-kinoite-plasmalogin-workaround.service --full --no-pager --pager-end Mar 05 16:16:43 fedora systemd[1]: fedora-kinoite-plasmalogin-workaround.service - Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite skipped, unmet condition check ConditionPathExists=!/etc/.fedora-kinoite-plasmalogin-workaround root@fedora:~# journalctl --unit fedora-kinoite-plasmalogin-workaround.service --full --no-pager --pager-end --boot -1 Mar 05 16:01:39 fedora systemd[1]: Starting fedora-kinoite-plasmalogin-workaround.service - Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite... Mar 05 16:01:39 fedora fedora-kinoite-plasmalogin-workaround[1087]: Checking plasmalogin entries in /etc/shadow & /etc/gshadow Mar 05 16:01:39 fedora fedora-kinoite-plasmalogin-workaround[1087]: Added missing plasmalogin entry to /etc/shadow Mar 05 16:01:39 fedora fedora-kinoite-plasmalogin-workaround[1087]: Added missing plasmalogin entry to /etc/gshadow Mar 05 16:01:39 fedora fedora-kinoite-plasmalogin-workaround[1087]: Writing stamp file: /etc/.fedora-kinoite-plasmalogin-workaround Mar 05 16:01:39 fedora systemd[1]: Finished fedora-kinoite-plasmalogin-workaround.service - Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite. Mar 05 16:16:25 fedora systemd[1]: fedora-kinoite-plasmalogin-workaround.service: Deactivated successfully. Mar 05 16:16:25 fedora systemd[1]: Stopped fedora-kinoite-plasmalogin-workaround.service - Workaround for missing plasmalogin entries in /etc/shadow & /etc/gshadow on Kinoite. ```
Member

Great, thanks for testing.

Great, thanks for testing.
Member

F44 beta is GO, thus I'm pushing that now.

F44 beta is GO, thus I'm pushing that now.
siosm self-assigned this 2026-03-08 14:08:59 +00:00
Member

Closing as this is work'ed around in F44 in time for the Beta. I'll create a new issue to track the real fix which is moving away from nss-altfiles: kde/tickets#684 (comment).

Closing as this is work'ed around in F44 in time for the Beta. I'll create a new issue to track the real fix which is moving away from nss-altfiles: https://forge.fedoraproject.org/kde/tickets/issues/684#issuecomment-550616.
siosm closed this issue 2026-03-08 14:09:46 +00:00
Member

Proper fix for this issue is tracked in atomic-desktops/tracker#108

Proper fix for this issue is tracked in https://forge.fedoraproject.org/atomic-desktops/tracker/issues/108
Sign in to join this conversation.
No milestone
No project
No assignees
7 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
kde/tracker#684
No description provided.