Created attachment 6315 [details]
Output from lsipcidrake on the machine exhibiting the fault

I have the same issue in my laptop with hybrid nVidia/Intel. I know Akien has too. Setting as release blocker for final release, hoping we can workaround the problem, although this takes part in a broader issue relating to nvidia Optimus support. If we can't, we'll have to make sure we mention it in the Errata.

Installing via classical installer and configuring only the Intel chipset (haven't tried other options with mga5 for now) works.

AFAIK it is not a regression since mga4 had the same problem for me. Martin, do the Mageia 4.1 LiveDVD ISOs perform the same for you?

Priority: Normal => release_blocker
CC: (none) => stormi, tmb
Severity: normal => major

I've not tested the 4.1 Live DVDs (I don't ever need them myself), and I'm running out of time to do any more testing today.

The fact that I can get to a working desktop via 'startx' suggests there is some hope this can be fixed in Mageia-5.

Assigning.

Please re-assign if I should have assigned to someone else

CC: (none) => marja11
Assignee: bugsquad => tmb

I've found a way to fix this on my laptop. With the GNOME Live DVD, adding the line

  xrandr --auto

near the beginning of /etc/X11/gdm/Init/Default does the job. It doesn't seem to cause any problems on my desktop with AMD graphics.

I doubt this will fix the problem for everyone, but it's a start.

Like Samuel, when I use the classic installer, I always select the Intel only option, and have never had any problems with that.

System Dell XPS L502x with intel/nvidia optimus vidio hardware.

I had the same problem with the 4.1 liveKDE iso.  In that case the rd.blacklist=nouveau rd.blacklist=nvidia xdriver=intel worked.  As above the classic installer I selected the intel and my installation has worked fine.

With the 5-rc live kde iso, the initial boot sequence comes up and flashes on and off, not really looking right, stutters.  Then a message that it is configuring hardware occurs and then it just goes blank with a dash in the upper left corner. 

The above fix does not work.  Using the Ctl-Alt BS BS during the flashing boot screens show the usual messages.  I don't know how to capture it.  

What does work is using xdriver=vesa along with the blacklists.  The display goes through visual hash and then continues on to the setup screens.  When I go to use the graphic setup in drak, it comes up as custom.  when i open custom it has intel 810.  if i click ok and use the defaults and then try to test it, it crashes the system.

Other live distros ie Mint, Kubuntu, Knoppix and the multibootiso all load perfectly without any problems.

CC: (none) => fuzzballz

@kent hill, what procedure did you follow to test the fix?

For the KDE Live DVD, the fix needs to be applied to

  /usr/share/X11/xdm/Xsetup_0

I put it just after the comment lines at the start of the file, and added the full path, i.e.

  /usr/bin/xrandr --auto

One quirk is that after selecting language/keyboard, a boot splash screen that doesn't occupy the full screen is displayed and animated. I suspect the journal line

  service_harddrake[xxx]: defaulting background resolution to 1024 x 768

has something to do with this.

The KDE desktop itself uses the full screen.

1. Booted into desktop. 
2. Connected to WiFi.
3. used Firefox
4. Set preferences
5. Used the Drak system
6. Ran hardware diagnostic
And etc

Logged out shut off computer and repeated.

