Bug 17233

Mageia-6-dev1-LiveDVD-PLASMA5-x86_64-DVD.iso 
Mon Nov 23 16:00:00 CET 2015

Whiteboard: (none) => 6dev1

can you please attach journalctl.txt that is the result of, as root:

  journalctl -b > journalctl.txt


and also please attach the relevant Xorg log(s) from /var/log/

(probably more than one, because you tested more than one driver. Also, I forgot what triggers that Xorg.9.log gets written instead of Xorg.0.log)

it would be nice to know whether the same problem exists in current cauldron, and if so, whether it persists when e.g. using lightdm as DM and XFCE as DE

if you don't have a cauldron installed, could you then pleade just try to add a mirror, install lighdm, set lightdm instead of sddm with drakdm and then do
   systemctl restart dm.service

CC: (none) => marja11
Keywords: (none) => NEEDINFO

In the mean time, the Live DVD has gone to its second iso, and that one is worse than the first one. I even do not get that far in the booting process. Is there a way to pickup the first version????

(In reply to Herman Viaene from comment #3)
> In the mean time, the Live DVD has gone to its second iso, and that one is
> worse than the first one. I even do not get that far in the booting process.
> Is there a way to pickup the first version????

I still have it on a backup disk.

I'm trying to upload it, here
http://waesvanm.home.xs4all.nl/QA/Mageia-6-dev1-LiveDVD-PLASMA5-x86_64-DVD/

but my first attempt failed, maybe I used up already to much of my xs4all disk space :-/

s/to/too/

@ Herman

I'll send you a link to the iso once it is uploaded, don't try to download it from the above link, because it'll be moved.

Created attachment 7274 [details]
journal

Created attachment 7275 [details]
Xorg.log

Created attachment 7276 [details]
Xorg.log.old

Thanks for the logs, Herman.

I hope someone will have a look at them, because I don't understand enough of what I see in them.

I only know that after
Dec 12 06:48:19 localhost sddm[1066]: Adding cookie to "/var/run/sddm/{3c9e3513-48a5-46f5-963a-565c171b1cc3}"
This should _not_ happen:
Dec 12 06:48:19 localhost sddm[1066]: Display server stopped.
Dec 12 06:48:19 localhost sddm[1066]: Running display stop script  "/usr/share/sddm/scripts/Xstop"

And this looks weird, too:
Dec 12 06:48:19 localhost sddm[1066]: QProcess: Destroyed while process ("/usr/libexec/sddm-helper") is still running.

and I don't understand what causes things like
(EE) open /dev/dri/card0: No such file or directory
in the Xorg log

Were you testing in a VM (VBox), or on real hw?

CC: (none) => doktor5000

The log looks ok, sddm tries to start an X server 4 times, and then it starts the service that is shown when the display manager failed to start (the black screen that informs that X failed to start ...)

As an excerpt:

Dec 12 06:48:20 localhost sddm[1469]: QProcess: Destroyed while process ("/usr/libexec/sddm-helper") is still running.

Dec 12 06:48:20 localhost systemd[1]: Failed to start Display Manager.
Dec 12 06:48:20 localhost systemd[1]: prefdm.service: Unit entered failed state.
Dec 12 06:48:20 localhost systemd[1]: prefdm.service: Triggering OnFailure= dependencies.
Dec 12 06:48:20 localhost systemd[1]: prefdm.service: Failed with result 'start-limit'.
Dec 12 06:48:20 localhost systemd[1]: Started Display Manager Failure Message.



Question is why does X fail to start, I saw this same problem (X fails to start, shows black failure message) too today when testing Mageia-6-dev1-LiveDVD-PLASMA5-x86_64-DVD on my physical box to try to reproduce bug 17221. And my physical box has nvidia graphics, so this is not only with ATI.

@Marja: He does test on real hardware, otherwise you wouldn't see it try to load the driver for the physical graphics card he mentioned. For the question about the error message, that's explained easier in context:

[    34.912] (II) [KMS] drm report modesetting isn't supported.
[    34.912] (EE) open /dev/dri/card0: No such file or directory
[    34.912] (WW) Falling back to old probe method for modesetting

As it cannot use radeon driver, then it falls back to framebuffer driver but seems it cannot detect the screen resolution and then it quits:

[    34.913] (II) FBDEV(3): using default device
[    34.913] (EE) Screen 0 deleted because of no matching config section.
[    34.913] (II) UnloadModule: "radeon"
[    34.913] (EE) Screen 0 deleted because of no matching config section.
[    34.913] (II) UnloadModule: "modesetting"
[    34.913] (EE) Screen 0 deleted because of no matching config section.
[    34.913] (II) UnloadModule: "fbdev"
[    34.913] (II) UnloadSubModule: "fbdevhw"
[    34.913] (EE) 
Fatal server error:
[    34.913] (EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices
[    34.913] (EE) 
[    34.913] (EE)

On my system, which has ...
# lspcidrake |grep Card
Card:ATI Radeon HD 5000 to HD 6300 (radeon/fglrx): Advanced Micro Devices, Inc. [AMD/ATI]|Cedar [Radeon HD 5000/6000/7350/8350 Series] [DISPLAY_VGA]

I compared the modules loaded when running the live iso vs a classical install,
which works and found that the problem was due to the radeon module not being
loaded. The following workaround, after it boots to text mode, works ...

Login as root (no password)
modprobe radeon
exit
login as live (no password)
startx startkde OR startx startgnome (as appropriate)

CC: (none) => davidwhodgins

On the Acer D620 with Radeon Xpress 1200, I have been running the classical i586 DVD installation using Xfce. I've kept it up to date. When I now try to run Plasma on it (changing the selection at the login screen), Plasma runs OK (as indicated in Comment 12).
I cannot test the x86-64 anymore as the HP laptop died in the mean time. I will try the latest Live DVD when the download finishes.

Downloaded i586 Plasma Live dated March 17th and tried to do the workaround as explained in Comment 12. Systems hangs now after entering modprobe "radeon" for some 20 minutes by now, keyboard completely blocked.

Created attachment 8174 [details]
CLI output of journalctl -b -u prefdm.service

I have the same issue both in a fresh install of Mageia-6-RC-x86_64-DVD.iso of 12 July (display manager sddm) and Mageia-6-RC-LiveDVD-PLASMA5-x86_64-DVD.iso.

The system is a notebook Sony Vaio E Series SVE1713G4EW
----------------------------------------------
[root@localhost ~]# lspci -nnk | grep -iA3 vga
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Thames [Radeon HD 7550M/7570M/7650M] [1002:6841]
        Subsystem: Sony Corporation Device [104d:90ac]
        Kernel driver in use: radeon
        Kernel modules: radeon
----------------------------------------------

The work around from Dave Hodgins (#12) works for me. Quite odd, but I have a working instance installed with Mageia-6-sta1-x86_64-DVD.iso. I cannot spot any difference in the display settings.

Greetings,
Ulrich Beckmann

(In reply to Ulrich Beckmann from comment #15)
> 
> I have the same issue both in a fresh install of Mageia-6-RC-x86_64-DVD.iso
> of 12 July (display manager sddm) and
> Mageia-6-RC-LiveDVD-PLASMA5-x86_64-DVD.iso.
> 
Tested again with Mageia-6-RC-x86_64-DVD.iso from Aug 13th. Display manager and login work fine now. No workaround needed.

Ulrich

Great news! What about you Herman, do you still reproduce the issue with current RC ISOs?

Not tested anymore up to now with live, only with classical. I will try tonight.

The classical installation runs well on the AcerD620 (see Comment 1 and 13 above)(since ages by now).
Just downloaded the LivePlasmai586 dd 22/7/2016: hangs with the message "There has been a problem with your graphical display ......... Good luck Press any key"
As in Comment 12, I went on and at the CLI
modprobe radeon
systemctl default
let me complete the startup , but after entering all parameters (Dutch, belgian keyboard, timezon Brussels) I got to the Mageia splash screen, this on disappeared after a little while to be replaced by a black screen and a mouse indicator which doe snot respond to moving the mouse. While I waas typing this (and I do not type fast) nothing changes anymore, so giving up on it.

As the LivePlasma isos were not rebuilt, one could not expect that the issue is solved yet. I had the issue also in my KDE installation from classical sta 1, and it was gone probably with the update of x11-driver-* on July 23rd.

Commment 13: If you had installed Plasma from the first set of classical rc isos, you would have had the same issue at reboot. KDE Plasma uses sddm as default display manager, whereas Xfce uses a different one.

Greetings
Ulrich

Is this issue still valid with sta2 ISOs?

No, does not repeat anymore with latest Live nor classical install

thanks a lot
=> Closing

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