Description of problem:With a freshly installed FC 34 (KDE desktop) I changed runlevel from 5 to 3. I was unable to login either as root or a general user. I switched back and was able to login. This seems to be incorrect behavior to me. Version-Release number of selected component (if applicable): polkit-0.117-2 How reproducible: seems to be readily reproducable Steps to Reproduce: 1.install the iso from below 2.systemctl set-default multi-user.target 3.reboot Actual results: Expected results: Additional info: Fedora-Everything-netinst-x86_64-Rawhide-20200828.n.2.is
Hello, tried both Gnome and KDE desktops and everything works fine for me. Only struggle was with changed keyboard local layout (defaulted to EN_us on multi-user.target). Can this be the issue? I feel needed to point out that polkit has nothing to do with logging-in. After isolating multi-user.target, polkit.service was not even running (not the case of set-default). Can you verify the issue on your system even with some really easy passwd?
Jan, Thanks for responding. I'll post the secure log file after I'm done with this post. Initially, I changed the default run level I rebooted. I would enter the userid and get the "password" prompt. Immediately after entering the password, the screen would flash. I'm pretty sure there was a message but I couldn't see it. I tried several times. I tried my own personal userid. SAME behavior. I tried a single user boot. From this, I do seem to recall seeing something about "cannot su". I went back to check the permissions for root and my personal id. No problems found. Keep in mind that this is EARLY in the system's life... right out of the box. I changed back to runlevel 5 and was able to login via kde. I "fixed" the root userid so there was no password required. Switched back to runlevel 3 and rebooted. AGAIN, same behavior. I started patching the system by adding various groups. This went VERY SLOWLY. I'm not sure just why. This IS a Virtual Machine running under QEMU. After several attempts at upgrading I tried the runlevel 3 change. IT WORKED! So, back to the failures. I have 3 coredumps on this system sddm first then klauncher and then kglobalaccell5, all at the same time. From the secure file it does show a crash. Currently, runlevel 3, at my first login as root I'm greeted by a bunch of messages about xdm. This is repeatable but I'm gonna have to work at trapping the messages. QEMU networking is somewhat difficult... so I can't ssh to the guest and trap the messages. I'll report more if/when I am able to trap the messages. Any thoughts you have about this problem would be greatly appreciated. Best regards, George...
Jan, I have a gzip'd file named secure.gz from /var/log/secure that I'm trying to append/add to this bug report. Last night I got a server 500 twice for my trouble. I'll try again in a few minutes. There were NO apparent error messages from this web site. Sigh... George...
Created attachment 1715625 [details] test attachment; please disregard
Created attachment 1715626 [details] gzip'd flat file; /var/log/secure
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.