Bug 726896

> I can login as root and then run startx

What if you run "rcxdm start" instead? What happens? Any error message?

I tried, x starts, graphical login screen appears, no errors.

Seems you've booted into runlevel 3.

But why, I upgrade a working system, 12.1 beta1, to 12.1 RC1? And then, how do I get that fixed, with systemd? (I still need to figure out lots about systemd, it's also not easy to use without any boot messages available on screen)

Well, I'm not familiar with systemd either. Frederic, any hints you can give us?

could you start your system with the following added to your boot command line :
systemd.log_level=debug systemd.log_target=kmsg

and once system is booted (text mode, since display manager doesn't start), run dmesg and attach its output to this bug report. 

Thanks.

I initially thought i had the same issue but while trying to reproduce it i found that X _does_ start, but only 30 seconds after the login prompt appeared which is quite a bad user experience.

David, is that the same for you or is it a different issue?

I'll attach my dmesg output below, maybe it helps.

Created attachment 459611 [details]
dmesg output with systemd debug messages

you have a network timeout and remotefs (either nfs or samba) involved, which is causing a 30s timeout.

are you using NetworkManager or legacy ifup ?

I use NetworkManager, and yes, i have my home on NIS (which works fine).

Hm, ok. i just double-checked and my system is configured to use ifup...

(In reply to comment #7)
> I initially thought i had the same issue but while trying to reproduce it i
> found that X _does_ start, but only 30 seconds after the login prompt appeared
> which is quite a bad user experience.
> 
> David, is that the same for you or is it a different issue?
> 
> I'll attach my dmesg output below, maybe it helps.

I noticed it takes rather long before the graphical login starts, the first times I thought it didn't start, then I discovered this, so I wait a while. But it's not 30 seconds, a lot less.

O, I now see what I wrote. When it worked, before, I didn't have to wait that long, now I wait and nothing happens.
I will try and send a dmesg output.

On my own laptop with intel graphics, after a fresh install, I cannot get x to start either. Whatever I try, nomodeset, intellegacy, nothing. Well, actually, it does start, but when I wait a while before entering password, it leaves the graphical shell and returns to console with a no responding system. Or when I login quicker, it starts the KDE session but just at the moment I see my desktop the same thing happens. Shall I create a different bug report for this?

Created attachment 459634 [details]
dmesg output

Ok, here the dmesg output

(In reply to comment #13)
> O, I now see what I wrote. When it worked, before, I didn't have to wait that
> long, now I wait and nothing happens.
> I will try and send a dmesg output.
> 
> On my own laptop with intel graphics, after a fresh install, I cannot get x to
> start either. Whatever I try, nomodeset, intellegacy, nothing. Well, actually,
> it does start, but when I wait a while before entering password, it leaves the
> graphical shell and returns to console with a no responding system. Or when I
> login quicker, it starts the KDE session but just at the moment I see my
> desktop the same thing happens. Shall I create a different bug report for this?

Did another test since I have a problem with the encrypted /tmp on the intel laptop, seems that was the cause, because now it starts without a problem. /tmp failed to mount, and obviously without tmp x cannot start.

Frederic, could you also verify what the original reporter meanwhile attached? Andre wasn't the original reporter ...

This is what always happens in bugzilla. Either you don't get (useful) feedback or feedback from the wrong person. :-(

David, you have a dependency cycle which should be fixed in RC2 (my guess is you are either using encrypted swap or an encrypted partition with /dev/random as password). Anyway, it doesn't belong to this bug report.

Andre, all I see is network service waiting for 30s

Thanks, Frederic. This confirms, that this bugreport landed in the wrong court. Reassigning to Frederic for now.

The original bug report was about my Acer aspire One 522 with AMD C50 processor and ATI video card, and the dmesg output that I attached was taken from this one. Does that mean that one is also caused by the encrypted swap and tmp? If so I will see this in a few days when I can install RC2

David, yes, I think it should be fixed in RC2. Closing as fixed for now, reopen if needed.

This is still the same in RC2. In the end I removed systemd and now the system starts as expected, graphical login appears, still one thing not working but that is not in the scope of this bug. It seems this bug was entirely related to systemd which doesn't seem ready for prime time yet. I have even started considering returning to windows. This says enough taken that I have been with suse since 8.2! Getting this version 12.1 running well gives me headaches and I wonder if it will be any better when the final release comes out, sorry.

if it is still not working with RC2, reopen this bug and attach dmesg output when booting with systemd.log_level=debug systemd.log_target=kmsg

Created attachment 460977 [details]
dmesg output

Started with systemd and debugging enabled

In RC2 same issue

your system is not configured to boot in graphical.target (ie new name for runlevel 5), now that systemd is not reading /etc/inittab after initial install

ln -s -f /lib/systemd/system/runlevel5.target /etc/systemd/system/default.target 

should fix this issue.

That fixed it, thanks. Maybe something that should be checked during upgrade since this was after zypper dup from a previous 12.1 where systemd obviously wasn't used yet.

closing as fixed