You are not logged in.
Hello everyone i just switched to arch 2 days ago after years of Windows. I did follow the really good(!) guides and got all stuff up and running without any issues.
I did opt to install GNOME as GM and followed the guide to set things up using 'systemctl enable gdm.service' to set GDM to start on boot. This does unfortunately not work. I still get dropped to the command line on boot. I did check if the service is running, which it is. I can run GDM with 'systemctl start gdm.service' from there everything runs fine.
Any advice where i did make a mistake?
Regards
Kai
Edit:
Solution was to Unlink /etc/systemd/system/display-manager.service and the again enabling gdm service with systemctl enable gdm.service
Unfortunately I was unable to identify the root cause for this problem.
Last edited by KaiKratz (2013-06-30 21:25:21)
Offline
HI, welcome to the forums.
have a look at
$ systemctl list-units --type=target
for any non-active ones. Then have a look at your output of
$ systemctl status default.target
graphical.target - Graphical Interface
Loaded: loaded (/usr/lib/systemd/system/graphical.target; disabled)
Active: active since Di 2013-06-25 00:13:37 CEST; 4 days ago
Docs: man:systemd.special(7)
Jun 25 00:13:37 sonic systemd[1]: Starting Graphical Interface.
Jun 25 00:13:37 sonic systemd[1]: Reached target Graphical Interface
Offline
Hi Strike0,
thanks for your help.
This is what iv got:
$ systemctl list-units --type=target
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
cryptsetup.target loaded active active Encrypted Volumes
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical Interface
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target loaded active active Local File Systems
multi-user.target loaded active active Multi-User System
paths.target loaded active active Paths
remote-fs.target loaded active active Remote File Systems
sockets.target loaded active active Sockets
sound.target loaded active active Sound Card
swap.target loaded active active Swap
sysinit.target loaded active active System Initialization
timers.target loaded active active Timers
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
14 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
and
$ systemctl status default.target
graphical.target - Graphical Interface
Loaded: loaded (/lib/systemd/system/graphical.target; enabled)
Active: active since Sat 2013-06-29 21:45:54 CEST; 2min 8s ago
Docs: man:systemd.special(7)
I am not entirely sure what to look for, at least nothing strikes out to be as broken right away. If you can deduce a problem from this output can you please be so kind and hint me into the right direction?
Cheers
Kai
Offline
Can you do either just "systemctl" without any arguments, or do "systemctl --type=service" to see if GDM made an attempt at loading? Did it fail, or did it every try to load at all?
Edit: Nevermind, I now see that you checked to see that it s running. If it reports itself as ssuccessfully running, can you switch through all the virtual terminals and screens to see if it is just somewhere unexpected? Do ctrl+alt+F1 then F2, etc.
Last edited by WonderWoofy (2013-06-29 20:37:45)
Offline
Hi WonderWoofy,
This is what i get:
$ systemctl --type=service
UNIT LOAD ACTIVE SUB DESCRIPTION
dbus.service loaded active running D-Bus System Message Bus
getty@tty1.service loaded active running Getty on tty1
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service
systemd-remount-fs.service loaded active exited Remount Root and Kernel File Systems
systemd-sysctl.service loaded active exited Apply Kernel Variables
systemd-t...es-setup.service loaded active exited Recreate Volatile Files and Directories
systemd-udev-trigger.service loaded active exited udev Coldplug all Devices
systemd-udevd.service loaded active running udev Kernel Device Manager
systemd-update-utmp.service loaded active exited Update UTMP about System Reboot/Shutdown
systemd-u...sessions.service loaded active exited Permit User Sessions
systemd-v...le-setup.service loaded active exited Setup Virtual Console
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
12 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
Help me a bit here: Shouldn't I see the GDM.service somewhere here?
Just to check I didn't make a stupid mistake i tried to disable an enable the GDM.service while still on tty.
$ systemctl disable GDM.service
$ systemctl enable GDM.service
Failed to issue method call: File exists
Does 'File exist" imply in this context that the service is already 'enabled' to be run on every boot?
Did I understood the documentation correct that a single call to 'systemctl enable GDM.service' should set systemd to execute the GDM on every boot? Or did i maybe overlook any configuration step?
Cheers
Kai
Offline
The display manager aliases itself to display-manager.service, then by making the graphical.target the default.target, the (now aliased) display-manager.service is pulled in as a "Wants=" of the graphical.target. So you may need to go remove the symlink manually in /etc/systemd/system, which should be a symlink called display-manager.service that points to gdm.service.
Also, Linux is case-sensitive. So using GDM.service is likely not going to work, as most service files are all lower case. The one exception I have seen is the NetworkManager.service... I am unsure why NetworkManager gets away with this.
Offline
yes, try the bit WonderWoofy explains in the first para.
To your other questions: you should see gdm.service listed in your services output, yes. And if enabling it succeeds, the default runlevel will be graphical.target --> gdm. If you compare your last output in #3 to mine in #2, yours shows graphical.target enabled (mine disabled; interestingly).
edit: I just tried, enabling graphical.target did not matter in this case, it created the first symlink:
$ ls -la /etc/systemd/system
lrwxrwxrwx 1 root root 40 30. Jun 02:43 default.target -> /usr/lib/systemd/system/graphical.target
lrwxrwxrwx 1 root root 35 24. Apr 17:01 display-manager.service -> /usr/lib/systemd/system/gdm.service
Last edited by Strike0 (2013-06-30 00:51:32)
Offline
@Strike0,
Just to note that the first of those links is not necessary i.e. the default.target -> .../graphical.target one. That's because that is systemd's default anyway. For example, I do not have a default.target set there at all because I just use systemd's builtin default. The display-manager.service is crucial, though.
@OP,
Incidentally, the output you are posting suggests you are trying to enable gdm as a regular user. That won't work. You need to enable the service with root privileges in order for systemd to set up the necessary sym links.
Last edited by cfr (2013-06-30 01:55:31)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
@KaiKratz
Could you post the output of 'systemctl status gdm.service'?
thank you.
Offline
cfr, good to clarify, yes. As you can see in #2, I use default too. I enabled graphical only to see if it makes a difference at all for gdm, since KaiKratz obviously has it enabled. As expected it did not matter. So the second symlink is the one in focus indeed.
edit: rephrase
Last edited by Strike0 (2013-06-30 08:04:38)
Offline
Try doing this
https://bbs.archlinux.org/viewtopic.php … 7#p1294407
Sorry for being lazy, I'm on my ipad
bitcoin: 1G62YGRFkMDwhGr5T5YGovfsxLx44eZo7U
Offline
Hi guys,
Unlinking the the symlink and then enabling the service worked.
Thank you very much for your help
Cheers
Kai
p.s. If anyone feels bored you can straight head to my next question
Offline
Hello everyone i just switched to arch 2 days ago after years of Windows. I did follow the really good(!) guides and got all stuff up and running without any issues.
I did opt to install GNOME as GM and followed the guide to set things up using 'systemctl enable gdm.service' to set GDM to start on boot. This does unfortunately not work. I still get dropped to the command line on boot. I did check if the service is running, which it is. I can run GDM with 'systemctl start gdm.service' from there everything runs fine.
Any advice where i did make a mistake?
Regards
KaiEdit:
Solution was to Unlink /etc/systemd/system/display-manager.service and the again enabling gdm service with systemctl enable gdm.service
Unfortunately I was unable to identify the root cause for this problem.
Hi, sorry I do not understand the solution, would kindly explain the steps that led to this solution? Thank you very much.
Yo T vi salir campeón InTrnacional, yo T di la vuelta en la cara y vi como lloraste y T paraste a aplaudirme. Eso jamas se T va a olvidar.
Offline
KaiKratz wrote:Solution was to Unlink /etc/systemd/system/display-manager.service and the again enabling gdm service with systemctl enable gdm.service
Unfortunately I was unable to identify the root cause for this problem.Hi, sorry I do not understand the solution, would kindly explain the steps that led to this solution? Thank you very much.
When you "enable" a service, systemctl parses the [Install] section of the systemd.service, and uses that information to determine what it will do. In the case of gdm.service (as well as other display managers), they are aliased to display-manager.service. When the graphical.target is enabled, or booted to, it pulls in the display-manager.service as a dependency (Wants=display-manager.service). So it looks for that service in the usual places and runs that, whatever it is. So it will find the "enabled" /etc/systemd/system/display-manager.service and run that. In this case it is a symlink that points to /usr/lib/systemd/system/gdm.service.
So what KaiKratz did was manually delete the symlink /etc/systemd/system/display-manager.service. Then he used systemctl to re-enable the gdm.service. Presumably, the symlink must have somehow been borked, or pointed to the wrong place. So recreating it allowed to to fix it and point to the correct destination.
Offline
talleres wrote:KaiKratz wrote:Solution was to Unlink /etc/systemd/system/display-manager.service and the again enabling gdm service with systemctl enable gdm.service
Unfortunately I was unable to identify the root cause for this problem.Hi, sorry I do not understand the solution, would kindly explain the steps that led to this solution? Thank you very much.
When you "enable" a service, systemctl parses the [Install] section of the systemd.service, and uses that information to determine what it will do. In the case of gdm.service (as well as other display managers), they are aliased to display-manager.service. When the graphical.target is enabled, or booted to, it pulls in the display-manager.service as a dependency (Wants=display-manager.service). So it looks for that service in the usual places and runs that, whatever it is. So it will find the "enabled" /etc/systemd/system/display-manager.service and run that. In this case it is a symlink that points to /usr/lib/systemd/system/gdm.service.
So what KaiKratz did was manually delete the symlink /etc/systemd/system/display-manager.service. Then he used systemctl to re-enable the gdm.service. Presumably, the symlink must have somehow been borked, or pointed to the wrong place. So recreating it allowed to to fix it and point to the correct destination.
So first remove "/etc/systemd/system/display-manager.service" and then I enable gdm.service with "systemctl enable gdm.service"? Nothing more?
Last edited by talleres (2013-07-01 18:26:01)
Yo T vi salir campeón InTrnacional, yo T di la vuelta en la cara y vi como lloraste y T paraste a aplaudirme. Eso jamas se T va a olvidar.
Offline
@talleres, I don't really know what your issue is, or if it is the same as what was discussed in this thread. But what I described is what solved the issue for the OP. Whether or not i will solve your problem, I have no idea. So if your issue is the exact same as the OP, then yes, that is what solved it.
Offline
If I have this problem, but it turns out that now I have another because "gdm" takes way too to start.
Yo T vi salir campeón InTrnacional, yo T di la vuelta en la cara y vi como lloraste y T paraste a aplaudirme. Eso jamas se T va a olvidar.
Offline
If I have this problem, but it turns out that now I have another because "gdm" takes way too to start.
I don't understand this. However, if you have a problem different from the one discussed in this thread, I suggest starting your own thread because this one is marked as [solved] and is therefore unlikely to attract much further attention.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline