You are not logged in.
One of my 3 machines is failing to log in. It was working perfectly fine until I rebooted it. On boot, it hangs on 'Starting Switch Root...' for about 2 minutes. Afterwards, it does make it past the boot screen and to SDDM (I'm using KDE). However, the shutdown/sleep/reboot buttons on SDDM are greyed out and non-functional. Attempting to log in a Wayland session results in a black screen. An X session gives the same result but with the addition of a non-functional cursor after another 2 or so minutes of waiting. Attempting to switch TTY (Alt + F*) on SDDM or the black post-login screen gives yet another black screen with no terminal prompt. I have been able to chroot into the system with an install USB just fine. I've already tried running pacman -Syyuu from within chroot and also regenerating the kernel EFI image with no effect. Running a journalctl -p3 and finding the latest failed boot reveals the following error messages: https://imgur.com/a/oePq2jl (Sincere apologies for the photo of a screen) Fortunately, this is not a system that holds any important info so I could just reinstall, but I would like to not have to set up what was a working system again. Any help is greatly appreciated.
System Info: Lenovo Thinkcentre M93P i7-4790k 16GB DDR3 500GB SSD Arch + KDE on btrfs Booting with Dracut unified EFI image + Plymouth + full disk encryption
Last edited by RamenFiend (2022-08-16 19:50:06)
Offline
Please post the full (without priority filtering) journalctl output you obtained from the chroot as text. See the examples from pastebin to pipe the output from the console to a pastebin.
Last edited by loqs (2022-08-15 20:06:59)
Offline
Offline
Screenshot is from 13. 8., journal starts at June, the alst two recorded boots are from 13. 8. and 15. 8., but the latter is the iso.
I guess because of
the shutdown/sleep/reboot buttons on SDDM are greyed out and non-functional … Attempting to switch TTY (Alt + F*) on SDDM or the black post-login screen gives yet another black screen with no terminal prompt.
you're rebooting w/ the power button?
Don't.
Frenetically press ctrl+alt+del and if that also doesn't work, look at https://wiki.archlinux.org/title/Keyboa … el_(SysRq)
W/ a hard reboot, the journal isn't sync'd to disk and lost.
Alternatively, try to boot the multi-user.target instead of sddm (2nd link below)
Offline
https://0x0.st/o2Dv.txt
Thanks for the advice, I didn't realize it was dumping the journal. I changed to multi-user.target as per seth's link and after another long 'Changing Root' boot, was able to log-in on the device's tty. I had to boot back into the ISO to gather the log as I couldn't connect to the internet from on the device itself.
Offline
This set of journals has some boots from yesterday afternoon (~16:30) but the last sddm reference is on Aug 13 08:38:17
The entire "Transport endpoint is not connected" might be just spam, likely from dbus-broker. It's there in the earlier boots as well (since aug 8th, what kinda aligns w/ the dbus-broker installation), but after Aug 13 08:38:17 you're not even attempting the graphical.target except in the archiso boot.
Since you're posting the entire journal archive uncommented, maybe you should point out which boot we should focus on and whether that problem existed for a couple of days and the boots from yesterday are actually irrelevant and skewed by your attmpts to deal w/ the problem.
If the problems started w/ installing dbus-broker, remove that again for the time being.
Offline
Yesterday I changed the default target from graphical to multi-user, so thats why SDDM isn't in the most recent boot (Aug 15), at least I think. I can change back to graphical.target and boot, and then shut down gracefully with sysreq if I enable it (I couldn't get ctrl+alt+del to do anything). Dbus-broker installation on August 8th sounds right. The problem didn't align with that installation though, the system worked fine with dbus-broker from Aug 8 to 13. The boot on Aug 13 would be the first instance of the problem. The system had been on for a while, I ran a pacman -Syu (unfortunaltely I can't remember what got updated) and shut it down. When I started it back up again the problem appeared. All changes since then have been my attempts to fix it, mostly running pacman -Syyuu and regenerating the kernel EFI image.
Last edited by RamenFiend (2022-08-16 17:02:20)
Offline
Things actually change here:
Aug 08 07:35:34 HTPC systemd[1]: Switching root.
Aug 08 07:35:34 HTPC systemd-journald[217]: Journal stopped
Aug 08 07:37:04 HTPC systemd-journald[217]: Received SIGTERM from PID 1 (systemd).
Aug 08 07:37:04 HTPC systemd[1]: systemd 251.4-1-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK +XKBCOMMON +UTMP -SYSVINIT default-hierarchy=unified)
--
Aug 12 20:05:58 HTPC systemd[1]: Switching root.
Aug 12 20:05:58 HTPC systemd-journald[215]: Journal stopped
Aug 12 20:07:29 HTPC systemd-journald[215]: Received SIGTERM from PID 1 (systemd).
Aug 12 20:07:29 HTPC systemd[1]: systemd 251.4-1-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK +XKBCOMMON +UTMP -SYSVINIT default-hierarchy=unified)
--
Aug 12 20:11:21 HTPC systemd[1]: Switching root.
Aug 12 20:11:21 HTPC systemd-journald[216]: Journal stopped
Aug 12 20:12:51 HTPC systemd-journald[216]: Received SIGTERM from PID 1 (systemd).
Aug 12 20:12:51 HTPC systemd[1]: systemd 251.4-1-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK +XKBCOMMON +UTMP -SYSVINIT default-hierarchy=unified)
On Aug 08 the root switching is instant (and so is every boot I glimpsed at before) and becomes slow at Aug 12 w/ a 90 timeout (which is default for systemd)
=> remove dbus-broker, see what happens.
Offline
Well, removing dbus-broker has fixed the issue. I can boot in normally just fine again. I'm not sure why it caused that, especially when it works just fine on my other 2 machines, and I'm equally unsure as to why I didn't think to try that earlier. Thank you so very much for the help.
Last edited by RamenFiend (2022-08-16 19:50:26)
Offline
Do you get "Activation request for 'org.freedesktop.login1' failed." on the other systems?
Offline
No, none of the same 'Activation request failed' or 'Transport endpoint is not connected' errors appear on the other systems with dbus-broker installed and enabled.
Offline
See the note in https://wiki.archlinux.org/title/D-Bus#dbus-broker
Do those systems use apparmor as well?
Offline
No apparmor on any of the 3 systems.
Offline
Ah, sorry - you removed it on July 20th
It fails to activate the service because that has "Exec=/bin/false", so the question is why it can't connect itfp.
qdbus --system | grep login
qdbus --system org.freedesktop.login1
ps aux | grep login
Offline
Outputs of those commands while logged in without dbus-broker: https://0x0.st/oLsz.txt
Offline
Nothing special there (unsurprisingly)
Offline