(In reply to kent hill from comment #6)
> With the 5-rc live kde iso, the initial boot sequence comes up and flashes
> on and off, not really looking right, stutters.  Then a message that it is
> configuring hardware occurs and then it just goes blank with a dash in the
> upper left corner. 
> 
> The above fix does not work.

This was the bit I was asking about. As per comment 8, if you are using the KDE live disk, you need to apply the fix to a different file. Also, because it's a live DVD, it won't survive a reboot. My testing procedure is:

  - boot to run level 3 (add the number 3 to the kernel boot parameters
    accessed from the boot menu)

  - log in as root

  - edit the appropriate file

  - type 'systemctl start dm.service'

(In reply to kent hill from comment #6)
> What does work is using xdriver=vesa along with the blacklists.  The display
> goes through visual hash and then continues on to the setup screens.  When I
> go to use the graphic setup in drak, it comes up as custom.  when i open
> custom it has intel 810.  if i click ok and use the defaults and then try to
> test it, it crashes the system.

I don't think it's possible to test a X driver change without a reboot.

(In reply to Martin Whitaker from comment #10)
> My testing procedure is:
> 
>   - boot to run level 3 (add the number 3 to the kernel boot parameters
>     accessed from the boot menu)
> 
>   - log in as root
> 
>   - edit the appropriate file
> 
>   - type 'systemctl start dm.service'

I've tried that on my optimus laptop, and it works great. X started properly and I could configure the language and start KDE in live mode.

As you pointed it, there are some strange graphical glitches that do not appear normally, like the ksplash animation running in 1024x768 in the top-left corner.
KDE also started in a "New Activity" activity instead of the normal "Desktop" one, so I had no icons on the desktop. I had to switch activities manually.

I have verified the live rc-5 kde gives the same results on my Dell XPS 15 l502x optimus system with your procedure.  What does the xrandr --auto do?

*** Bug 15950 has been marked as a duplicate of this bug. ***

CC: (none) => paulo_ricardogo

It's probably too late, but...

Wouldn't it be better to have a fix for at least some hardware (with a few minor glitches in the KDE desktop) than no fix at all.

If the fix does not affect other hardware that is working fine currently, I'd say let's go for it :)

I can only speak for my limited selection of hardware, but I don't see any problems. To make it safe, we could do something like

  grep -q optimus /proc/cmdline && /usr/bin/xrandr --auto

or to make it the default than can be disabled if it causes problems

  grep -q nooptimus /proc/cmdline || /usr/bin/xrandr --auto

(needs testing, and I haven't got time to do it right now).

The safest the better, I'd like to test the first one in next round of ISOs.

(In reply to Samuel VERSCHELDE from comment #18)
> The safest the better, I'd like to test the first one in next round of ISOs.

Though the first one is only a fix for people who will read the release notes or errata and know that they need to add "optimus" to the boot options. If we can check that adding "/usr/bin/xrandr --auto" behaves properly on all hardware, that's the way to go.

My mixed results in comment 12 might be linked to booting first in runlevel 3, and then using startx. If the fix was already there in the ISO while booting normally, maybe things would behave better.

Ok, forget my comment #18 then, I had thought that was an automated detection of optimus. Couldn't we detect it and then call xrandr only when in this situation?

(In reply to Samuel VERSCHELDE from comment #18)
> The safest the better, I'd like to test the first one in next round of ISOs.

Though I agree that we could implement the first proposition, so that we can test the next ISOs using the "optimus" argument in the boot options, and also ask the rest from QA to test with "optimus" even when they don't have optimus hardware, to see if the argument is really needed or if we can implement the workaround directly for everyone.

(In reply to Samuel VERSCHELDE from comment #20)
> Ok, forget my comment #18 then, I had thought that was an automated
> detection of optimus. Couldn't we detect it and then call xrandr only when
> in this situation?

How about

  if [ -e /sys/module/nouveau -a -e /sys/kernel/debug/vgaswitcheroo ]
  then
    grep -q nooptimusfix /proc/cmdline || /usr/bin/xrandr --auto
  fi

Would the Live DVD ever choose the proprietary driver for Optimus graphics?

For the reference, Thomas has added the first proposal from comment 17 in the new set of Live ISOs, i.e. the optimus cmdline parameter should trigger the workaround.

I'll see if it behaves better than in comment 12 for me (I suspect my issues were mostly due to breaking the boot in two steps, especially the problem of KDE starting in an empty new activity instead of the "Desktop" one).

Unfortunately Thomas has implemented the first proposal in a different way, which doesn't work. Executing that fragment of code from the command line, I get

  -bash: strstr: command not found

crap, I only pasted half of my code to the iso builder...

That should teach me to not build stuff in the middle fo the night...

:/

I've tested the new round with the proper fix. The results are overall good:

- Both GNOME and KDE LiveDVDs can now start the install from boot properly using the "optimus" parameter

- KDE boots fine to a live system with "optimus", though the same issues as in comment 12 appear:
  o ksplash is shown twice (once with the good resolution, and once in 1024x768 on top of it) - minor cosmetic issue
  o KDE starts in an empty "New Activity" activity. The usual "Desktop" activity which contains icons (among which the draklive-install launcher) is also available, but one needs to switch activities manually - bigger issue, but still way better than no boot at all

- GNOME boots fine to a live system with "optimus"... when it wants. Sometimes it also fails with systemd's "Good luck" followed by GNOME's "Oh no". But that's probably unrelated to this fix, and more a symptom of bug 16032.


So basically the hack does its job :)
I can't tell if my issue with KDE's empty duplicate activity is due to this fix, or if it's an independent issue that I just never could experience since the live ISOs wouldn't boot on my optimus laptop.

*** Bug 14920 has been marked as a duplicate of this bug. ***

CC: (none) => yullaw

Same results as Rémi here. After installing from the live desktop, you can boot the installed system without adding "optimus" to the boot options, but still get the two KDE issues.

With a bit of further testing, I've found the double ksplash issue also occurs with a classic install if I select the default "configure both screens independently" option.

I normally select the "intel only" option.

Oh, that would be it: two instances of X must be started, the one we see is the second one. Isn't the first one still avaible on one of the ttys?

(In reply to Samuel VERSCHELDE from comment #30)
> Oh, that would be it: two instances of X must be started, the one we see is
> the second one. Isn't the first one still avaible on one of the ttys?

I tried against and did not see this, when booting the LiveDVD I see the duplicate ksplash and duplicate activity, but I only have one X on the ttys, and one Xorg.*.log.

I'll attach some info.

Created attachment 6727 [details]
journalctl -b from succesful boot with "optimus" flag with duplicate ksplash and activities

Created attachment 6728 [details]
X server log from succesful boot with "optimus" flag with duplicate ksplash and activities

I went on with the installation on real hardware, using the "Install" option in the LiveDVD KDE 64bit bootloader and the "optimus" flag.

I confirm that the symptoms described above are reproducible post-install, at each boot: ksplash is displayed in the top-left corner in 1024x768, and KDE spaws a duplicate "New activity" and loads it instead of "Desktop".

I checked /etc/X11/xorg.conf (attached in the next comment), and it confirms Martin's findings from comment 29. By default, XFdrake (in the live ISOs at least) configures two devices (intel and nouveau), and two monitors, one for each device.

After reconfiguring Xorg via XFdrake, and choosing to configure Intel only (which is the only viable solution currently for optimus), the symptoms disappear.


So to solve this bug, we really need to prevent XFdrake from auto configuring the two GPUs as two "monitors", and only configure the Intel GPU. This would probably also remove the need for the "optimus" hack to start X properly.

Created attachment 6729 [details]
Default (wrong) xorg.conf after a live install on optimus hardware

I also have the journalctl -b and Xorg.0.log from the installed system with the bad xorg.conf if need be (Xorg.0.log seems to be a bit different from the one of the live system, as the live system seems to have only one "monitor" configured at first).

Added to Errata, please improve if you can: 

You might want to add another workaround, if once tested proves working: Ctrl+Alt+Backspace, twice, to restart X.

Whiteboard: FOR_ERRATA => IN_ERRATA

Oops link missing: https://wiki.mageia.org/en/Mageia_5_Errata#Computers_with_hybrid_graphics

Same or different problem?

I tried to install Mageia 5 on my new laptop (UEFI) an ASUS N551J with two graphical cards (intel and nvidia). I have tried every option mentioned in the errata (hybrid graphics). I have tried the Live KDE 64 DVD and the classical 64 DVD. Nothing works. I am now 'doomed' to use Mint, that works at once, but I like Mageia much better (if it is installable).

LiveKDE64DVD:

Sometimes at boottime (LiveDVD) I get many nouveau errors and after a while I get a KDE desktop (intel detected?). I can than install it and after reboot I sometimes can configure a user and can log in into KDE. After a few seconds everything freezes. Poweroff and poweron and than it freezes already at boottime (blank screen or with nouveau errors with sometimes I see kernel panic).

Sometimes at boottime (LiveDVD) I get less nouveau errors and it freezes already (no KDE).

I tried boot options as suggested 'optimus' and/or 'rd.blacklist=nouveau rd.blacklist=nvidia xdriver=intel' â> No effect. Still nouveau errors at boottime and/or freezes.

ClassicalKDE64DVD:

Installation works until after reboot. Same problems as with the LiveDVD.
I tried the boot options, no effect. At the point of the installer to configure the graphics, it suggested 'Intel 810 and later' and not 'use intel only' as told in the errata. Even with Intel selected I get nouveau errors at boottime, with or without boot options.

It seems a problem like mentioned in the errata with the hybrid graphics (Intel+Nvidia), but the suggested options does not work.

Linux Mint 17.1:

No problem, works at once. No errors.

CC: (none) => info4pwo

Created attachment 6786 [details]
boot screen LiveKDE64DVD on ASUS N551J nouveau errors (part1)

boot screen LiveKDE64DVD on ASUS N551J nouveau errors (part1)

This is with and without the suggested boot options.

Created attachment 6787 [details]
boot screen LiveKDE64DVD on ASUS N551J nouveau errors (part2)

After this sometimes the laptop freezes or I can go on after a while.

Created attachment 6788 [details]
Xorg log of LiveKDE64DVD on ASUS N551J (if I am lucky to get so far)

(In reply to Peter Woldering from comment #39)
> Same or different problem?

The issue might be similar, but it has probably different causes too. You are clearly experiencing bug 15734, but there's more to it than just having the installer try to output to the nvidia GPU instead of the intel chipset.

I'll clone the bug so that we can keep track of your issue in its own bug report.

I own the Asus N550JK model and I have Optimus graphics as well and I have had the same problem mentioned.

I found a temporary fix to this issue by doing the following:

When you get to Emergency Mode like I did you type your root password and press Enter to login.

Then you type nano /boot/grub2/grub.cfg

Delete splash quiet from the kernel line and in the end add modprobe.blacklist=nouveau

Now save the changes and reboot.

CC: (none) => kristoffer.grundstrom1983

I found a solution that worked for me on the Asus N550JK which consist by the following procedure:

su -

Type:

nano /etc/modprobe.d/blacklist-mga.conf

Add the line

blacklist nouveau

Save the changes with Ctrl + x

Type or paste the follwing as root:

echo options nouveau modeset=0 | sudo tee -a /etc/modprobe.d/blacklist-mga.conf

Now type as root:

update-initramfs -u

I'm not saying that it'll work for you, but it did the trick for me.

Any ETA on this to get fixed before Mageia 6 comes out as a stable release?

I'll note that with the M6 sta1 Live GNOME DVD, I no longer need to use the "optimus" flag on the command line.

I could boot the Live without getting a blank screen either. I consider it fixed.

Please reopen if it still happens. If there are other optimus-related issues, prefer creating a new bug report for it.

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