Can't reach graphic mode

English Install/Boot/Login
#1

Greetings,
I recently installed 12.3 64 bit on my laptop that previous had 11.4 32 bit. After years of using 11.4, I was reluctant to delete it so I installed 12.3 to a different partition. After a hitchfree install, I had 11.4 and 12.3 installed. To make my migration easier, I shared some vital folders in my home folder. For a while I had a perfect system with 11.4 and 12.3 running. After a few days, I started slowly removing the shared components as I installed.
A few days a go, I rebooted and suddenly the system stops and the text screen showing that ‘graphic mode reached’ or something like that. I can’t paste the exact statement since I am currently in X writing this. Anyway, after battlling this for days, my work around is to boot into text then run init 5 and all is well. Only init 5 works. If I run ‘systemctl start gdm.service’ or kdm.service, it fails.

How can I get my system to boot straight to graphics again?

#2

So tell us about your computer and its graphic hardware. My normal suggestion is to switch to kernel 3.10.5 right now and see if that helps. I have a blog that gives all of the ways one can upgrade your kernel version.

openSUSE and Installing New Linux Kernel Versions - Blogs - openSUSE Forums

What you are seeing is being switched to the Graphics Mode, but the X window system did not load. You can use Ctrl-Alt-F1 or F2 or F3 to load virtual desktop sessions when this occurs and log in as root or as a normal user.

Thank You,

#3

Thanks for your suggestion. I’m updating my kernel first then I’ll let you know if this solves my probs.

#4

Good luck and do come back and let us know of your success.

Thank You,

#5

Well, if “init 5” works, the problem can’t really be in the kernel or video drivers.

Only init 5 works. If I run ‘systemctl start gdm.service’ or kdm.service, it fails.

That’s normal. There is no gdm.service or kdm.service.
Both kdm and gdm are started by the “xdm” init script.

So “systemctl start xdm” should work.

How can I get my system to boot straight to graphics again?

The question is, why is it not working in the first place?
What does “systemctl status xdm” say, when it doesn’t work?

If “init 5” works, I see no reason for directly booting to graphical target should fail…

Maybe disabling plymouth would help?
Press ‘e’ at the boot menu, search for the line starting with “linux”, and append “plymouth.enable=0” at the end of it.
Then press F10 to boot.

#6

sorry, I meant xdm.service not gdm. anyway here is the output to systermctl status xdm.service:

xdm.service - LSB: X Display Manager
Loaded: loaded (/etc/init.d/xdm)
Active: failed (Result: exit-code) since Mon, 2013-08-12 20:42:35 WAT; 1min 38s ago
Process: 1267 ExecStart=/etc/init.d/xdm start (code=exited, status=1/FAILURE)
CGroup: name=systemd:/system/xdm.service

Aug 12 20:42:35 iomari.home systemd[1]: Starting LSB: X Display Manager…
Aug 12 20:42:35 iomari.home xdm[1267]: Starting service gdmgdm[1278]: CRITICAL: error getting system bus: Could not connect: No such file or directory
Aug 12 20:42:35 iomari.home startproc[1277]: startproc: exit status of parent of /usr/sbin/gdm: 1
Aug 12 20:42:35 iomari.home xdm[1267]: …failed
Aug 12 20:42:35 iomari.home systemd[1]: Failed to start LSB: X Display Manager.
Aug 12 20:42:35 iomari.home systemd[1]: Unit xdm.service entered failed state

#7

This would indicate that dbus.service is not running when xdm is started.
So, what’s the output of:

systemctl status dbus.service

and, since this one is socket activated:

systemctl status dbus.socket

Note that this is needed from the time BEFORE you run init 5. So maybe redirect the output to a file, so you can post it afterwards (by appending “> filename” to the commands).

And did I understand you right:
The 11.4 and the 12.3 install were on completely different partitions, only some folders in /home were shared?
Or did you also share other things, like /etc f.e.?
And the 12.3 was a fresh install, not an upgrade, right?

#8

The 11.4 and the 12.3 install were on completely different partitions, only some folders in /home were shared?
Or did you also share other things, like /etc f.e.?
And the 12.3 was a fresh install, not an upgrade, right?[/QUOTE]

Here is the dmesg output. I think I see the prob but don’t know how to fix it. You mentioned about dbus and this is what I found:

9.960113] systemd[1]: Found ordering cycle on basic.target/start
9.960122] systemd[1]: Walked on cycle path to sockets.target/start
9.960126] systemd[1]: Walked on cycle path to dbus.socket/start
9.960129] systemd[1]: Walked on cycle path to sysinit.target/start
9.960133] systemd[1]: Walked on cycle path to uptimed.service/start
9.960136] systemd[1]: Walked on cycle path to basic.target/start
9.960140] systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start
9.960224] systemd[1]: Found ordering cycle on basic.target/start
9.960228] systemd[1]: Walked on cycle path to cups.path/start
9.960231] systemd[1]: Walked on cycle path to sysinit.target/start
9.960235] systemd[1]: Walked on cycle path to uptimed.service/start
9.960238] systemd[1]: Walked on cycle path to basic.target/start
9.960241] systemd[1]: Breaking ordering cycle by deleting job cups.path/start
9.960286] systemd[1]: Found ordering cycle on basic.target/start
9.960290] systemd[1]: Walked on cycle path to sockets.target/start
9.960293] systemd[1]: Walked on cycle path to cups.socket/start
9.960296] systemd[1]: Walked on cycle path to sysinit.target/start
9.960300] systemd[1]: Walked on cycle path to uptimed.service/start
9.960303] systemd[1]: Walked on cycle path to basic.target/start
9.960307] systemd[1]: Breaking ordering cycle by deleting job cups.socket/start
9.960348] systemd[1]: Found ordering cycle on basic.target/start
9.960352] systemd[1]: Walked on cycle path to sockets.target/start
9.960356] systemd[1]: Walked on cycle path to avahi-daemon.socket/start
9.960359] systemd[1]: Walked on cycle path to sysinit.target/start
9.960362] systemd[1]: Walked on cycle path to uptimed.service/start
9.960366] systemd[1]: Walked on cycle path to basic.target/start
9.960369] systemd[1]: Breaking ordering cycle by deleting job avahi-daemon.socket/start
9.960410] systemd[1]: Found ordering cycle on basic.target/start
9.960414] systemd[1]: Walked on cycle path to sockets.target/start
9.960417] systemd[1]: Walked on cycle path to pcscd.socket/start
9.960421] systemd[1]: Walked on cycle path to sysinit.target/start
9.960424] systemd[1]: Walked on cycle path to uptimed.service/start
9.960427] systemd[1]: Walked on cycle path to basic.target/start
9.960431] systemd[1]: Breaking ordering cycle by deleting job pcscd.socket/start
9.960472] systemd[1]: Found ordering cycle on basic.target/start
9.960476] systemd[1]: Walked on cycle path to sysinit.target/start
9.960479] systemd[1]: Walked on cycle path to uptimed.service/start
9.960482] systemd[1]: Walked on cycle path to basic.target/start
9.960486] systemd[1]: Breaking ordering cycle by deleting job uptimed.service/start

How do I stop the process from deleting the dbus.socket?

#9

I never asked for the dmesg output.
And I can’t really read anything out of it.

I hope the systemctl output as requested by me would show a clue.

If not, maybe “journalctl” will do… :wink:

#10

SOLVED:

I had to add the following lines to my graphical.target:

Requires=dbus.service polkit.service
After=dbus.service polkit.service

Thanks for everyone’s help. I found the answer in a bugzilla report:

#11

OK, but this shouldn’t be needed.

But if it helps you, good.

I hope you did that change in /etc, otherwise it will get overwritten by a systemd update… :wink: