Bug 1879313 - Changed runlevel to 3 in NEW FC34; couldn't login
Summary: Changed runlevel to 3 in NEW FC34; couldn't login
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: polkit
Version: 34
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jan Rybar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-16 01:14 UTC by George R. Goffe
Modified: 2021-02-09 16:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
test attachment; please disregard (2.03 KB, application/gzip)
2020-09-22 04:40 UTC, George R. Goffe
no flags Details
gzip'd flat file; /var/log/secure (2.03 KB, application/gzip)
2020-09-22 04:41 UTC, George R. Goffe
no flags Details

Description George R. Goffe 2020-09-16 01:14:23 UTC
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

Comment 1 Jan Rybar 2020-09-17 13:18:09 UTC
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?

Comment 2 George R. Goffe 2020-09-18 20:35:41 UTC
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...

Comment 3 George R. Goffe 2020-09-19 18:55:06 UTC
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...

Comment 4 George R. Goffe 2020-09-22 04:40:21 UTC
Created attachment 1715625 [details]
test attachment; please disregard

Comment 5 George R. Goffe 2020-09-22 04:41:07 UTC
Created attachment 1715626 [details]
gzip'd flat file; /var/log/secure

Comment 6 Ben Cotton 2021-02-09 16:11:33 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.


Note You need to log in before you can comment on or make changes to this bug.