Description of problem: After performing a number of updates, which IIRC involved new X input and video drivers (including sisimedia, which the hardware requires), one (at least!) kernel updates, my test notebook stopped running X11. For the record, it's the same hardware referenced in bug 19620 -- it used to work well (with the workaround mentioned there, that is). The symptom was a black screen after boot (curiously, the machine would not reboot, so I learned to use SysRq-REISU O (to shut it down). Trying to simplify things, I removed the xorg.conf file and did a restart. This time I left the notebook running for a little longer and the famous "Sorry, there was a problem starting your graphical display" message was shown. I don't know if there's any relation to another bug. I also tested with other kernels available at "advanced options" (inclusive the oldest one -- which used to work until now) and the issue seems not to be kernel related. Following advice in bug 19781, I decided to try the vesa driver (instead of the usual sisimedia), which worked and I could get a X screen, albeit at a lower resolution.
Created attachment 8698 [details] X11 log after being unable to run. Log obtained after booting into textmode as root. Xorg log from previous unsuccessful boot.
Created attachment 8699 [details] Dummy xorg.conf which makes X11 work
As asked in bug 19781, I inform Autologin is active/on.
instead of "vesa", you could try using "modesetting"
CC: (none) => tmb
I tried and it didn't work: "Screen 0 deleted because of no matching config section." To be honest, I never used that and assumed a mere (Driver "modesetting") line would do. I just got the "Sorry, there was a problem... Good Luck!" text screen (no sarcasm here -- I even think the message tries to comfort the user under the circumstances). Thanks for you suggestion and please advise me if some other specific info is needed.
CC: (none) => marja11 Attachment 8698 mime type: text/x-log => text/plain
(In reply to Renato Dali from comment #5) Hi Renato > > I just got the "Sorry, there was a problem... Good Luck!" text screen (no > sarcasm here -- I even think the message tries to comfort the user under the > circumstances). > Setting "Blocks: 19781" because it's a "Good luck" failure I understand you use SDDM as display manager, and Plasma5 as DE, is that correct? Do you have the same problems when disabling autologin? If so, do you have the same problems when using a different DM, e.g. lightdm or GDM, or when trying to login to a different DE? Assigning to kernel & drivers maintainers, anyway, since the problems started with driver updates
Assignee: bugsquad => kernelBlocks: (none) => 19781
Marja, thanks for your attention. WRT your questions: 1) LightDM is installed and being used and XDM as alternative; SDDM was not installed; 2) Xfce was chosen(*), but the failure happens before it gets executed, at the Xorg start phase; 3) Me thinks that the "good luck" error refers to a failure to start Xorg, not Plasma or another DE; 4) I didn't install another DE, because Xfce used to work satisfactorily until some days ago on the same hardware. (*) Plasma is not installed.
Some interesting developments: I forgot to mention I followed Marja's suggestion to deactivate the automatic login and then also removed the dummy xorg.conf selecting vesa, only to see the "Good luck" message again displayed. Since the result was identical, I probably didn't think it was worthy mentioning. Next, the dummy xorg.conf selecting the vesa driver was restored to make possible using the computer. There were a number of updates done while using the vesa driver. That was about 2h ago. I noticed there was nothing related to sisimedia, but there was some package apparently related to producing a hardware list. Being able to use the computer with the vesa driver, I decided to try drakconf to configure the graphics interface. For starters, drakconf said it would ignore my xorg.conf because it was defective or something. It correctly detected SiS 671/771 and suggested the sisimedia driver. When the configuration was tested, the computer coughed and the screen filled with occasional little horizontal streaks and at least one full-wide horizontal white line to finally get to the colorful testing pattern -- which appeared to have the desired resolution 1280x800. ============== HINT 1: One idea would be to include size markers in the testing patterns so that the user can tell the selected resolution is working. Basically, that amounts to drawing scales/rules with number markings. ============== No mouse pointer, though. The test ended well and both the Composite extension and the mouse acceleration were turned off (the intent was to recover the mouse pointer). ============== HINT 2: If you can, turn on the mouse on the test screen. It makes it easier to click on the buttons (Yes and No) that answer the âDid it work?â question... ============== The mouse acceleration toggle would reset to on after the test, no matter how many times I turned it off. Finally, the question: do you want to use that configuration? I answered yes and rebooted the computer (there was a message with that recommendation BTW). Now comes the interesting part. ------------------------------ Upon reboot, everything looked normal. The screen was clear and the letters were fine, meaning 1280x800 was attained in LightDM. Unexpectedly good â it was necessary to login because I had deactivated automatic login. To my surprise, I could not. After selecting the sole user and typing my password, I was returned to the initial login screen. Changing to IceWM didn't change anything. Not even by typing the user as "Another user". To test the keyboard I typed the password when LightDM expected the user name: all was correct. It simply was rejected. What now? I then tried to log as root. Lo and behold, a red screen came up and I could log in. "Welcome root" in that Mageia initial dialog feels weird. BTW, I seem to remember the red screen remaining during the session in Mageia 3 or 4, but it was immediately replaced by the new contest-winning Mageia wallpaper. The new xorg.conf file asked for sisimedia and had no option for "NoAccel"eration, but surprisingly included a SWCursor one (even if it was reset to [X] Use mouse hardware acceleration" all the time in drakconf). Once inside, I changed the DM from LightDM to XDM. After a reboot, with the unattractive XDM login manager, I tried and could login as a normal user -- to IceWM, that is. I don't know whether that is some XDM default or whether it was an option I unwillingly selected before. When I logged as root as described above, I clearly remember logging to Xfce _after_ even trying unsuccessfully IceWM as a normal user. Anyway, once logged as a normal user in IceWM I changed the DM back to LightDM, did a reboot and amazingly could log in as normal user to Xfce from LightDM. Just tested with xdpyinfo and it's 1280x800 alright. There are some new updates (libhawkey... librepo), but perhaps the machine should be allowed to rest a bit. :-) In the end, it indeed seems related to bug 19781! Thanks everyone for your help.
Some additional weird facts: - when trying to reboot, for a brief moment the Good Luck message was shown. I think it was hidden by the graphical screen and appeared in the reboot process; - I rebooted after commenting out the SWCursor xorg.conf option... it didn't reboot, I had to turn the computer off and it would not boot again! Is this important after all? - Booted with the recovery failsafe entry and reinstated the SWCursor option; reboot and saw that: a) the Good Luck message was shown and b) instead of a simple boot there were some 4 (four) tries, on each the screen going blank and then returning to the textmode Good Luck message... on the fourth time, graphics mode was entered and LightDM appeared -- and I'm typing on the notebook right now. That robot-like repeated tries might have happened before as I was typing the above comment on another machine and did not observe whether the boot was fast or not.
Hi, again. Just to write that I reactivated automatic login with the following result: This time I got some three tries of Xorg to go into graphics mode, followed by some 12 tries (maybe more) with the Good Luck message appearing and disappearing as it tried to get into graphics mode. After a while, the graphics screen appeared -- the login screen, that is. The automatic login selection apparently did not "stick". But I was able to login... and am using it right now.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=19854
Thanks for all the feedback, Renato :-) Could you please also either: 1. attach journal.txt that is the result of running, as root: journalctl -a --since=2016-11-26 > journal.txt (if it's too large, then compress it with xz xz journal.txt and then attach journal.txt.xz) 2. redo your tests and run, while replacing "?" with a number that you increase with every test, every time after booting up: journalctl -ab > journal_?.txt and attach each journal* file that you created, while telling what exactly was tested (autologin or not, custom xorg.conf, etc.) Choose option #1, unless you have plenty of time, since not all those separate logs might be needed. If you remember at what time you tested what, then it helps if you mention that :-)
Created attachment 8711 [details] Journal since 2016/11/23 Marja, here's the journal since 11/23 to give some context and because it seems I didn't use the computer on last 24 and 25. The end of the year is particularly busy at work, but I'll have in mind the need to post the most recent log lines in the future (like mentioned in option II).
It could be fixed now, can you try after updating?
Keywords: (none) => NEEDINFO
Created attachment 8716 [details] Journal after first update. Log obtained after update which include IIRC kernel and Xorg updates. No change observed: one boot with 21 attempts to enter graphics mode (!) and autologin option set but with no effect (i.e. login required).
Created attachment 8717 [details] Journal after second update. Actually after two updates but only the last one had a new kernel. Also, autologin was disabled prior to reboot and journal/log creation. Again no change observed. The number of tries the computer must do before finally getting to graphics mode varies from an earlier 4 (before this update) to 21 (also before). After the last update there were counted 14 retries while the computer failed to get a graphics screen. It is as if a necessary step needed for graphics to work is taking too long to complete and another step enters graphics mode, perceives the other step didn't end and then quits to textmode -- only to retry graphics later.
Once booted though the computer behaves well... all this was posted from the notebook in question... thanks for your attention, Samuel. I hope this helps somehow solve the issue which seemingly also affects others.
Just tried something: it ocurred to me to boot into text mode and from there to use startx and observe the results. Two files are going to be attached: the journal after booting into text mode and the Xorg.0.log, the latter obtained after a unsuccessful tentative to bring up X11. Alas, the followin pattern was noticed: a. Boot Mga6 into text mode and log in; b. Run startx, which fails (inevitably); c. Run immediately startx (OK, maybe wait 3 seconds): it inevitably succeeds when run a second time. Weird, eh? Looks like some initialization is needed... [Consider that I counted 21 unsuccessful tries when the computer boots directly into graphics mode!]
Created attachment 8719 [details] Journal after booting to text mode.
Created attachment 8720 [details] Xorg log of failed attempt to run X11
Created attachment 8721 [details] Xorg log of SUCCESSFUL attempt at running X11
Hi. Some news. I tested a lot of variations without many positive results. But I discovered that connecting an external monitor solves the problem: Mga6 boots normally to graphics mode and even autologins when told to. Fortunately, I still have a 1280x1024 monitor and the notebook mirrors the screen at full resolution (1280x800, hence two black bands above and below the screen on the external monitor). The only catch is that the notebook thinks there's only one output... I know the sisimedia driver accepts some special options after an [Option "EnableSisCtrl"] -- I may try that later. Also, the drakconf generated config has many modelines... and yet the sisimedia driver seems to create their own. I'll experiment with that later, too. This might be related to the presence of the external monitor (actually I had the idea to use it after reading the log file).
More "interesting" facts... After using the monitor, Xorg health seems improved somehow: now, without the monitor, there are no more n7umerous blinkings like before and after just one flash the notebook enters the graphical mode and LightDM's screen is shown (even though Autologin is set to work). After manual login, I can use xrandr to see all modes (1280x800, 1024x768, 800x600...) work at 60Hz only. After shutting down, connecting the monitor and **leaving it turned off**, I notice the notebook boots normally and Autologin works (!)... also, xrandr now exhibits lots of rates for each mode -- 1280x800 works at 75Hz, because the monitor can do it. I know monitors can respond EDID queries even if turned off, but why Autologin works? Also, does Xorg keeps some kind of state from one run to another -- and can the use of a external monitor change anything? Up until when I connected the monitor, startx kept malfunctioning the first time; thus, it is reasonable to suppose nothing was changed about whatever caused the many retries when LightDM was unable to enter graphics mode. I seem to recall that startx worked at the first time it was run after the monitor was connected -- and then I decided to use drakconf to get the automatic login again. I'll do more testing without the monitor to make sure there was really some kind of healing... Also uploading another journal...
Created attachment 8722 [details] Journal after connecting external monitor and mysterious healing of X11
Created attachment 8723 [details] Xorg log after "healing". Boot done with external monitor off.
Created attachment 8724 [details] Current plain xorg.conf -- copied at the "after healing" moment.
Yet more observations: After a night of sleep, I turned on the notebook and it booted after 1 (or perhaps two) screen flashings -- showing the LightDM login screen, that is (automatic login was set, so behavior was not the expected). I then decided to try the XDM login manager. Last time it booted to IceWM, so I chose not to restart the daemon/process and went for automatic login configuration. To my surprise, automatic login was not activated and, upon activation, there was a message stating the need to install an "Autologin" package. I can only conclude LightDM manages automatic logins by itself while XDM requires an extra package. I okayed the installation and then proceeded to reboot. Which never happened. The notebook returned to eternal hiccups, trying over and over unsuccessfully to enter graphics mode. This time I counted 21 times (the prior maximum) and turned the computer off (Alt+SysRq REISU O). That took between 5 and 10 minutes... *sigh* Turned it back on and went to breakfast. Minutes later it was still trying to boot with the messages I already observed before: [ OK ] Started Command Scheduler. Started Hold until boot process finishes up... I then used the same trick as yesterday and connected a monitor to the notebook's VGA output -- but didn't turn the monitor on. Now the notebook could boot immediately -- but to the XDM login screen... the Autologin package seemingly didn't do its thing. I logged in and now am posting this with the notebook. Though the performance of the SiS hardware is weak (videos only up to 480p), 1280x800 is quite gorgeous when correctly configured in Xfce _and_ Firefox, making for a fairly good experience -- with Flashblock installed, that is. In conclusion, XDM made things worse than LightDM. I will now reboot, after choosing LightDM again, to see whether that Autologin package changed anything for better or worse.
Some news. And a workaround. Since the last time, I've been trying some things around what I imagined could cause this bug. 1) Login problems. I did read some scripts, tried some configurations, did some tweaks and discovered that the use of an external monitor "cured" the lack of autologin. Tried other Display Managers (the ones which didn't pull dependencies the size of the Titanic) like LXDM. Installed additional LightDM settings package (which is interesting but did not sole anything). 2) Initialization settings: tweaked some settings in Drakconf, again to no avail. Interestingly, one can only ask for autologin in graphical mode. I wanted to have autologin and posterior execution of startx (a workaround IMHO). That means editing scripts which I could not find (a getty@ service or something). OTOH, I wonder whether it is possible to configure the video hardware and set "Run X at boot" off... Until now, all updates were applied but none could solve the autologin problem: I could get to LightDM (or any other), but had to login myself. Then I decided to reconfigure X11 (with drakx11) and suddenly it worked again. I ran a diff of the configuration which was working but didn't allow automatic login and the recently created by drakX11. Nothing special, nothing different, just some lines out of order. Then I noticed the lack of the NoAccel option and tested again the display corruption described in bug 19620. Yep, no doubt, an error while using mc. Then I decided to use again that option and the "no automatic login" issue returned instantly. That didn't cause any problems before but some update must have made that option bad with the sisimedia driver. Further testing revealed that the corruption mostly occurs when using mc (though pressing backspace repeatedly when the terminal bell would sound -- like when it's already at column 1) did cause some small artifacts (a little streak). Thus, the idea is not using that option. Possible workarounds to the mc problems are: a) not using it, but finding another textmode/console file manager (I could only find "ranger"... others are graphical); b) refraining from using mc and instead using a graphical FM like e.g. Thunar (that solution is not adequate for use with the console -- e.g. Crtl-Alt-F3 -- but mc can be kept for exclusive console use); c) using mc -s (for "slow"): that helps a lot, problems are kept at a very minimum, but frame characters are lost. I think these are viable options, maybe even good enough as workaround.
Summary: As of 2016/11/26, Mga6 sta1 fully updated won't run X11 => Cannot autologin - Xorg? sisimedia? systemd? (was 2016/11/26: Mga6 sta1 won't run X11)
Changed the bug title to reflect recent discoveries. Also I must mention bug 19927 (on a different hardware!), because the first attachment has the systemd message about not being able to take control of a console and thus disabling systemd.logind.
I did some additional experimentation and reinstalled Mga6 sta2 (netinstall) to see whether the problem would occur on the most recent package versions. For testing purposes, and following a comment by Thierry Vignaud in another bug report ( https://bugs.mageia.org/show_bug.cgi?id=19620#c10 ), I decided to configure the driver as VESA instead of the automatically detected sisimedia. As a result, Mageia 6 sta2 booted with a different resolution (1024x768 against a chosen 1280x800), but it could configured successfully to autologin. Next, the Xorg driver was configured to sisimedia (the default choice for the hardware) and the inability to autologin returned. It is therefore ascertained that the problem is related to the unmaintained sisimedia driver, exactly as commented in Thierry's post. Given the UPSTREAM dependence which will not be addressed for all we know, the present bug might be closed as WONTFIX. OTOH, I could configure Mageia to start in text mode and -- after a manual login -- it was possible to run "startxfce". This is an acceptable workaround (for me!). Thus, I'm closing the bug as WORKSFORME. If someone has a better idea, please reopen it. Thanks and a Happy Christmas for everyone!
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME