You are not logged in.
The last functioning state of my system was the 20th May 2022 — all subsequent upgrades cause me to be unable to log into my user session (graphical or otherwise, wayland or X11), although I can log in as root.
If I open a root session on TTY2 and log in either graphically (TTY7 or in a terminal TTY3) I get the same behaviour — the process either freezes with a cursor and a black screen after lightdm tries to start the graphical session or just a blinking cursor in the terminal which eventually kicks me back to the login prompt. In TTY2, using `journalctl -fxeb0`, I see that dropbox keeps trying to start and fails, but uninstalling dropbox doesn’t fix the problem (just the logs).
I *suspect* there is a dbus issue, as if I “su” into my user as root, and try to use systemctl to disable any user units, I get an error about dbus permissions. I don’t know if this is normal.
This was happening on the same kernel as my stable system, and is not fixed by the latest kernel either.
I’m at a bit of a loss as to how to proceed (rolling back results in a stable system, so I can sit at 2022/05/20) and debug this properly, especially as root can login, “su gideon” works as root, but actual session login does not.
Last edited by gtf21 (2022-07-24 15:14:56)
Offline
It *could* be something to do with xcb-utils and other X-related things as I have a lot of units whichuse X which start on login (dunst, redshift-gtk, dropbox) and these seem to be doing core dumps regularly when I start a session, and I can see lots of mentions of xcb*, libX*, and so on. Xcb-utils et al. were upgraded in the system upgrade. It does seem to be related to font rendering (pango/cairo) within X.
Offline
unable to log into my user session (graphical or otherwise
The rest of your posts seem to contradict the "or otherwise" thing. If you boot the multi-user.target (2nd link below) can you the login as gideon?
Offline
I tried setting the multi-user target as default, rebooting, and logging in and I get the same behaviour: it hangs when I try to log into my user, but logging in as root works (from which I can “su gideon” but when I so, systemctl —user gives me “permission denied”).
(This is with a full system upgrade performed on Friday 17th June.)
Last edited by gtf21 (2022-06-19 20:00:48)
Offline
Move your users profiles (eg. for bash ~/.bashrc, ~/.bash_profile and ~/.profile) out of the way (somewhere else)
Can you now login?
Offline
I tried again which a system upgrade today (23/07/22) and same problem occurs, even when I have:
- deleted .zsh .zshrc .zshenv
- deleted .xprofile
- deleted .config/i3
I’m concerned that there might be a few systemd services under my user which are causing the issue, because:
1. If I login to root then sudo su gideon, I can log in
2. If I login to gideon (on a terminal tty) I cannot log in
3. If I login through a lightdm to start an X session, I cannot log in
4. If I login to root, sudo su gideon, then try to do systemctl —user list-units, I get:
Failed to connect to bus: No medium foundSystem is still unusable unless I rollback
Offline
I disabled the display manager unit via
systemctl disable lightdmAnd rebooted, and then:
1. on tty2 started a root session, did sudo su gideon, and then watched the journal with
journalctl -f > /path/to/file2. on tty1 I tried to login as gideon
The output is is here: http://0x0.st/oju8.txt
I'm not 100% sure, but it seems to be a set of issues with pam / dbus.
Last edited by gtf21 (2022-07-23 17:08:55)
Offline
You login fine, then something™ (smells like a user service) wants to start gnome-gkr and ~1m later the session terminates
Jul 23 18:53:58 anaximander systemd[1]: Started Session 7 of User gideon.
Jul 23 18:53:58 anaximander login[1197]: pam_env(login:session): deprecated reading of user environment enabled
Jul 23 18:53:58 anaximander systemd[1243]: Starting Gnome Keyring Daemon...
Jul 23 18:54:45 anaximander mullvad-daemon[1013]: [mullvad_daemon::version_check][DEBUG] Writing version check cache to /var/cache/mullvad-vpn/version-info.json
Jul 23 18:54:45 anaximander mullvad-daemon[1013]: [mullvad_daemon::management_interface][DEBUG] Broadcasting new app version info
Jul 23 18:54:55 anaximander systemd[1]: getty@tty1.service: Deactivated successfully.What if you chsh to /bin/bash and do you have OMZ installed?
Offline
I’ll see if I can disable some user services but I can’t get systemctl to work in my “sudo su” session even when I set the DBUS_SESSION_BUS_ADDRESS to “unix:path=/run/user/1000/bus” — this worked once for me but then never again as the bus is never created.
Offline
https://wiki.archlinux.org/title/System … asic_setup
What if you chsh to /bin/bash and do you have OMZ installed?
Offline
I tried chsh to bash — still doesn’t work. I assume OMZ is oh my zsh, which I have never used. I’ve also removed all the zsh config files as per previous post, and have tried removing all files from default.target.wants and timers.target.wants in ~/.config/systemd/user. I still can’t log in (that log fole was sent after removing all the zshrc files and the systemd files).
Offline
I found it! In /etc/pam.d/login there is a line which automatically starts gnome keyring as per https://wiki.archlinux.org/title/GNOME/Keyring
Commenting this line allows me to login.
Offline
What did the line (singular?) actually say?
Ideally post the entire login pam config that has caused this.
If there's a (kinda really severe) problem w/ the config exampled in the wiki, this needs to be brought up with the wiki.
Also please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
Offline
I’ll post the config lines in a bit, but in a way the issue isn’t resolved — gnome-keyring-daemon now just doesn’t work (and I use it for quite a lot of stuff). Unfortunately I’m a bit lost as to why because it doesn’t log anything except that it is starting (and it just hangs there).
Offline
Ok, so, in /etc/pam.d/login, I commented out the line which says:
session optional pam_gnome_keyring.so auto_startBut it turns out that lightdm also auto-starts gnome-keyring-daemon if it's present (by default), so I had to edit /etc/pam.d/lightdm and comment out the following lines:
-auth optional pam_gnome_keyring.so
-session optional pam_gnome_keyring.so auto_startFinally, because I set gnome-keyring-daemon to autostart by copying files into /etc/xdg/autostart as per somewhere I can't remember, but I don't think it was the wiki (maybe it was the gnome-keyring-daemon instructions, I had to take every file gnome-keyring-daemon*.desktop and add
Hidden=trueThis fixed my session not logging in, but gnome-keyring-daemon still doesn't work.
Offline
You could try to explicitly run gnome-keyring from an interactive shell and see what it does.
Maybe gdb or strace it.
Offline
Ok, well since this fixes the login issue what I'll do is mark it as resolved and open a new topic for the gkd issue.
Offline