You are not logged in.
Today I ran an upgrade (since the last one in a week or so). Upon next boot I ended up with VT, systemd reporting reaching multi-user.target and X cursor, though gdm just didn't show up. While I was able to move mouse, VT didn't react on keyboard in any way (just as if it wasn't there).
Unfortunately, I had no time to properly investigate the issue. I rebooted to rescue.target, disabled and re-enabled gdm.service and booted to multi-user.target. This time gdm started normally.
I didn't yet have time to come back to that system yet, so I don't really have a clue about the root of the problem.
Edit: It appears I was overly optimistic. The system consistently fails to boot to working state, while booting it to rescue.target, starting multi-user.target from command line, logging in and restarting gdm.service consistently helps.
Last edited by czarkoff (2012-11-30 21:25:17)
Offline
Hi,
may not be related but I had similar failed systemd-logind.service , some dbus errros etc after
the last (eg filesystem 2012.10-2 -> 2012.11-1) update.I have ssd installation with /var symlinked to directory on other hdd partition.
I noticed the /var/lock and /var/run links wrong.
So I unlinked and re-created links to point to /run and /run/lock, all is fine now.
Maybe the problem is because of my unusual setup and not related to your at all,
anyway I think it is worth checking /var.
With systemd this is a very problematic setup, as systemd mounts partitions asynchronnously. So, there may be a time when /var points to an unmounted partition... Why is there a need for having /var as a symbolic link at all? Why can't you simply mount that hdd on /var?
Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd
Offline
The problem was in the systemd. When trying to fix I lost the sound and a smooth X display. I reinstalled the installation and all ok.
So you you suppressed the problem instead of fixing it...
Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd
Offline
So you you suppressed the problem instead of fixing it...
FYI, if I have controll over the system at the first place, I will fix and post the solutions. The systemd automates the things. I don't mind as long as suitable fixing/knowledge tools/documents are provided.
Systemd is challanging the Arch Way, which is good. But we have to remember that there are two sides in the coin..... system/improvements by devs and utilisation by users.
Markku
Offline