| Summary: | [6sta1] Classic install has problems with starting sddm on nvidia system | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Len Lawrence <tarazed25> |
| Component: | Release (media or process) | Assignee: | Nicolas Lécureuil <mageia> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | jim, marja11, sysadmin-bugs |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | sddm | CVE: | |
| Status comment: | |||
| Attachments: |
Latest boot journal
journalctl -xe file from latest session X log file from some point in the trials. Latest X configuration Comparison of xorg.conf from Classic and from-Live installs Journal file for last clean reboot of 4.7.0 |
||
|
Description
Len Lawrence
2016-07-03 21:20:13 CEST
(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
Marja Van Waes
2016-07-04 07:31:28 CEST
CC:
(none) =>
marja11 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 ? 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 =>
RESOLVED |