Description of problem: x86_64 installation from 6sta1 classic iso dated 2016-06-29 Aorus X5 laptop with twin nvidia GTX965M graphics cards UEFI boot - multiple desktops Warning: this is a messy one. After successful installs of Plasma and Gnome on UEFI and CSM systems respectively, using nomodeset for the initial boots, I had a lot of trouble booting Cauldron on the Aorus X5. The installation went smoothly but rebooting, using nomodeset failed. The trouble seemed to be related to sddm in some way. I spent several hours trying various things, rebooting, trying to start sddm manually; even reinstalling sddm, at one point but nothing worked. The system hung forever after the attempt to start the dm. Eventually, with the vesa xdriver it arrived at a very sparse desktop with a very basic dm which I can only guess must be xdm (no options except username, then password). The desktop supplies aterm as a default. Ran the housekeeping tasks and installed the nvidia driver via drakconf. After reboot, it was still xdm but nvidia seemed to be running, at last. Configured sddm as the dm. systemctl status showed that sddm was alive but logging out went straight to xdm again. To get to sddm I had to # systemctl start sddm.service which started the sddm login. Rebooting from the user session brought up xdm again. One more try at starting sddm from user session then a successful logout to sddm. Rebooted from there, nomodeset maybe, sddm came up and I could finally choose the Mate desktop. Shall continue to note what happens at various stages but cannot provide many signposts for the whole saga - cannot remember all those steps. Four hours work and a journal with 16000 lines, which was captured. There are a couple of journals from the last reboot and some X info from about the 2.5 hour mark. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
(In reply to Len Lawrence from comment #0) So tired, I missed these bits: Version-Release number of selected component (if applicable): Mageia-6-sta1-x86_64-DVD > How reproducible: > Hard to say, but the failure of sddm was persistent and it seems to be hardware dependent in some way. Needs nvidia anyway. > > Steps to Reproduce: > 1. Install multiple desktops from 6sta1 classic 64bit iso. During install accept the installation of the proprietary driver. Try configuring vesa or nvidia at system configuration stage, on separate installs. > 2. Reboot nomodeset. If it fails on vesa, reinstall it in a console and try a reboot and let it run. An alternative is to install nvidia and try sddm. > 3. It is likely that both trials will fail but sometimes the vesa driver does get to a desktop via xdm. That is the time to reinstall nvidia and reboot - which goes to xdm but allows sddm to be launched from the user session. I cannot vouch for the accuracy of these sequences - it is all a bit hazy, but the fact remains; sddm has a problem.
Created attachment 8115 [details] Latest boot journal $ journalctl -ab
Created attachment 8116 [details] journalctl -xe file from latest session
Created attachment 8117 [details] X log file from some point in the trials.
Created attachment 8118 [details] Latest X configuration
CC: (none) => marja11Assignee: bugsquad => mageiaSource RPM: (none) => sddm
Several more attempts to get the graphics going on this machine. Nearly all attempts end up at either a blank screen with a rectangular mouse pointer or a screen with an area of coloured noise. tty logins are not available at that stage. Virtually every combination of possibilities has been tried including SLI on and off, installing X drivers in rescue mode and adding or not adding the kernel nomodeset parameter. Just to make sure that the laptop was still fully functional I installed Plasma from a Live session and that rebooted fine to a sddm login. The next stage is to repeat the tests and capture diagnostics before ttys become inaccessible. Sorry that there is so little information at this point. Classic installs have suceeded on two other nvidia machines so the problem might be specific to the Aorus X5.
Is there a difference between xorg.conf for the install from a Plasma LiveDVD, where sddm works, and the classical install where it mostly doesn't? (e.g. in the Section "Device") If so, can you try whether adjusting the xorg.conf in your classical install helps?
@marja I have not tried the Plasma Live again - will let you know> Meanwhile... Aorus X5 twin GTX965M laptop aka "markab" Short report: a multi-desktop install from the 6sta1 classic iso now boots to the desktop without a hitch when kernel handling of display modes is suppressed. Longer report: Comparing xorg.conf files The starting point was a desktop with nouveau at 2880x1620 installed from Live session a few days before. Earlier assumption that nvidia was running proved incorrect; nvidia-settings on the panel did not work. And, there was no xorg.conf (??). Installed kernel 4.7.0. drakx11 -> nvidia -> reboot 4.7.0+nomodeset Stopped in console mode. xorg.conf present - dumped to removable drive. lsmod showed nvidia only (no nvidia-modeset module loaded) sddm not running so restarted it and logged in successfully. Mate desktop functional but no weather information. Dumped xorg.conf again. New install from classic iso using existing partitions. Multiple desktops chosen - 8100+ packages OK Installed proprietary driver, configured media sources (wired connection) Distribution upgrade; 212 packages OK Rebooted 4.7.0+nomodeset straight to the desktop without any hitches. Weather information available. Dumped xorg.conf. Further tests to be made without nomodeset, also installation without wired connection, and installation of single Plasma or GNOME desktops. Would it be worthwhile to try earlier kernels? No installation logs or journal files captured so far but it might be a good idea to dump them in the next few experiments.
Created attachment 8133 [details] Comparison of xorg.conf from Classic and from-Live installs Not much difference - just the default colordepth line.
Another series of tests on markab involving the 4.6.3 kernel. From the standpoint of a successful 4.7.0 boot tried reverting to 4.6.3, without nomodeset. -> graphics driver failure -> drakx11 install nvidia. reboot 4.6.3 with nomodeset -> graphics problem -> install vesa (lsmod showed that nouveau was in control) rebooted 4.6.3 nomodeset -> low resolution desktop drakx11 -> nvidia -> reboot 4.6.3 nomodeset dkms started the module build -> "already built on this kernel" -> failed -> graphics failure Gave up - obviously back in the endless loop reboot 4.7.0 ... no Plymouth screen, no tty -> hung Cold reboot 4.7.0 -> failed Restart with nomodeset -> graphics failure -> drakx11 installed vesa reboot 4.7.0 nomodeset -> vesa desktop -> drakx11 install nvidia reboot 4.7.0 -> sddm -> nvidia desktop The moral of all this seems to be, for markab at least, avoid the 4.6.3 kernel. Time to close this bug.
Created attachment 8134 [details] Journal file for last clean reboot of 4.7.0 This applies to the twin nvidia laptop.
I had a similar experience today with a clean net-install of plasma. On booting I got the "can't start x-server message" Having read this bug report, rather than messing with xorg.conf or proprietary drivers, I installed xdm and gdm (which brought with it a minimal Gnome). xdm got me nowhere - it just kept repainting the login screen. With GDM I could log into the minimal Gnome installation, but if I chose plasma I got a popup that said something like "Could not start Dbus. Could you call qdbus?" and was then returned to the gdm login screen So I switched back to sddm. As soon as the dm service re-started the sddm login screen appeared and I could log in to plasma. On subsequent boots the system has correctly booted to the sddm login screen.
CC: (none) => jim
It is time to close this, particularly as mageia has moved on from 6sta1. Not sure what the status should be; SOLVED / CLOSED ?
If you can't reproduce this issue anymore, I guess you can close as RESOLVED FIXED.
Yes, I mean no. Thanks.
Status: NEW => RESOLVEDResolution: (none) => FIXED