Description of problem: A consensus was reached at today's QA meeting that the "problem starting your graphical display", "Good luck :)" boot error with M6 is a significant and serious general problem. This bug is to be a common reporting form for everyone to share their experiences. Please feel free to add your comments, successes and failures. Feel also free to change the Summary of this bug to better fit technically what's going on here. There are many successes balanced by many failures. IMO it's not an Nvidia vs Radeon vs VESA thing. It's more general then that. Once the error is encountered the system, for me anyway, becomes completely unusable adding to the frustration. Any help here would be appreciated. Thanks.
Created attachment 8355 [details] "good luck" M6 graphical display error screen capture
Created attachment 8356 [details] "good luck" error M6 journalctl capture
On real hardware, M6, Plasma, 64-bit Install from todays x86_64 boot.iso Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 5 64-bit, Nvidia driver Plasma DM After initial install I was successful to get to a working Plasma desktop. System rebooted successfully. Upon MCC -> Boot -> select autologin System boots to the now called "good luck" error. I will attach a screen shot and a copy of the journalctl read out.
In Vbox, M6, Plasma & Gnome, 64-bit Install from the latest CI's. All four platforms. Gnome, 32 & 64 bit Plasma, 32 & 64 bit. Never gets to a working desktop. Immediately goes to the "good luck" error.
In Vbox, M6, XFCE, 64-bit Install using latest CI. Fails immediately to the "good luck" error
(In reply to William Kenney from comment #0) Any help > here would be appreciated. Thanks. Are you using SDDM and is this related to: https://bugs.mageia.org/show_bug.cgi?id=18791#c18
(In reply to Barry Jackson from comment #6) > Are you using SDDM and is this related to: > https://bugs.mageia.org/show_bug.cgi?id=18791#c18 Removing /etc/sysconfig/desktop changes nothing. A reboot results in the same error message.
Severity: normal => criticalPriority: Normal => release_blocker
Real hardware x64 EFI, AMD/ATI/Radeon HD7310 graphics. All booting the most recent ISO from USB. Plasma Live 22 July: Shows this error. Run: fails to boot "Good luck". Install: fails to boot "Good luck". Gnome Live 22 July: does *not* show this error. Run: fails to boot for another reason (old bug ipv6 & BROADCAST matching) Install: fails to boot for another reason (old bug ipv6 & BROADCAST matching) Classic 13 Aug: does *not* show this error. No problems.
CC: (none) => lewyssmith
Further to Comment 8, re *Gnome Live* There were several related bugs for Mageia 5 testing, which indicate that the "ipv6 does not support BROADCAST matching" (a shorewell issue) is anodine, simply the last message output before ISO booting stops for a real reason. In those cases it was always an AMD/ATI/Radeon issue, Gnome only; KDE Live always booted OK. So it could now be for M6 the same root problem differently manifested between Plasma & Gnome Lives (on real hardware).
I think this is the same issue as: https://bugs.mageia.org/show_bug.cgi?id=18724 https://bugs.mageia.org/show_bug.cgi?id=18802 https://bugs.mageia.org/show_bug.cgi?id=18256 https://bugs.mageia.org/show_bug.cgi?id=18990
CC: (none) => geiger.david68210
(In reply to William Kenney from comment #7) > Removing /etc/sysconfig/desktop changes nothing. > A reboot results in the same error message. The point is *not* to remove /etc/sysconfig/desktop. The point is to make sure this file exists and contains DISPLAYMANAGER=SDDM.
FWIW, I see that sddm has segfaulted and prefdm.service has core-dumped. Has anyone else noticed and investigated this. Tested sta1 X86_64 under mga5 Virtualbox. Haven't been able to find the prefdm core. When I searched for sddm segfaults and prefdm core dumps I noticed OM-Cooker had this comment: Post by Colin Close New package 0.13.0-10 now available. Thanks to plfiorini who proivided a fix. Missing programs no longer cause a segfault and all existing executable paths are honoured. Relevant? I see sta1 is at 0.13.0-4.
CC: (none) => mrambo
Clean install to blank drive from boot.iso this morning /etc/sysconfig/desktop Does not exist.
Successful reboot with a manual log-in to a working desktop. Still no: /etc/sysconfig/desktop
MCC -> Boot -> set up for autologin /etc/sysconfig/desktop created as follows: DISPLAYMANAGER=sddm
Reboot system results in error as described in #3 Checking /etc/sysconfig/desktop remains the same.
Created attachment 8357 [details] CLI output of journalctl -b --no-pager | grep sddm Installed Plasma 5, display manager sddm, from classical iso of 13th Aug. (usb), Real Hardware, UEFI, [AMD/ATI] Thames [Radeon HD 7550M/7570M/7650M], driver Radeon. Reboot sucessful, system is clean. See https://bugs.mageia.org/show_bug.cgi?id=17233#c16 Switched after system upgrade to autologin. It leads to the "good luck" error, journal attached. # cat /etc/sysconfig/desktop DISPLAYMANAGER=sddm Note the error message: Unable to find autologin session entry ".desktop" The workaround described in https://bugs.mageia.org/show_bug.cgi?id=17233#c12 (Dave Hodgins) let you recover the desktop. Ulrich
CC: (none) => bequimao.de
(In reply to Ulrich Beckmann from comment #17) > The workaround described in > https://bugs.mageia.org/show_bug.cgi?id=17233#c12 (Dave Hodgins) let you > recover the desktop. How would this apply to an Nvidia based system? How would this apply to a Vbox based system?
I found a bug regarding autologin. See the autologin section in /etc/sddm.conf [Autologin] User=bequimao #Session=.desktop Session=01plasma.desktop The name 01plasma.desktop refers to the file in /usr/share/xsession Good luck Ulrich
OK many thanks to Ulrich Beckmann. On my real hardware system ( Comment 3 ) that was booting to the "good luck" error message. The end of the /etc/sddm.conf file looks like this with no autologin: ....... ...... #Session= # Name of the session to automatically log in when the system starts first time. Default value is empty. # #Relogin= # If true and User and Session are set automatic login will kick in again on session exit, otherwise it will work only the first time. # Default value is false. # #### Mageia-specific configuration [Users] MinimumUid=500 # hide system users # system users using real shells and hence cannot be hidden via HideShells HideUsers=mysql,apache,mldonkey HideShells=/sbin/nologin,/bin/false,/usr/sbin/nologin,/bin/true [Theme] # use our new custom theme without a userlist Current=mga-coffee # use our custom theme based on Maui but with default Mageia background # Current=mga-maui # maui is the default theme, when none is specified #Current=maui #Current=maldives #Current=elarun #Current=numix #Current=circles # allow display of user icons from a central system location # requires accountsservice to be installed which is not the default # FacesDir=/var/lib/AccountsService/icons/ MCC -> Boot -> enable autologin adds the following to the end of the sddm.conf file: ...... ...... # requires accountsservice to be installed which is not the default # FacesDir=/var/lib/AccountsService/icons/ [Autologin] Session=.desktop User=wilcal Which results in the "good luck" error message on boot and a bricked system. Under this condition I was able to open a root terminal and command: vi /etc/sddm.conf and remove: [Autologin] Session=.desktop User=wilcal and on reboot the system went back to the manual login mode and I was able to get back to a working desktop. One baby step for us anyway.
Hi William, I did not say remove the Autologin section. Just look at the correction I did in comment#19. We know now which program is the culprit, and we can remove the dimension "autologin" from the matrix. It is a different issue than the X11 issue. I do have a working autologin installation now! As to the X11 issue (with AMD/ATI card, driver radeon) the bug arose also in my Cauldron installation (sta 1) by midth of July and was resolved with the system upgrade of 23rd of July. I assume that it was the update of x11-driver-*. I really assume that, if new Plasma live isos were build, the "good luck" issue with sddm would be resolved there, too. Best regards Ulrich aka Bequimão
(In reply to William Kenney from comment #15) > MCC -> Boot -> set up for autologin > > /etc/sysconfig/desktop > > created as follows: > > DISPLAYMANAGER=sddm That should be: DISPLAYMANAGER=SDDM Not tested if it makes a difference but I suspect it may.
CC: (none) => zen25000
(In reply to Barry Jackson from comment #22) > That should be: > DISPLAYMANAGER=SDDM > > Not tested if it makes a difference but I suspect it may. Nope sorry, didn't make a difference. Still boots to the "Good Luck" error. But the good news is I'm get'n really good at un-bricking the test system. :-))
This is only about SDDM, correct? And not only about VBox, but also about installing to real hw, correct?
Source RPM: (none) => sddmCC: (none) => marja11Assignee: bugsquad => mageia
s/installing to/installs on/
Keywords: (none) => 6RC
(In reply to Marja van Waes from comment #24) > This is only about SDDM, correct? > > And not only about VBox, but also about installing to real hw, correct? This error is pretty universal and not specific to any specific platform.
(In reply to William Kenney from comment #26) > (In reply to Marja van Waes from comment #24) > > > This is only about SDDM, correct? > > > > And not only about VBox, but also about installing to real hw, correct? > > This error is pretty universal and not specific to any specific platform. Either it is one and the same bug everywhere, which would mean the Xorg.0.log and/or journalctl -ab and/or dmesg show the same problem. Or it is a collection of bugs, (different errors in the above mentioned files or outputs). In the first case, having one report is fine. In the second case, this bug should become a tracker. So far, no one in this bug report mentioned using anything else than SDDM as display manager. Besides, the attachments show sddm was used, too. So keeping the assigment to sddm for now. Does this bug also occur when you do *not* try to use autologin? (asking because of 'Unable to find autologin session entry ".desktop"' lines in your logs).
(In reply to Marja van Waes from comment #27) > Does this bug also occur when you do *not* try to use autologin? > (asking because of 'Unable to find autologin session entry ".desktop"' lines > in your logs). Hello Marja, I do not use autologin (I never activate it) and I have the "good luck" error in Vbox + SDDM environment.
CC: (none) => mageia
(In reply to Marja van Waes from comment #27) > Either it is one and the same bug everywhere, which would mean the > Xorg.0.log and/or journalctl -ab and/or dmesg show the same problem. IMO there are multiple reports for the same error source. I bet we've got at least a half dozen errors logged that we'll ultimately find have all the same source. There is nothing sacred for the title of this lets call it a "tracker" bug. As we better identify the source I would expect this bugs title to change to better define what's going on.
(In reply to Yann Ciret from comment #28) > Hello Marja, > > I do not use autologin (I never activate it) and I have the "good luck" > error in Vbox + SDDM environment. @ Yann Ciret, Which iso did you install? Did you update your installation to the present state? Ulrich
(In reply to Ulrich Beckmann from comment #30) > Which iso did you install? > Did you update your installation to the present state? > > Ulrich I did not install ISO. This is a cauldron machine since the beginning of Mageia. And yes, the system is up to date.
The most recent encounter I've had with an M6 install then fail to "good luck" used the x86_64 boot.iso from an up to date repo. That was on 18 Aug. So I think this is a generic to all install platforms bug. repo was mirrors.kernel.org I've also seen this error for a long time, months.
(In reply to William Kenney from comment #32) > The most recent encounter I've had with an M6 install then fail to "good > luck" used the x86_64 boot.iso from an up to date repo. That was on 18 Aug. > So I think this is a generic to all install platforms bug. Disagree *unless* it has regressed very recently. See my Comment 8 (the 13 Aug x64 Classic ISO did not show this bug for me on real h/w). (In reply to Marja van Waes from comment #27) > Either it is one and the same bug everywhere, which would mean the > Xorg.0.log and/or journalctl -ab and/or dmesg show the same problem. > Or it is a collection of bugs, (different errors in the above mentioned > files or outputs). and (In reply to William Kenney from comment #29) > IMO there are multiple reports for the same error source. I bet we've > got at least a half dozen errors logged that we'll ultimately find have > all the same source. See Comment 10.
(In reply to Lewis Smith from comment #33) > Disagree *unless* it has regressed very recently. See my Comment 8 (the 13 > Aug x64 Classic ISO did not show this bug for me on real h/w). As we progress forward on this I will execute a clean new install using the latest x86_64 boot.iso to a blank harddrive. The platform will be: Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 5 64-bit, Nvidia driver Plasma DM Nvidia driver invoked. Repo will be my local mirror of: mirrors.kernel.org rsync'd just minutes before the test. I'll try to do this at least several times per week or as often as necessary. Testing will be the same as I executed in Comment #3. After the "good luck" error manifests itself I will recover the system by removing the three autologin commands at the end of /etc/sddm.conf See Comment #20 This mornings install resulted in the same "good luck" error. Recovery was successful.
(In reply to Yann Ciret from comment #31) > (In reply to Ulrich Beckmann from comment #30) > > Which iso did you install? > > Did you update your installation to the present state? > > > > Ulrich > > I did not install ISO. This is a cauldron machine since the beginning of > Mageia. > > And yes, the system is up to date. Cool. But I don't think that such an installation is fit for qa testing. Just too many transitions. I tested now a new install of Mageia-6-RC-x86_64-DVD on VirtualBox. Host is openSUSE 42.1 Leap, Version 5.0.24, Plasma and sddm. Reboot failed with "good luck" error. Next steps: 1) switch off 3D acceleration 2) booted with kernel param "nomodeset" 3) system actualization to the present state. 4) reboot kernel 4.7.2-desktop-1.mga6, without "nomodeset" 5) switch on 3D acceleration Everything works fine. Please try another system actualization! Ulrich
(In reply to William Kenney from comment #34) > (In reply to Lewis Smith from comment #33) > > rsync'd just minutes before the test. I'll try to do this at least > several times per week or as often as necessary. Testing will be the > same as I executed in Comment #3. After the "good luck" error > manifests itself I will recover the system by removing the three > autologin commands at the end of /etc/sddm.conf See Comment #20 > > This mornings install resulted in the same "good luck" error. > Recovery was successful. I have filed a bug for the autologin issue https://bugs.mageia.org/show_bug.cgi?id=19234 There you see a fix to get autologin to work. Ulrich
(In reply to Ulrich Beckmann from comment #36) > I have filed a bug for the autologin issue > https://bugs.mageia.org/show_bug.cgi?id=19234 > There you see a fix to get autologin to work. Thanks Ulrich. One of these related bugs is gonna turn up the root cause of all of this.
hello i have install mga6 sta1 whit the driver nvidia 367.27;XX on a old pc (pentium 64 ) the graphic card is a gtx 750 ti after the first boot, the pc and the display is ok (kernel 4.6.3 and nvidia driver 367.27;XX ) .after the update (kernel 4.7.2.... and driver nvidia 367.35....) the display fails and i have the message "Good luck " thanks
CC: (none) => pleny29Target Milestone: --- => Mageia 6Hardware: All => x86_64
(In reply to pat leny from comment #38) > hello > i have install mga6 sta1 whit the driver nvidia 367.27;XX on a old pc > (pentium 64 ) the graphic card is a gtx 750 ti > after the first boot, the pc and the display is ok (kernel 4.6.3 and nvidia > driver 367.27;XX ) .after the update (kernel 4.7.2.... and driver nvidia > 367.35....) the display fails and i have the message "Good luck " > > thanks Which desktop environment and which display manager? Did you activate autologin? Ulrich
Problem is with xorg.conf not with autologin here is thread from our forum where i posted how to solve it,remove xorg.conf. We still use old depcrated xorg.conf it's still supported but not readed first and it should not be used anymore. https://forums.mageia.org/en/viewtopic.php?f=15&t=11257#p65528
CC: (none) => ozkyster
i use plasma 5.7 and the display manager is sddm. the bug is with autologin or not ( but the bug appear when installing the driver nvidia) i have a message than there is a error when the system is installing module i install the kernel 4.7.2 server and my pc is good now svp:please my English is very bad pleny
I can confirm Comment 40 with the proviso that all updates are also installed. I had a fresh installment of sta1 in virtualbox that exhibited the 'good luck' message. This was literally at first boot after installation. Removing xorg.conf did not help at that point. But after adding repositories and updating this VM now works as expected. This is only a single anecdote but it implies a combination of removing xorg.conf plus a fixed package in updates that is not on sta1. Auto login can now be enabled and disabled at will on this system without breaking anything. One additional data point; my hardware installation has never exhibited any of these problems at all - with or without auto login - with or without xorg.conf so perhaps the underlying video system also plays a role (perhaps xorg.conf is wrongly built for some?). (The hardware install is on an Acer M46128G with integrated Intel video.)
Assignee: mageia => kde
This morning I went at this with a different platform: Intel i5 8GB DRAM Gigabyte: GA-B85M-D3H ( non-Nvidia ) This is one of the most popular MoBo's out there. Install with x86_64 boot.iso, Plasma ( 08/22/16 ) Local repo mirrored to mirrors.kernel.org just minutes before the test. Start with a blank drive. Initial boot resulted in a brief display of the "good luck" error but then the system proceeded to the Plasma login screen and the login was successful. Subsequent reboots did not present the "good luck" error. The following code was put at the bottom of /etc/sddm.conf during the install. [Autologin] Session=.desktop User= Commenting out these three lines changed nothing for the reboot. Then. MCC -> Boot -> set to Auto login added: [Autologin] User=wilcal Session=.desktop to the end of /etc/sddm.conf The following reboot resulted in the "good luck" error screen every time. Using VI removing these three lines of code resulted in booting back to the normal login screen and successfully to the working Plasma desktop. Uncommenting the generic: [Autologin] Session=.desktop User= Rebooting the system resulted in getting back to the Plasma login screen and a successful login to a working Plasma desktop.
(In reply to Otto Leipälä from comment #40) > Problem is with xorg.conf not with autologin here is thread from our forum > where i posted how to solve it,remove xorg.conf. > > We still use old depcrated xorg.conf it's still supported but not readed > first and it should not be used anymore. > > https://forums.mageia.org/en/viewtopic.php?f=15&t=11257#p65528 In my case, this is the good solution. I drop the vboxvideo blacklist in modprobe.d directory and rename my xorg.conf to xorg.conf.yann. After system reboot, my SDDM is in 1600x900 and not in 1280x1024. All is fine now.
Experienced the 'good luck' message at first boot on a fresh boot-nonfree.iso installation. Removing xorg.conf was all that was required to remedy the problem. Adding or removing auto login did not appear to influence behavior in any way and auto login worked fine. I did notice on this install that there is no boot up splash screen - just three question marks (???). Hitting escape while the ??? was up returned to the boot up messages. Should that be a separate bug? I did not need to blacklist anything for this install.
(Forgot to mention that Comment 45 was Plasma on Vbox) Just installed boot-nonfree.iso Plasma on Intel hardware / Intel integrated video (Acer M4618G). Everything works out of the gate on this hardware. Auto login is fine. Works with or without the xorg.conf file. I can try with ATI and nvidia video hardware next week (time allowing).
(In reply to Mike Rambo from comment #45) > Experienced the 'good luck' message at first boot on a fresh > boot-nonfree.iso installation. Removing xorg.conf was all that was required > to remedy the problem. That is unacceptable in the final release. We should never expect a non-technical person to get into the inners of the OS and change something to make it work.
(In reply to William Kenney from comment #47) > (In reply to Mike Rambo from comment #45) > > > Experienced the 'good luck' message at first boot on a fresh > > boot-nonfree.iso installation. Removing xorg.conf was all that was required > > to remedy the problem. > > That is unacceptable in the final release. We should never expect a > non-technical person to get into the inners of the OS and change > something to make it work. Of course. But perhaps the devs now know what to look for. I'll test some more hardware next week (work at a school district - we have some of that) and see what happens with other hardware. It's looking rather like xorg.conf borks the installation on some hardware. A dev might figure out why.
Now I figured my autologin problem out. It is really a different issue. See https://bugs.mageia.org/show_bug.cgi?id=19234#c4. sddm works in my installation from classical iso on my AMD/ATI hardware as already said. I am also confident that live DVDs will work fine when newly rebuilt with the present state. xorg.conf made no difference in my tests. So it might be really obsolete. Greetings Ulrich
Working here: add blacklist vboxvideo in a file in /etc/modprobe.conf no need to modify xorg.conf reboot All is now working well
CC: (none) => ennael1
Please do also read what Chris wrote to QA ml https://ml.mageia.org/l/arc/qa-discuss/2016-08/msg00190.html Her summary: > My tests indicate (but I'm not sure): it's not a virtualbox bug, not a kernel > bug, but a packaging/ or mageia patch to vb that triggers the 'good luck' > error, but it's also possible that a lovely drak* module does something weird > ;-) CC'ing mageiatools list
CC: (none) => mageiatools
Anne asked me to add here my post to the QA mailing list: _________________ I've made some test to hunt the 'good luck' error/bug (no gui) after installing M6 (clean install with the most recent net iso) in VirtualBox. Host is M5, virtualbox 5.1.2. * The guest VM is a xfce only install, default packages, DM is lightdm, auto login works. x86_64 system. kernel desktop 4.7.2. * I've cloned the guest, start it, removed my workaround file /etc/modprobe.d/vboxvideo.conf (blacklist vboxvideo, suggested by tmb some weeks ago), also I've removed /etc/X11/xorg.conf * I've uninstalled vboxadditions-kernel-*. I've installed the kernel-desktop-devel*, which pulls in automatically all needed build essentials. * Downloaded the most recent and original VBoxGuestAdditions_5.1.4.iso, attached it as an optical disk, mounted it, and ran the installer, it builds fine, no errors. * After rebooting: all is well, no more nomodeset or blacklisting needed, lsmod shows that the kernel module vboxvideo is loaded. I had to adjust the screen size anew (view, Virtual screen size), works. Shared clipboad, shared folders work, just to make sure, but that was not broken anyway. The login screen (lightdm) is now not restricted to small because module vboxvideo is loaded at this stage. * Now comes the fun part: testing drakx11/mcc. As soon as I tried to configure the graphical card via mcc, a new xorg.conf is written. After reboot: 'good luck error'. Remove the xorg.conf: all is well again. My tests indicate (but I'm not sure): it's not a virtualbox bug, not a kernel bug, but a packaging/ or mageia patch to vb that triggers the 'good luck' error, but it's also possible that a lovely drak* module does something weird. ___________
CC: (none) => shybluenight
Just to add another voice, I'm seeing a variation of this on real hardware, SDDM, Plasma, current (as of about a week ago) cauldron. I get the Good Luck message, but several seconds later SDDM starts correctly. This happens repeatedly, and I've never seen a hang. The conjecture that this has to do with xorg.conf and configuration is a good one since I see this on *none* of my existing cauldron systems which are kept current through urpmi --auto-update. Whatever triggers this happens during *current* cauldron fresh installs. I think the first thing to do is find this message in the code and read further to see what's expected to happen after it is displayed. From the behavior I see, I'll bet there is some sort of retry that works sometimes and sometimes bricks the system. It would almost be better if this is code we added, because adding debugging code would be easier. Also, I think there are two bugs here. The first is whatever gets us to the message in the first place. The second is how the retry screws up after it is displayed.
CC: (none) => ftg
First and foremost many thanks to all for participating in the pursuit of this critical bug. (In reply to Frank Griffin from comment #53) > Just to add another voice, I'm seeing a variation of this on real hardware, > SDDM, Plasma, current (as of about a week ago) cauldron. I get the Good > Luck message, but several seconds later SDDM starts correctly. This happens > repeatedly, and I've never seen a hang. Yup, I've seen that here too on real hardware.
(In reply to Frank Griffin from comment #53) > Just to add another voice, I'm seeing a variation of this on real hardware, > SDDM, Plasma, current (as of about a week ago) cauldron. I get the Good > Luck message, but several seconds later SDDM starts correctly. This happens > repeatedly, and I've never seen a hang. That is https://bugs.mageia.org/show_bug.cgi?id=18791
(In reply to Frank Griffin from comment #53) To find the message text was my first idea as well. I've found it, it had to be something specific for Mageia, drakx11 is mentioned, and after systemd was implemented. The text of the 'good luck' message comes from: /usr/sbin/display-manager-failure-message Being called by systemd: /lib/systemd/system/display-manager-failure.service which is executed when /lib/systemd/system/display-manager.service fails, that is: '/etc/X11/prefdm -nodaemon'
This looks to me like it is an X failure although there might be different core reasons depending upon configuration. I have been testing five different configurations with one in vbox and the other four on hardware. The hardware has been the same Acer M4618G mentioned in Comment 46. I have tested using the integrated Intel video, with a Radeon card, and with an nVidia card. The latter was tested with both proprietary and nouveau drivers. In all cases, when the good luck message is seen X has failed to start and prefdm has segfaulted and core dumped in the logs. sddm has has also "Process crashed" for the vbox case or segfaulted in the radeon and nouveau cases. To "fix" vbox you can either remove xorg.conf or blacklist vboxvideo as has been mentioned. Interestingly, if you remove xorg.conf it appears the X uses vboxvideo anyway but must configure something differently than the default because it works ok. I couldn't figure out what driver was used when you blacklist vboxvideo. Looked to me like it identifies as SGI according to glxinfo in the blacklist case. For radeon and nouveau Xorg logs show a permission problem with /dev/dri/card0 as described in bug 19199. On Intel and nVidia /dev/dri/card0 shows crw-rw----+ permissions. On radeon and nouveau the + indicating extended attributes is missing. When I manually added additional permissions (in this case just added o+rw as a shotgun approach) startx then worked ok. Adding sddm or SDDM to video in /etc/group does not help. There was a gentoo forum message about that but it doesn't work here. This all makes me think that X configuration might be at the root of the whole thing. Perhaps folks that understand X configuration a bit better might figure out why? I have separate hard drives here for all these configurations so it shouldn't be much of a problem to get logs or other files if they will help. Hope this helps in some way.
On Vbox, M6, Plasma, 64-bit Install from x86_64 boot.iso dated 08/22/16 Install was clean, first boot went to the "good luck" error message. I couldn't figure out how to fix it and get to a working desktop.
(In reply to Mike Rambo from comment #57) > Hope this helps in some way. Everything helps in this effort. Your work is highly appreciated.
Found something on the nouveau installation when I started looking into the prefdm segfault. The restart timeout is set to 0 in /usr/lib/systemd/system/prefdm.service Changing RestartSec=0 to RestartSec=500ms appears to resolve the problem. I rebooted about 10 times with the 500ms setting without a failure. I also tried RestartSec=250ms and restarted three time without a failure there. I noticed the default is 100ms in /etc/systemd/system.conf so last of all I tried RestartSec=100ms and that too seems to fix the problem - at least on this hardware. I will look at this on the radeon when I can get the box reconfigured.
CC: lewyssmith => (none)
Looks like I jumped to conclusions too soon. The previous nouveau installation started working with the steps in Comment 60 yesterday. Decided to try and replicate the results with another boot-nonfree.iso install this morning. The new install is not impressed with those steps at all. Back to the 'good luck' message - and I guess back to the drawing board. I must have done something else that I don't recall to influence the situation yesterday because I used that machine and rebooted a couple dozen times yesterday afternoon.
(In reply to Chris B from comment #56) > The text of the 'good luck' message comes from: > > /usr/sbin/display-manager-failure-message On my real hardware system that file is found at: /usr/bin/display-manager-failure-message
Fresh virtualbox mga6 Plasma installation via boot-nonfree.iso this morning still results in good luck message. With the installation generated xorg.conf if you kill the boot splash screen you will see several attempts to start the display manager and finally a failure message. The logs will contain a systemd reported prefdm segfault - usually five of them IME. Removing xorg.conf eliminates the multiple attempts to start the display manager, it does start, and it works. There are no segfaults in the logs. lsmod indicates X has used the same vboxvideo driver that was put in xorg.conf by the installer except that something is different in the configuration specifics because it now works. Oddly enough, trying to get X to generate a file (with Xorg -configure) fails and a working configuration is not produced. Passing the kernel nomodeset at boot also eliminates the multiple attempts to start the display manger which does start and works. There are no segfaults in the logs. lsmod no longer shows vboxvideo but only vboxsf and vboxguest. I also want to note that when I have referred to the boot splash screen I am referring to where the boot splash screen should be. In really, I am not seeing the boot splash but only a black screen with three question marks (? ? ?). I think I've seen this particular quirk only with virtualbox and it does not matter whether good luck eventually appears - it is there regardless.
Fresh hardware mga6 installation via boot-nonfree on radeon hardware. This also still results in the good luck message but the causes are different. If you kill the boot splash there are again multiple attempts to start the display manager and then also the failure message. But there are no segfaults in dmesg or system logs. Running systemctl status prefdm (which a boot message suggests) reveals the following: [root@mga6test2 ~]# systemctl status prefdm â prefdm.service - Display Manager Loaded: loaded (/usr/lib/systemd/system/prefdm.service; static; vendor preset: enabled) Active: failed (Result: start-limit-hit) since Fri 2016-09-02 12:45:41 EDT; 34s ago Process: 1552 ExecStart=/etc/X11/prefdm -nodaemon (code=dumped, signal=SEGV) Main PID: 1552 (code=dumped, signal=SEGV) Sep 02 12:45:41 mga6test2 systemd[1]: prefdm.service: Failed with result 'core-dump'. Sep 02 12:45:41 mga6test2 systemd[1]: prefdm.service: Service has no hold-off time, scheduling restart. Sep 02 12:45:41 mga6test2 systemd[1]: Stopped Display Manager. Sep 02 12:45:41 mga6test2 systemd[1]: prefdm.service: Start request repeated too quickly. Sep 02 12:45:41 mga6test2 systemd[1]: Failed to start Display Manager. Sep 02 12:45:41 mga6test2 systemd[1]: prefdm.service: Unit entered failed state. Sep 02 12:45:41 mga6test2 systemd[1]: prefdm.service: Triggering OnFailure= dependencies. Sep 02 12:45:41 mga6test2 systemd[1]: prefdm.service: Failed with result 'start-limit-hit'. If I log in via console as myself startx works and the desktop displays as it should. Because of the syslog message saying that prefdm was restarting too fast I tried changing the RestartSec value in /usr/lib/systemd/system/prefdm.service. Changing RestartSec=0 to a value of 1 or higher results in a functional graphical interface. Setting that value to 5 or higher prevents the multiple attempts to start the display-manager in the boot messages behind the splash screen. I also tried adding prefdm.service to the After line in display-manager-failure.service but it did not help in preventing the good luck message. The system still appears to think prefdm failed even though the graphical interface is actually in the process of starting. Nothing I have tried thus far has negated the good luck message which comes via display-manager-failure.service in systemd.
does /etc/sysconfig/desktop exist ? if yes does it contain : DISPLAYMANAGER=sddm ?
No it didn't. It does now and it fixed the radeon install (even with all the other stuff set back to original settings). It did not fix the vbox install. That one looks to me like an X config problem. Still had to take one of the several steps to work around it. I usually remove /etc/xorg.conf. I'll do another radeon install next week and retry my tests on nVidia and Intel hardware too.
Well, I just got the "good luck" message after setting up Cauldron in a VM on Fedora 24 KVM host. I'm using the QXL video driver. I have no /etc/sysconfig/desktop. prefdm failed as noted in comment 64. I had an /etc/X11/xorg.conf file, and even after renaming it so xorg wouldn't find it, it still failed. Adjusting the RestartSec time, as mentioned in comment 60, to 500ms, did not work either. Adding "nomodeset" at grub to the kernel arguments worked. Alternatively, switching to VMVGA graphics for my virtual machine fixes it without additional work. People experiencing this issue on VirtualBox should also check to see if switching to VMware VGA fixes the issue for them without requiring "nomodeset". That said, it seems that for QXL, we need "nomodeset" for things to work. :(
CC: (none) => ngompa13
Oh, I forgot to mention I am running kernel 4.7.2-server in my VM (it was a netinstall).
I just verified with a Fedora 24 netinstall (which also installs kernel 4.7.2) on KVM that I can use QXL without issues. What puzzles me is that I can't quite figure out what's different between Cauldron and Fedora 24 that causes this breakage...
Real Hardware install. Today I executed a clean new install using the latest x86_64 boot.iso to a blank hard drive. The platform was: Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 5 64-bit, Nvidia driver Plasma DM Nvidia driver invoked. Repo will be my local mirror of: mirrors.kernel.org Install was clean and successful, boot to a working Plasma desktop. Set: MCC -> Boot -> select autologin Reboot system Successful boot, and auto login, to a working Plasma desktop. No "good luck" error message.
Fresh installs using boot-nonfree on vNidia hardware. #1) used nouveau drivers. Saw 'good luck' at first boot and there were five lines about prefdm segfaulting in the logs. /etc/sysconfig/desktop did not exist. Added that file and configured with DISPLAYMANAGER=sddm per Comment 65 and there was no longer any 'good luck' or prefdm segfaults. #2) used proprietary drivers. Saw three question marks (???) instead of the boot splash but there was NOT any good luck message and the graphical display started without problem - and this without any /etc/sysconfig/desktop file. No prefdm segfaults either. But there was no text displayed when I typed my username to log in graphically. The password field displayed asterisks as usual. For whatever reason NONE of the consoles on CTRL ALT F2-F7 are there - only the cursor underline. The existence (or not) of /etc/sysconfig/desktop appears to make no difference with this configuration. I have these two hard drives if something further will help diagnose.
I have both the issues mentioned. I thought that they were distinct. "Good Luck" message: On a fresh install, I am invited to use the nvidia driver. On first reboot, I get the "good luck" message. I then install all updates, and run XFdrake in a console. That cures the problem on the next reboot. On a fresh home directory, .Xauthority is usually owned by root. That was sending me into an endless loop with lightdm. The 3 question marks. I read that a fresh initrd should cure that. It did -for one day. I posted to the Forum, and am now waiting for the RC before commenting further.
CC: (none) => laidlaws
As a continuation of comment 67, I tried with a freshly broken setup with KVM using QXL, and creating /etc/sysconfig/desktop and adding "DISPLAYMANAGER=sddm" to that file makes everything work properly with QXL.
CC: (none) => hhielscher
boot.iso x86_64 Vbox client Install went fine and successful reboot to working desktop using the nomodeset in the kernel options. Removed 187 orphans and set it to auto login and that booted to a black screen. Awaiting the new isos.
Just to test the remaining hardware variations on hand... two more Plasma tests using boot-nonfree on Intel and Radeon hardware. Intel) Saw 'good luck' at first boot and there were three lines about prefdm segfaulting in the logs. After the good luck message Intel has always went ahead and started the graphical display anyway after a few seconds - same in this case. /etc/sysconfig/desktop did not exist. Added that file and configured with DISPLAYMANAGER=sddm per Comment 65 and there was no longer any 'good luck', prefdm segfaults, or any delay starting up. Radeon) Identical behavior to nVidia using nouveau drivers. Saw 'good luck' at first boot and there were five lines about prefdm segfaulting in the logs. /etc/sysconfig/desktop did not exist. Added that file and configured with DISPLAYMANAGER=sddm per Comment 65 and there was no longer any 'good luck' or prefdm segfaults. To summarize these four hardware configurations, and as Nicolas implied in Comment 65, for all but the nVidia proprietary configuration /etc/sysconfig/desktop seems to be in the middle of this - prefdm segfaults without it. No idea why the nVidia proprietary drivers avoids the fault but it does here. Following the segfault trail through /etc/X11/prefdm looks to me like it leads right back to the sddm executable via /etc/X11/lookupdm and /usr/share/X11/dm.d/11sddm.conf. Looks again like it may be related to Bug 18791 as mentioned long ago in this bug. Or maybe someone who knows more will see something else. I know I forgot to test autologin on one of these but it has always worked for me once the graphical starts successfully.
*** Bug 19354 has been marked as a duplicate of this bug. ***
CC: (none) => jan
I just noticed the reference to sddm. I switched my DM to lightdm, and on a first reboot, nothing has changed. I haven't tried the proprietary nVidia driver. It is always too much trouble to get nouveau out of the picture. My desktop is currently Xfce. MATE is similar. My card is a GeForce 750. The question marks appear only after selecting from Grub2's menu, and the appearance returns to normal when the login screen comes up. It is not for me to say, but sddm does not seem to be the cause in my case.
A heap of updates just came in as I was writing Comment 77, so I installed them and rebooted. The daily retry of KDE included a fresh version of sddm. Plymouth-related updates failed with the following message: "file /usr/share/plymouth/themes/Mageia-Default/background.png from install of plymouth-0.9.2-6.mga6.x86_64 conflicts with file from package mageia-theme-Default-1.5.0.51-1.mga6.noarch." In the new scenario, using lightdm, there is no change whatever for this bug.
(In reply to Doug Laidlaw from comment #78) > A heap of updates just came in as I was writing Comment 77, so I installed > them and rebooted. The daily retry of KDE included a fresh version of sddm. > Plymouth-related updates failed with the following message: > > "file /usr/share/plymouth/themes/Mageia-Default/background.png from install > of plymouth-0.9.2-6.mga6.x86_64 conflicts with file from package > mageia-theme-Default-1.5.0.51-1.mga6.noarch." > > In the new scenario, using lightdm, there is no change whatever for this > bug. Yes that's my mistake (plymouth) - will fix conflicts :\
Hi There, I installed mga6 (sta1) some weeks ago (network install) from virtualbox. I had several on and off good luck bugs (glb) days after days depending on updates... . This morning I updated mga6, glb was still there. I followed advices found in this thread: blakclist vboxvideo + removing /etc/X11/xorg.conf solved glb problems.
CC: (none) => jcldc13
I am running 6 on its own partition and virtualbox is not installed.
I am no longer experiencing the "good luck" bug. See Comment 72. I renamed xorg.conf and rebooted. No fresh xorg.conf was created, but the Mageia nVidia driver was used. The "???" seemed to disappear more quickly, but it started, all the same.
Just as an afterthought, with xorg.conf put back but not rebooted, Second Life gave me a "Window Creation error." Rebooting cured that. From previous research, it has something to do with glx.
I just installed Cauldron as my default system from the sta1 release. Got the "good luck error" and can't do anything. Renamed xorg.conf: no help /etc/sysconfig.desktop already existed: DISPLAYMANAGER=lightdm About to try a current boot.iso as this seems to be the most common cure. Tried logging in as user and running startx: Fatal server error: no screens found
Installed Mga6 from latest boot.iso for x86_64. Got "good luck" error on first reboot. Opened XFdrake, configured nVidia card (it had been "automatic") Got a desktop on next reboot.
Hi all, Fresh install with net-install iso in a VB under Win10 this morning... No graphical pbs on the first boot, then trying to install VirtualBox-addons 5.1.6 (latest release...) After reboot, no graphical display, just text with "good luck" at the end... Trying to remove xorg.conf, same pb. Trying tu put "nomodeset" on grub command line, black screen after boot. Kernel 4.7.4-desktop-2.mga6
CC: (none) => sylvain.hemonet
(In reply to Sylvain HEMONET from comment #86) > Hi all, > Fresh install with net-install iso in a VB under Win10 this morning... > No graphical pbs on the first boot, then trying to install VirtualBox-addons > 5.1.6 (latest release...) > After reboot, no graphical display, just text with "good luck" at the end... > Trying to remove xorg.conf, same pb. > Trying tu put "nomodeset" on grub command line, black screen after boot. > Kernel 4.7.4-desktop-2.mga6 Did you run "update-grub" after the change to the kernel command line? Have you tried running XFdrake, as I did (Comment 85?) That is what the "Good Luck" message asks you to do. From a comment higher up, Xorg.conf is being replaced by entries in /etc/X11/xorg.conf.d.
(In reply to Doug Laidlaw from comment #87) > (In reply to Sylvain HEMONET from comment #86) > > Hi all, > > Fresh install with net-install iso in a VB under Win10 this morning... > > No graphical pbs on the first boot, then trying to install VirtualBox-addons > > 5.1.6 (latest release...) > > After reboot, no graphical display, just text with "good luck" at the end... > > Trying to remove xorg.conf, same pb. > > Trying tu put "nomodeset" on grub command line, black screen after boot. > > Kernel 4.7.4-desktop-2.mga6 > > Did you run "update-grub" after the change to the kernel command line? > Have you tried running XFdrake, as I did (Comment 85?) That is what the > "Good Luck" message asks you to do. From a comment higher up, Xorg.conf is > being replaced by entries in /etc/X11/xorg.conf.d. No, I don't run grub-update, I just put "e" to edit command line and put "nomodeset" at the end of linuz command, then crtl-x to boot... It's no the procedure ? I tried to change graphical driver in XFDrake on VESA, no changes... I can't choose Nvidia driver 'cause I'm working on a VirtualBox...
(In reply to Sylvain HEMONET from comment #88) > (In reply to Doug Laidlaw from comment #87) > > (In reply to Sylvain HEMONET from comment #86) > > > Hi all, > > > Fresh install with net-install iso in a VB under Win10 this morning... > > > No graphical pbs on the first boot, then trying to install VirtualBox-addons > > > 5.1.6 (latest release...) > > > After reboot, no graphical display, just text with "good luck" at the end... > > > Trying to remove xorg.conf, same pb. > > > Trying tu put "nomodeset" on grub command line, black screen after boot. > > > Kernel 4.7.4-desktop-2.mga6 > > > > Did you run "update-grub" after the change to the kernel command line? > > Have you tried running XFdrake, as I did (Comment 85?) That is what the > > "Good Luck" message asks you to do. From a comment higher up, Xorg.conf is > > being replaced by entries in /etc/X11/xorg.conf.d. > > No, I don't run grub-update, I just put "e" to edit command line and put > "nomodeset" at the end of linuz command, then crtl-x to boot... > It's no the procedure ? Yes, that is O.K. if you are editing the entry while in GRUB. You need to run update-grub only for permanent changes. > I tried to change graphical driver in XFDrake on VESA, no changes... > I can't choose Nvidia driver 'cause I'm working on a VirtualBox... Comment 80 seems to be the closest to your situation.
I just upgrade with new kernel 4-7-5-Desktop and it seems working better ! I think VirtualBox-addons are installed, I will check that...
What a pity... The first boot is ok, but rebooting makes the trouble alyways...
Same here. It is in the above comments somewhere. But Anne got Comment 80 to work. The distro doesn't even obey La Presidente!
Yes, I just try with a sta1 and upgrading with latest release... It's seems to working fine !
I have forgotten to mention that I don't have VirtualBox-addons installed...
Hello, this morning, some update of Virtualbox package 5.1.6 (corresponding to the last rewiew of VB...), and no graphical interface on reboot, one more time !
CC: shybluenight => (none)
In two installations of Mageia 6 STA1 I checked today, October 1st, all the updates were installed without problems. There was no conflict of packages, and the plasma environment is working correctly (See bug 19478)
CC: (none) => terraagua
Created attachment 8567 [details] Error picture 1 Error message at statarting mageia 6 sta1 i VirtualBox
Created attachment 8568 [details] picture 2 error message at starting mageia 6 sta1 Picture 2 on error starting mageia 6 sta1 in VirtualBox
Created attachment 8569 [details] Picture 3 error starting mageia 6 sta 1 Picture 3 error starting mageia 6 sta1 in VirtualBox
I am no longer running sta 1. I do a netinstall from the latest boot.iso. I do get the "good luck" error at the beginning. Then I do a full update from the command line to have the latest kernel. If that doesn't give me a screen on the next boot, I run Xfdrake. That takes away the "good luck" error, but not the screen with the 3 "?". I notice a mention of a missing library in Plymouth, but the devs will know about that.
Today I succeeded to instaal mageia 6 sta1 with kernel 4.8.2 i VirtualBox
You are lucky. I decided to move everything to a new hard drive. I installed from sta1. My .Xauthority was not created at all. I was sent to the "good luck" prompt, ran XFdrake and got nowhere. My Internet connection often disappears at the stage of installing updates. A "cold start" of the router usually cures it.By the time I had tried that several times, I already had a dkms-nvidia in /var, blocking a new one. I did a fresh netinstall from a recent boot.iso. Got the "good luck" prompt. Quite normal so far. The existing dkms-nvidia prevented a new one being created. I uninstalled the RPM, which removed the folder, then ran XFdrake again. Success! The installer went ahead and installed grub2, and here I am. Whew!
just reinstalled my laptop and i see this pb. The major issue with this is that pulseaudio does not work either ( related to the Ooops ).
btw i just removed locally prefdm and used sddm service instead and ONLY this fixed all my issues. I think we MUST get rid of prefdm for mageia6
I see that prefdm is causing issues in just about every distro. But the installer gave me lightdm.
Test platform: Intel Core i5-4460 Haswell Quad-Core 3.2GHz LGA 1150 Gigabyte GA-B85M-D3H LGA 1150 Intel B85 chipset MoBo Integrated Graphics Processor - Intel HD Graphics, Kernel modules: i915 Audio chipset - Realtek ALC892, 7.1 channels, Kernel modules: snd_hda_intel Corsair Vengeance 8GB ( 2 x 4GB ) 240-pin DDR3 SDRAM 1600 A net install ( boot.iso ) on this system was successful today except during the boot to the Plasma desktop the "Good luck :)" screen is briefly displayed but then the system progresses to the Plasma desktop. That same "Good luck :)" message is briefly displayed when shutting down or Reboot. If you issue a Reboot the "Good luck :)" screen is displayed during the going down process and redisplayed again during the boot up process.
I use VirtualBox Version 5.1.2_OSE r108956 for Mageia 6 sta1. Yesterday I updated mageia 6 sta1 and when rebooted I run in the Good Luck message again. I tried to change some parameters but no luck. I read back last backup and succeded. Now I use: Linux localhost.localdomain 4.8.2-desktop-2.mga6 #1 SMP Tue Oct 18 21:41:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Same story like Jan's, only difference: i use a working kernel 4.6.3 Everything else throws up the Goog luck-message.
CC: (none) => isis2000
can you test to disable prefdm.service and enable sddm.service of gdm.service ( it depends if you use Plasma or gnome )
Created attachment 8616 [details] boot screen after enabling sddm.service Did so by systemctl disable/enable prefdm and sddm services as root. Following reboot system holds in boot, see attached picture.
Following reboot in kernel 4.6.3 without problems. Checked as root for the named services. prefdm is inactive and sddm is active/running
Created attachment 8617 [details] services as seen in mcc In one view the services as in MCC. Tried to check out boot-option for prefdm, but after giving OK, and returning to the same services-screen, it is turned back enabled again. No matter what, prefdm has stopped and sddm is clearly running (in kernel 4.6.3 that is)
Updates today have caused all of my M6 Vbox client installs to fail to the "Good luck :)" screen. That includes both M5 & M6 Hosts. Last update of these Vbox Clients was last Sunday. Updates to my M6 Plasma on real hardware have been successful after a reboot. In the next 24-hours I'll attempt a complete re-install of these clients.
(In reply to William Kenney from comment #113) > In the next 24-hours I'll attempt a complete re-install of these clients. Vbox, M5 x86_64 KDE Host, M6 x86_64 Plasma client An attempt to re-install M6 Plasma x86_64 from net install ( boot.iso ) resulted in the "Good luck :)" message at boot. This is using an up-to-date repo as of 0:54 UTC, Thur, Nov 3. I would say that M6 install in any configuration is bricked right now.
Created attachment 8619 [details] boot holds Managed to get fully working desktop with kernel 4.8.6 This after returning into recovery-mode for kernel 4.8.6 Following systemctl default as root Linux localhost 4.8.6-desktop-1.mga6 Then again tried to start the regular way to 4.8.6 This time again no desktop, see picture. Executed Ctrl-Alt-Del, and went into recovery=mode once more for kernel 4.8.6 And issued systemctl default once more which again gave me the kde/plasma-desktop. PS: I did no further updates today so far, though i know there are, but probably with their own issues, that aside.
Today updated Cauldron to the latest level. System starts just fine into Plasma, but only through recovery-mode and "systemctl default" as mentioned earlier.
About my experience too for a while. No longer goes into "Good Luck" but "systemctl default" was taking me full circle.
After update I reboot and when booting I change to kernel: 4.8.2_desktop-2.mha6 created Oct 18 at 21:41 The boot succeded with plasma.
For many weeks now( see #80), I switched from mga5 to mga6 on two platforms : - Virtualbox (installed from boot.iso sta1) - Real hardware: Laptop with intel HD5000 GPU (mga5 to mg6 migration from CLI) Everyday I run update (currently I am running kernel is 4.8.6-desktop-1.mga6) and I don't have any "good luck" bug anymore since a while. Noticed that on Virtualbox I don't even blacklist vboxvideo module anymore.
btw, from systemd 230 NEWS file : * The prefdm.service file has been removed. Distributions should maintain this unit downstream if they intend to keep it around. However, we recommend writing normal unit files for display managers instead.
I have a 2 new real hardware testing platforms : A) laptop with nvidia card --------------------------- This laptop was running mga5 and I updated to mg6 from the CLI. Nvidia drivers have been updated, and I am running mga6 with the latest updates (November 8th) and everything works fine, I have kde5/plasma5 running perfect with nvidia proprietary drivers. B) Desktop machine with nvidia card ------------------------------------ I installed mga6 from sta1 live DVD. At first boot, everything was running fine (kde5/plasma5). Then I updated (urpmi --auto-update), which brought a tons of packages and latest kernel 4.8.6. Then when I have rebooted, "good luck bug" appeared !!!!!! The good news is that I found why conf A) works although conf B does not :) From (conf A), which is an upgrade from mga5 to mga6, GRUB1 is used to boot, whereas from a fresh install (conf B, sta1 live DVD) GRUB2 is used to boot. And the difference between both GRUB is that option "nokmsboot" is used on GRUB1 only. If I add "nokmsboot" on GRUB2 (conf B) then desktop works like a charm without "good luck bug" and with nvidia proprietary drivers activated. This option "mkmsboot" prevents the kernel to detect video card which consequently load video drivers. explanation: If you don't put "nokmsboot" at kernel command line boot, and if you have, for example an nvidia card, then kernel at boot will load "nouveau" driver no matter if you have blackist it. As nouveau is loaded, then nvidia will not load if you have an xorg.conf file with nvidia driver specify on it and you might see a good luck bug message. One possibly explanation of all the good luck bug may comes from this feature (nokmsboot) activated or not, I guess..
> If I add "nokmsboot" on GRUB2 (conf B) then desktop works like a charm > without "good luck bug" and with nvidia proprietary drivers activated. I have made no changes to my system for a while. I have a GeForce video card. Without "nokmsboot" I get a message that the proprietary driver can't be loaded. Usually, I don't get nouveau either, just a text prompt. It was like that before the "goodluck" bug showed up. Once everything is up and running, the "good luck" bug doesn't come back It seemed relevant that Nicolas found prefdm causing problems. I originally ran lightdm, which may have pulled in prefdm libraries. I looked around the Web and found that prefdm was causing problems of one kind or another for just about every distro. I am currently running sddm. I had never heard of prefdm. From Comment 120, it wasn't a display manager, but a chooser. locate still finds: /etc/X11/prefdm /usr/lib/systemd/system/prefdm.service IN MCC "Services", prefdm is set to start on boot, and is running. This is on Cauldron as a default system. Should I run a test, and if so, what? I hope that I haven't shot down the whole house of cards!
After adding iomem=relaxed to kernel-parameters, booting now from my default Mageia menu-entry (so no longer workarounds through recovery-mode). [root@localhost ~]# uname -a Linux localhost 4.8.7-desktop-1.mga6 #1 SMP Sat Nov 12 11:51:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# systemctl status sddm.service â sddm.service - Simple Desktop Display Manager Loaded: loaded (/usr/lib/systemd/system/sddm.service; enab Active: active (running) since Sun 2016-11-13 01:38:46 CET Docs: man:sddm(1) man:sddm.conf(5) Main PID: 3942 (sddm) CGroup: /system.slice/sddm.service ââ3942 /usr/bin/sddm ââ4083 /usr/libexec/Xorg -nolisten tcp -auth /var/ So far happy tester, goodnight.
This report has been moved to the following trackers: Bug 19781 for bugs resulting in this error on Real Hardware Bug 19782 for bugs resulting in this error in VBOX Please read the matching tracker when you hit the "Good luck" failure again, to see how to report it. Note that for _autologin_ causing this issue, bug 19234 will be kept!
Status: NEW => RESOLVEDResolution: (none) => MOVED
Use VirtualBox. Just update to kernel 4.8.8-1. Cant't boot to loggin-window. Can loggin with kernel 4.8.2
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=19798
@ all who have or do hit this bug: If you still hit the "good luck" error in a fresh install without workarounds, then please read: Bug 19781 for bugs resulting in this error on Real Hardware Bug 19782 for bugs resulting in this error in VBOX and file a new bug report as suggested there. If you don't know how to file a bug report, then please ask for help in the forums or on discuss ml. Note that adding to this bug report does not help. @ Jan Please file a separate bug report (no need to read bug 19782, since you don't get as far as the login window)
After successfully installing and running Mageia 6 for a while (some weeks) I unexpectedly started seeing the "good luck" bug - appears to boot OK but stops with a black screen and no GUI login screen - also able to ssh in from another system. I tried rebooting again yesterday with same black screen result. I left the system overnight and this morning noticed that I had a mouse cursor working on the black screen. I just tried ctrl-alt-backspace in the hope that the X-Windows system would be restarted and it worked! I now have a GUI login. Sharing this here as a possible workaround temporary solution. Does it work for anyone else? My hardware: HP z600, graphics card: 0f:00.0 VGA compatible controller: NVIDIA Corporation GF106GL [Quadro 2000] (rev a1) $ uname -r 4.9.50-server-1.mga6 $ rpm -qa | grep kernel kernel-server-devel-4.9.50-1.mga6-1-1.mga6 kernel-server-4.9.43-1.mga6-1-1.mga6 kernel-server-devel-latest-4.9.50-1.mga6 kernel-firmware-20170531-1.mga6 kernel-firmware-nonfree-20170531-1.mga6.nonfree kernel-server-4.9.50-1.mga6-1-1.mga6 kernel-server-devel-4.9.43-1.mga6-1-1.mga6 kernel-server-latest-4.9.50-1.mga6 kernel-userspace-headers-4.9.50-1.mga6 Desktop Environment is mate: task-mate-1.18.0-1.mga6
CC: (none) => paul.blackburn
The bug appearing so much later is new. Something must have triggered it. Did you update anything that would change your settings? I have seen the bug only after a change.
@Doug Laidlaw I keep my Mageia 6 systems up-to-date by running "urpmi --auto-update" on a regular basis. The only other change I can think of on that particular machine is that I have managed to find a solution to running VMware Workstation 12 (which seems to be working well) and documented it here: https://wiki.mageia.org/en/Installing_VMware_workstation_12_in_Mageia_6 I have other mga6 systems on different hardware (Acer laptop and netbook) which are also kept up to date but do not exhibit "black screen with no GUI login screen" issue. I can try to experiment on the mga6 laptop to see if installing VMware is related (but will be pushing the limits of that hardware - eg not so much RAM available). Are there any particular log or data files needed for analysis of the bug (if I can re-create it on the laptop)?
It could be a hardware issue. It came to my mind that I was advised to install the open source video driver then upgrade to the nVidia driver (Mageia RPMs.) That requires the "nokmsboot" option to be added to the kernel. When the proprietary drivers are installed from the beginning, nokmsboot is there, but an upgrade doesn't add it. It must be added manually to /etc/grub.d/default, and update-grub run afterwards.