Created attachment 1785 [details]
Xorg.0.log

Created attachment 1786 [details]
kdm.log

Created attachment 1787 [details]
boot.log

Created attachment 1788 [details]
.xsession-errors

Created attachment 1789 [details]
xorg.conf

I will leave this system untouched for now, so if any other details are need they will be available.

.xsessionerrors looks interesting :-

"Control process died, committing suicide! "

I did a net install last night to help with another bug and this still has the same issue.
This is the report.bug.gz from that install which is attached to bug 5040 
https://bugs.mageia.org/attachment.cgi?id=1819

Priority: Normal => release_blocker
Severity: major => critical

I have a similar set-up, a full KDE installed from Beta 2 as an install, not an upgrade.  I can use KDE and KDM quite normally.  Do we have a bug that affects only some users?

CC: (none) => laidlaws

(In reply to comment #7)
>Do we have a bug that affects only some users?

Yes it must be hardware specific.
The system I am using now (beta2 full KDE install) had the same issue, however after switching the graphics driver from the default nouveau to vesa and then back to nouveau, it now works and boots fine.

I now have two test installs (real, not vm) that I have left broken for debugging.

I am open to suggestions.

I know the feeling.  I have a similar bug in Xscreensaver (bug 4742.)  But this one is marked as a release-stopper.

There was a report of problems with nVidia, but you and I are both using nouveau.

Progress!

After KDE log-in at the black screen (with cursor), if I switch to tty2, log-in as root and :

pkill kwin

then switch back to tty1 and the KDE desktop is up and running correctly.

Maybe we should not enable kwin by default ?

Maybe.  kwin had problems earlier.  You can choose a different DM with MCC, under Boot/Display Manager.  Worth a try.

If it is hardware-related and you have two boxes displaying it, is their hardware the same?

To add to my last post - when using pkill kwin there is still a problem. Application windows have no headers, but seem to function otherwise.

All systems are on the same h/w.

Yes thanks Doug - I just installed GDM and even with kwin enabled it cures the problem completely, so this does look like it's maybe a KDM issue.

The only problem I have with that, is that this system that I am using now (on the same machine) uses KDM, kwin is enabled, it was installed from the same Beta2 iso and it is fully up-to-date.
It did have the issue just after installation, and I somehow fixed it (I wish I knew how) but now it's fine.

A new net install today still has the same problem. (with udev-181-4.mga2 update)
Disabling kwin in systemsettings fixes it with no other side effects that I can find.

I think that unless a real fix for this is found we should disable kwin for KDE installs and add something to errata to warn that possible problems may be encountered using kwin with KDM and nouveau on some hardware.

There is no knowing how widespread this problem will be until release, so better to be safe IMHO.

It was marked as a release-blocker: there will be no release until it is fixed.  But I won't interfere.

(In reply to comment #13)
> A new net install today still has the same problem. (with udev-181-4.mga2
> update)
> Disabling kwin in systemsettings fixes it with no other side effects that I can
> find.
> 
> I think that unless a real fix for this is found we should disable kwin for KDE
> installs and add something to errata to warn that possible problems may be
> encountered using kwin with KDM and nouveau on some hardware.
> 
> There is no knowing how widespread this problem will be until release, so
> better to be safe IMHO.
I hope you're not serious when suggesting to disable kwin here nor that you expect to run KDE without a windows manager.
You should here open a bug upstream (aka KDE) with some traces to help kwin maintainer to narrow the bug.
If the bug only occurs when using kdm/systemd combo and not with gdm/systemd or kdm/sysvinit than it's probably yet another acl problem and we need colin's help here.

I know sander was looking into kwin issues last night.

Not sure I can specifically help at this stage, but I doubt it's an ACL issue specifically - that doesn't generally seem to be an issue under kdm, tho' it is very strange that using GDM seems to help.

Perhaps this is magically fixed now with latest systemd+kdm? Worth trying but I wouldn't hold out too much hope!

This also affects the mga2 beta3 LIVE KDE CD.

Boot looks fine until the KDE tools icons are appearing across the bottom of the splash screen and then the screen goes black with just a working mouse cursor.

Logging in as root on tty2, followed by
pkill kwin
brings up a slightly broken (window top bars missing) system on tty1.
If "enable desktop effects" is unchecked in systemsettings and 
systemctl restart dm.service 
is run from tty2 then a working system is available on tty1. (window top bars no longer missing).

(In reply to comment #17)
> 
> Logging in as root on tty2, followed by
> pkill kwin
> brings up a slightly broken (window top bars missing) system on tty1.

Of course, kwin is the kde window manager. If you kill it, you lost the title bar and window decorations.

> If "enable desktop effects" is unchecked in systemsettings and 
> systemctl restart dm.service 
> is run from tty2 then a working system is available on tty1. (window top bars
> no longer missing).

This bug is hardware specific, but it seems to affect only a few users.

Kwin doesn't work correctly with desktop effects for your video card with the current video card driver.

Probably, you should be able to disable desktop effects at runtime when the screen goes black by Alt+Maj+F12, and then you will be able to definitively disable them in systemsettings.

You seem to have 2 systems affected by this bug; do they use the same video card?


(In reply to comment #8)
> The system I am using now (beta2 full KDE install) had the same issue, however
> after switching the graphics driver from the default nouveau to vesa and then
> back to nouveau, it now works and boots fine.
> 

Here, it seems that the installer doesn't have correctly install the driver or the xorg config for this system. Does this system now works correctly?

Silly question, have you tried a gnome install instead? So we can see if a kde only problem or anything else.

CC: (none) => anaselli

(In reply to comment #19)
> Silly question, have you tried a gnome install instead? So we can see if a kde
> only problem or anything else.

I did a Gnome net install a couple of days ago and didn't see this problem.

I am not experiencing this bug, so I will drop off the list for it.

Could you please reply to the questions in comment 18?

Does the workaround with Alt+Maj+F12 work?

same video card on the 2 systems?

One system seems to work after switching to vesa, then return to nouveau. Is it working correctly after this?

Keywords: (none) => NEEDINFO

Sorry Luc I have been busy.

Using Alt/Shift/F12 does immediately clear problem. That's very handy ;)

All systems are on the same physical hardware - just different partitions.

The system that I am using now does continue to work (in my user only) when I switch to kwin effects - this is the one that first encountered the problem.

IIRC I switched to vesa and then back to nouveau, I also tried nv which worked, but has horrible text rendering issues.

Adding to the above I can boot fully into my current Cauldron with kwin enabled, on just this one installation (the first one that had video drivers switched about). 
It only works in *my* user, not Xguest or my "Joe Bloggs" second user.

I wish I could think where to look for the difference.

What groups is your user in? Perhaps you have a logind/consolekit configuration problem?

Hi Colin,
Nothing special - baz is in baz - nothing else.
Likewise with Joe and xguest, just in their own default groups.

Barry

(In reply to comment #23)
> Sorry Luc I have been busy.

no problem

> 
> Using Alt/Shift/F12 does immediately clear problem. That's very handy ;)

Well, at least we have an easy workaround. I will add it in errata.

>  
> All systems are on the same physical hardware - just different partitions.
> 

OK

Last week (mageia-kde4-config-2-0.20120422.1), I slightly modified the default kwin config (global kwinrc). The change can't fix the config for existing users, but could help for new account.
Could you try to create a new user and see if the change help in your case?

(In reply to comment #27)
> 
> Last week (mageia-kde4-config-2-0.20120422.1), I slightly modified the default
> kwin config (global kwinrc). The change can't fix the config for existing
> users, but could help for new account.
> Could you try to create a new user and see if the change help in your case?

No change :(

I fully updated the system and added new user.

I can still boot into baz with kwin enabled, but not into fred (he's the new user)

I also fully updated another installation (via chroot) and have yet to boot into it and add a new user - will report back.

Lowering to 'high' priority.

Priority: release_blocker => Low
CC: (none) => guillomovitch

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Yes - flagged for mga2 too.
Reduced priority since workaround is acceptable and it only seems to affect old hardware.

Keywords: NEEDINFO => (none)
Priority: High => Normal
Whiteboard: (none) => MGA2TOO
Severity: critical => normal

Closing as fixed since no one else is experiencing this and my affected hardware has died and been replaced.

Status: NEW => RESOLVED
Resolution: (none) => FIXED