Solved! Turns out my first clue regarding /etc/shadow was the correct culprit all along. And for those who are interested in rebasing from Silverblue to Kinoite or vice-versa, this is an additional step in addition to the official unofficial instructions for the rebase. Note: this error didn’t actually affect the system - I’ve been using it like this for months since Kinoite 35 came out. But the error has been there, and that…bugged me.
Googling the “PAM:accounting grantors=?” error hinted that the user is missing from /etc/shadow. Looking at the /etc/passwd file on a Silverblue/Kinoite system is pretty confusing because it’s pretty bare - mine only has entries for root and myself. Whereas the /etc/shadow file has many more entries. It wasn’t clear until playing with getent passwd -s and looking into the /etc/nsswitch.conf file that it was evident that Silverblue/Kinoite uses the nss-altfiles module. It makes perfect sense now, of course, since we would want to store that info in /lib/passwd instead of /etc/passwd, since /lib is part of the ostree whereas /etc is mutable.
nsswitch.conf
# Generated by authselect on Tue Aug 31 14:25:43 2021
# Do not modify this file manually.
# If you want to make changes to nsswitch.conf please modify
# /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'.
#
# Note that your changes may not be applied as they may be
# overwritten by selected profile. Maps set in the authselect
# profile takes always precedence and overwrites the same maps
# set in the user file. Only maps that are not set by the profile
# are applied from the user file.
#
# For example, if the profile sets:
# passwd: sss files
# and /etc/authselect/user-nsswitch.conf contains:
# passwd: files
# hosts: files dns
# the resulting generated nsswitch.conf will be:
# passwd: sss files # from profile
# hosts: files dns # from user file
passwd: sss files systemd altfiles
group: sss files systemd altfiles
netgroup: sss files
automount: sss files
services: sss files
But problematically there’s no corresponding module for the shadow file. So there is only /etc/shadow. It doesn’t get overwritten by an ostree rebase/upgrade. So that means that the sddm user that replaced gdm in /lib/passwd never had the same change cascaded down to /etc/shadow.
TLDR; use sudo vipw -s to edit the /etc/shadow file manually and add the sddm user. I don’t particularly like the idea of manually updating the shadow file, but I couldn’t (in my short time looking) find a tool (e.g. pwconv) that would look at the /lib/passwd file as most tools expect everything to be in /etc. If there’s a better option, please let me know.
Pretty neat to learn new stuff every day. Yay to Linux and OSS, that allows us to peek under the covers and figure out what’s going on and fix pretty much anything with some research.