As mentioned in the subject line, following layering a new package using rpm-ostree, and rebooting, my system boots, I’m greeted with the sddm greeter, however after inputting my password I get a login failure message.
I do have 3 images to boot from in the grub boot menu. 0 is the latest, following the install of the gtk theme. 1 was my initial rebase to Fedora 41 (was working great). 2 is the last working image prior to rebasing. In spite of having 3 images to boot from all 3 suffer from the same issue; I input my password…. I get a login failed message.
I currently have the system booted with anaconda from my installation USB. I’ve mounted my disk and chrooted into the latest image. I can’t run any rpm-ostree commands successfully however as the system didn’t boot using the image created by rpm-ostree. Also, after looking through some of the file system I don’t see anything that was obviously corrupted (etc/shadow, sddm config, etc…). Also given that the issue affects all 3 bootable images it seems more likely to me that a service isn’t starting (polkit?) or assn is unable to communicate with the appropriate service.
What I’m trying to figure out is next troubleshooting steps. From the chrooted system, what logs can I access that would give me clues about services loaded/failed or communication failures, from last boot? Is there some way to use rpm-ostree or ostree to assess the health of the boot images? Or something similar? What other troubleshooting steps are available to me?
When reaching SSDM, and you open a text console (with Ctrl+Alt+F3 or similar), can you log in from there? If not, then this might be a security context issue (though I don’t understand how such an issue could be caused by a theme package).
Can you log in with SELinux set to permissive mode, by editing the GRUB entry at boot time for one of the available deployments, and adding enforcing=0 at the end of the line starting with linux?
Alternatively, one could force the auto-relabeling of the file system by adding autorelabel=1 parameter on the boot command line (as above). I have tested this on a Silverblue test system, and, as expected, received a bunch of errors regarding the read-only nature of the the OSTree images, so do use it with caution, preferably after having performed the necessary backups. Even though I had no issues afterwards, and could log into the system, it might behave differently on other systems.
So rooting around using a recovery shell is more confusing on an ostree based system than typical Linux install, that’s for sure. I found the journal files hidden way down under /root/ostree/deploy/fedora/var/log/journal/
It actually looks like I am authenticating, a session is started, and then instantly ends. The only “smoke” I can find is after starting the Wayland user session for me, sddm-helper exits with an exit code of 127.
It looks like sddm-helper is in the middle of passing things off to /etc/sddm/wayland-session and start-sway. Then exit code of 127.
That being said Ctrl+Alt+f3 does let me get a tty login to my actual system, so maybe troubleshooting will get a little easier from here. Rpm-ostree rollback didn’t fix it so…
Figured it out. The issue was entirely self inflicted.
Thanks for the advice to switch to a tty login. start-sway is the equivalent of startx, just for sway.
Anyways, long story short I looked through the sddm config to try and find the answer to why login would succeed but my user session would close immediately. The sddm config file points to .cache/wayland-errors as the file where Wayland session errors are written. Turns out I had put some readline settings in my .bashrc (which should be in .inputrc). It looks like the way the Wayland session is started, it would load up the .bashrc, which would then cause an error causing the whole process to fail.
Removed the settings and login works again.
Lesson learned: ostree systems are not so different from typical Linux after all.
