Created attachment 6221 [details]
journal from live mode real hw

Cut off mid-sentence, sorry.

Vbox has no tty's available to debug but real hw (athlon64x2,nvidia340,ivtv) does have tty's and journal shows an error similar to bug 15468 which was about installs but previously fixed by the 'big hammer' fix.

fixed in ISO from 2015-04-10

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

I'm sorry but it isn't fixed. I'm getting this result on my hardware as of the RC ISO dated 4/10.

I am only an end-user so I know only what works and what doesn't. I was referred here from Bug 15235 after they reported *that* bug fixed.

That bug was a release blocker; if this one is considered "fixed" and will not be further addressed, then I am stuck on M4 or with another distro. I'm resolved not to go crawling back to Windows.

CC: (none) => alan.augustson

Reopening as per comment 4.
Please give some nice instructions to Alan about how to debug this further :)

Priority: Normal => release_blocker
Status: RESOLVED => REOPENED
CC: (none) => rverschelde
Resolution: FIXED => (none)

I was able to get a root console just before the "Oh no" screen, and ran journalctl.

The final [FAILED]-level error read:

xt_addrtype: ipv6 does not support BROADCAST matching

...which was what Bug 15235 was about.

So now I have no idea which bug I'm dealing with.

This message is not related at all and is really just a warningas nothing

CC: (none) => thierry.vignaud

works fien for me now so must be hardware dependent.

Experiencing it here in Vbox and on real hardware:

ISO Name: Mageia-5-RC-LiveDVD-GNOME-i586-DVD.iso
DATE.txt: Wed Apr 15 08:00:00 CEST 2015
md5sum:   d51b5b1761e834b63b1c780216237951

Repeated trys still same problem.

Vbox 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 4 64-bit, Nvidia driver
virtualbox-4.3.10-1.1.mga4.x86_64
virtualbox-guest-additions-4.3.10-1.1.mga4.x86_64

Hardware test platform:
Intel, P4 530J 3.0 GHz, 800MHz FSB, 1MB L2, LGA 775
GigaByte  GA-81915G Pro F4  i915G  LGA 775  MoBo
 Marvel Yukon 88E8001 Gigabit LAN
 Intel High Def Audio, Azalia (C-Media 9880) (snd-hda-intel)
 Intel Graphics Media Accelerator 900 (Intel 82915G)
Kingston 4GB (2 x 2GB) DDR400 PC-3200
250GB Seagate
Kingwin KF-91-BK SATA Mobile Rack
Kingwin KF-91-T-BK SATA Mobile Rack Tray
Sony CD/DVD-RW DWQ120AB2

CC: (none) => wilcal.int

Created attachment 6287 [details]
Output from journalctl, boot attempt 15 Apr 2015 00:15 GMT approx.

Output from journalctl, boot attempt 15 Apr 2015 00:15 GMT approx.

Comment on attachment 6287 [details]
Output from journalctl, boot attempt 15 Apr 2015 00:15 GMT approx.

System specs:

Intel Core i7-720QM
ATI Mobility Radeon HD 5870

Can you also give the content of DATE.txt Alan please which will show which build of the RC iso you are using.

Reproduced in vbox with gnome livedvd both 32 & 64

Wed Apr 15 08:00:00 CEST 2015

tty's are corrupted, with just green lines at the top of the screen. Unable to grab a journal from here.

Claire, that was the RC dated 10 April.

Just discovered there was a new ISO as of yesterday. Will test immediately.

MageiaSync shows "Failed" in the Date column, every time I try to sync the latest ISO. Advise?

Ignore the date check in mageiasync for now. Manually check the contents of DATE.txt once the sync has finished though please.

Created attachment 6296 [details]
Output from journalctl from failed boot, RC dated 15 Apr 2015

System specs:

Intel Core i7-720QM
ATI Mobility Radeon HD 5870

I found in that output an (EE) that looked AMD/ATi specific:

(EE) AIGLX error: failed to open /usr/X11R6/lib64/modules/dri/fglrx_dri.so, error[/usr/X11R6/lib64/modules/dri/fglrx_dri.so: cannot open shared object file: No such file or directory

Is that meaningful here?

(In reply to Alan Augustson from comment #19)
> Is that meaningful here?

I don't think so, because the following line says

(II) AIGLX: Loaded and initialized OpenGL driver(II) GLX: Initialized DRI GL provider for screen 0

I am seeing the same messages on my working system.

CC: (none) => mageia

(In reply to Alan Augustson from comment #19)
> I found in that output an (EE) that looked AMD/ATi specific:
> 
> (EE) AIGLX error: failed to open /usr/X11R6/lib64/modules/dri/fglrx_dri.so,
> error[/usr/X11R6/lib64/modules/dri/fglrx_dri.so: cannot open shared object
> file: No such file or directory
> 
> Is that meaningful here?

Nope, its just a message that it didn't find the file in that path.

the fglrx driver probes several paths until it finds the file it needs, 
so that should only be an info flag, not an error one, but nothing to worry about

Well, how about this following passage?


Apr 16 10:53:08 localhost gnome-session[2790]: (gnome-session-failed:3033): Gdk-WARNING **: gnome-session-failed: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Apr 16 10:53:08 localhost pulseaudio[2983]: XIO:  fatal IO error 0 (Success) on X server ":0"
Apr 16 10:53:08 localhost pulseaudio[2983]: after 12 requests (6 known processed) with 0 events remaining.
Apr 16 10:53:08 localhost gnome-session[2790]: (evolution-alarm-notify:3059): Gdk-WARNING **: evolution-alarm-notify: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Apr 16 10:53:08 localhost org.gtk.vfs.Daemon[2895]: A connection to the bus can't be made
Apr 16 10:53:08 localhost org.gtk.vfs.Daemon[2895]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
Apr 16 10:53:08 localhost gnome-session[2790]: mageiawelcome.py: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Apr 16 10:53:08 localhost gnome-session[2790]: WARNING: App 'gnome-settings-daemon.desktop' exited with code 1
Apr 16 10:53:08 localhost gnome-session[2790]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
Apr 16 10:53:08 localhost gnome-session[2790]: pam-panel-icon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Apr 16 10:53:08 localhost gnome-session[2790]: (nm-applet:3081): Gdk-WARNING **: nm-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Apr 16 10:53:08 localhost gnome-session[2790]: gnome-session[2790]: WARNING: App 'gnome-settings-daemon.desktop' exited with code 1
Apr 16 10:53:08 localhost gnome-session[2790]: (net_applet:3075): Gdk-WARNING **: net_applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.

Looks like this is where the problem starts:

Apr 16 10:52:40 localhost gnome-session[2790]: X Error of failed request:  BadValue (integer parameter out of range for operation)
Apr 16 10:52:40 localhost gnome-session[2790]: Major opcode of failed request:  142 (RANDR)
Apr 16 10:52:40 localhost gnome-session[2790]: Minor opcode of failed request:  13 (RRChangeOutputProperty)
Apr 16 10:52:40 localhost gnome-session[2790]: Value in failed request:  0x79
Apr 16 10:52:40 localhost gnome-session[2790]: Serial number of failed request:  307
Apr 16 10:52:40 localhost gnome-session[2790]: Current serial number in output stream:  309
Apr 16 10:52:40 localhost gnome-session[2790]: WARNING: App 'gnome-shell.desktop' exited with code 1
Apr 16 10:52:40 localhost gnome-session[2790]: WARNING: App 'gnome-shell.desktop' respawning too quickly
Apr 16 10:52:40 localhost gnome-session[2790]: gnome-session[2790]: WARNING: App 'gnome-shell.desktop' exited with code 1
Apr 16 10:52:40 localhost gnome-session[2790]: gnome-session[2790]: WARNING: App 'gnome-shell.desktop' respawning too quickly
Apr 16 10:52:40 localhost gnome-session[2790]: Unrecoverable failure in required component gnome-shell.desktop

A quick web search showed up a couple of bug reports from people experiencing the same problem:

  https://bbs.archlinux.org/viewtopic.php?id=188475
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767673

but no solution other than to use the radeon driver.

Created attachment 6319 [details]
journalctl output from failed boot using xdriver=radeon

Since the other referenced bugs seem to point to AMD Catalyst as the culprit, I attempted yet another time using the xdriver=radeon option. The exact same results, so far as I could tell. Here's the journalctl output.

Just successfully booted using Ubuntu GNOME 14.10 and the fglrx driver. So I don't know if the AMD graphics problem is Mageia-specific but evidence so far is pointing in that direction.

(In reply to Alan Augustson from comment #24)
> Since the other referenced bugs seem to point to AMD Catalyst as the
> culprit, I attempted yet another time using the xdriver=radeon option. The
> exact same results, so far as I could tell. Here's the journalctl output.

Same effect, but different cause:

Apr 20 07:36:19 localhost gdm-Xorg-:0[1578]: (II) Module glx: vendor="NVIDIA Corporation"

Apr 20 07:36:19 localhost gdm-Xorg-:0[1578]: (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)

This means you have no 3D acceleration, and GNOME won't start without it.

I can reproduce this on my hardware when booting from the Live DVD. It doesn't happen when using the radeon driver in my installed system.

If you add "nomodeset" to kernel command line before booting. does it change anything ?

(In reply to Alan Augustson from comment #25)
> Just successfully booted using Ubuntu GNOME 14.10 and the fglrx driver. So I
> don't know if the AMD graphics problem is Mageia-specific but evidence so
> far is pointing in that direction.

Well, 14.10 has older kernel, older mesa, older fglrx, ... so not a really good comparision... but yes... the fglrx driver sucks ...

Is ubuntu using fglrx driver in live mode, or do you need to install it after ?

(In reply to Thomas Backlund from comment #27)
> If you add "nomodeset" to kernel command line before booting. does it change
> anything ?

I assume this was a question to Alan, when using the fglrx driver. With xdriver=radeon nomodeset, you get

  *ERROR* No UMS support in radeon module!

and the X server dies before GNOME can even get started.

I have just tried the Live DVD on a machine with an old Radeon card that is no longer supported by fglrx - in that case it defaults to the radeon driver and correctly loads the X.org GLX module, not the nVidia one, and reaches the GNOME desktop.

It was for both as you reported issues with nvidia driver too

(In reply to Thomas Backlund from comment #30)
> It was for both as you reported issues with nvidia driver too

Ah, no, it's the radeon driver, but it's incorrectly loading the nvidia GLX module. From Alan's log:

Apr 20 07:36:55 localhost gdm-Xorg-:1[2770]: (II) Loading /usr/lib64/xorg/extra-modules/libglx.so
Apr 20 07:36:55 localhost gdm-Xorg-:1[2770]: (II) Module glx: vendor="NVIDIA Corporation"

which is the same when I boot from the Live DVD on my newer machine with xdriver=radeon.

Alan, try booting with xdriver=ati. This works for me.

Yeah, the xorg driver is ati, it's the kernel module that is radeon


sorry for not pointing that out...

"xdriver=ati" works! So is it possible that the AMD Catalyst driver is simply no longer GNOME-compatible, or GNOME-compliant, or whatever?

I'm pretty darn happy about this... I was *not* interested in KDE, or in any other distro.

is anyone here successfully using M5 with fglrx and Gnome? last I knew, there were some pretty vast performance differences, mainly 3D acceleration speed and operating temperature, between fglrx and the radeon driver. Cannot find any recent sources saying anything about the current state of compatibility.

(In reply to Thomas Backlund from comment #33)
> Yeah, the xorg driver is ati, it's the kernel module that is radeon
> 
> sorry for not pointing that out...

Even the errata for M-4 gets it wrong, and suggests using xdriver=radeon :-( I guess this has gone unnoticed because xdriver=radeon does actually switch to using the radeon driver. Where it goes wrong is that service_harddrake tries to install the x11-driver-video-radeon package - which doesn't exist - and because that fails it misses the step of cleaning out the nvidia modules from /usr/lib64/xorg/extra-modules. The only effect of this is you don't get 3D acceleration.

This trap for the unwary could be fixed by making service_harddrake translate the names.

(In reply to Martin Whitaker from comment #36)
> This trap for the unwary could be fixed by making service_harddrake
> translate the names.

Or maybe add a virtual provide for x11-driver-video-radeon in x11-driver-video-ati? (and maybe doing something similar for other packages with discrepancies between the driver name and the x11 package name).

(In reply to Alan Augustson from comment #34)
> "xdriver=ati" works! So is it possible that the AMD Catalyst driver is
> simply no longer GNOME-compatible, or GNOME-compliant, or whatever?
> 
I can successfully boot to the desktop with the GNOME Live DVD using fglrx, so it must be sensitive to particular combinations of hardware. My guess is it relates to your display size (1600x900), as it fails on a call to an XRandR function, and XRandR is the module that handles changing the display resolution.

(In reply to Rémi Verschelde from comment #37)
> Or maybe add a virtual provide for x11-driver-video-radeon in
> x11-driver-video-ati? (and maybe doing something similar for other packages
> with discrepancies between the driver name and the x11 package name).

Yes, that would work too. Looking at the man page for ati, it says it is a wrapper for three drivers, radeon, r128, and mach64.

So I wonder if it would be feasible to install while using "ati", then install fglrx later? Seems that the worst case scenario would only require a reboot using ati and disabling fglrx once again.

(In reply to Alan Augustson from comment #40)
> So I wonder if it would be feasible to install while using "ati", then
> install fglrx later? Seems that the worst case scenario would only require a
> reboot using ati and disabling fglrx once again.

My plans exactly, so... 

round 9 live medias now use ati driver in live mode, and fglrx can be activated after install

Well I just tried that very approach with our existing ISO and wound up with an unbootable install. I'll try this one. If I can find the instructions for getting and configuring MageiaSync, that is.

But the performance of the ati driver is so very substandard compared to fglrx -- problematic though it obviously is -- that if I cannot get the proprietary driver working I simply cannot use Gnome on M5.

@Alan, the "OH no" issue is mostly in live mode, so if you get it installed with -ati driver, you can configure fglrx after booting into the installed system.

Created attachment 6328 [details]
journalctl output from failed boot, 04/22/2015

https://oliverchang.github.io/2014/12/22/fixing-linux-amd-catalyst-linux-drivers-gdm/

Has this already been tried? Is it even applicable to our environment?

I see now that my journalctl output attachment failed -- somehow it was an enormous size. So here instead is what I tried.

I did the following:

1. Installed and booted successfully using ati driver.
2. Switched graphics to fglrx.
3. Ran aticonfig --initial as root.
4. Rebooted, making sure to remove the "xdriver=ati" option.

Unable to start the X server. Just a black screen. Ctrl-Alt-Backspace didn't help.

Thankfully I was able to reach a text login with Ctrl-Alt-F2, and ran drakconf from the command line. Didn't even know that was possible, but I chanced it.

I must have my Catalyst driver working. The radeon driver is simply too subpar for the specific application I run most of all.

(In reply to Alan Augustson from comment #45)
> https://oliverchang.github.io/2014/12/22/fixing-linux-amd-catalyst-linux-
> drivers-gdm/
> 
> Has this already been tried? Is it even applicable to our environment?

Yes, see bug 15235, starting at comment 40. Sadly, you have a different bug.

Is "my" bug still covered in this process? Do I have to start all over again?

https://wiki.archlinux.org/index.php/GDM#Failure_to_start_with_AMD_Catalyst_driver

The consensus at Arch Linux is "You're screwed, mate; get a new computer".

I'm hoping we can do better.

(In reply to Alan Augustson from comment #46)

> I did the following:
> 
> 1. Installed and booted successfully using ati driver.
> 2. Switched graphics to fglrx.
> 3. Ran aticonfig --initial as root.
> 4. Rebooted, making sure to remove the "xdriver=ati" option.
> 

This it wrong way to do it, especially point 3.

instead: 
1. simply boot round 9 iso (dont add any "xdriver=ati")
2. install
3. reboot into installed system
4. go into mageia control center, configure X server, answer yes when asked if you want to use proprietary driver. mcc will then install the fglrx drivers and do the necessary config changes.
5. close mcc, reboot into system with hopefully working fglrx

Did precisely as directed in Comment 50; achieved precisely the same result as in Comment 46.

The journalctl output from my most recent attempt is too large to attach; but I did notice the following:

=====

Apr 22 18:26:46 celene gdm-Xorg-:0[1076]: (II) fglrx(0): EDID vendor "LGD", prod id 477
Apr 22 18:26:46 celene gdm-Xorg-:0[1076]: (II) fglrx(0): Printing DDC gathered Modelines:
Apr 22 18:26:46 celene gdm-Xorg-:0[1076]: (II) fglrx(0): Modeline "1600x900"x0.0   97.75  1600 1648 1696 1784  900 902 905 912 -hsync -vsync (54.8 kHz eP)
Apr 22 18:26:46 celene gnome-session[1528]: X Error of failed request:  BadValue (integer parameter out of range for operation)
Apr 22 18:26:46 celene gnome-session[1528]: Major opcode of failed request:  142 (RANDR)
Apr 22 18:26:46 celene gnome-session[1528]: Minor opcode of failed request:  13 (RRChangeOutputProperty)
Apr 22 18:26:46 celene gnome-session[1528]: Value in failed request:  0x79
Apr 22 18:26:46 celene gnome-session[1528]: Serial number of failed request:  307
Apr 22 18:26:46 celene gnome-session[1528]: Current serial number in output stream:  309

=====

Is this meaningful to this bug?

Ouch. "Major opcode of failed request:  142 (RANDR)"
 
That looks like something from mga-bg-res calling out to xrandr for background resizing  ...

Can you compress the log and then attach it

Thomas, you can see the same failure in attachment 6296 [details].

Alan, are you using journalctl without any options to generate the log? If so, you can reduce the size by using the -b option, e.g.

  journalctl -b 0

just outputs the log from when you last booted the system, and

  journalctl -b -1

outputs the log from the previous boot up until the last boot.

(In reply to Thomas Backlund from comment #53)
> Ouch. "Major opcode of failed request:  142 (RANDR)"
>  
> That looks like something from mga-bg-res calling out to xrandr for
> background resizing  ...
> 
I don't think the error would arise in gnome-session. mga-bg-res (up to 0.6) only calls xrandr to determine the monitor resolution; if xrandr fails, the bash script will just proceed with an empty resolution screen and possibly fail. But that should not break gnome-session IMO.

I've pushed mga-bg-res 0.7 in core/updates_testing that uses monitor-probe instead of xrandr and runs as a systemd service, but I'd like to have more feedback about it before getting it on the RC ISOs and possibly breaking more stuff :)

Created attachment 6335 [details]
journalctl output, 04/23/2015

I had forgotten to mention the "Oh no" screen has returned.

Attachment 6328 is obsolete: 0 => 1

(In reply to Rémi Verschelde from comment #55)
> (In reply to Thomas Backlund from comment #53)

> I've pushed mga-bg-res 0.7 in core/updates_testing that uses monitor-probe
> instead of xrandr and runs as a systemd service, but I'd like to have more
> feedback about it before getting it on the RC ISOs and possibly breaking
> more stuff :)

Remi, do I understand correctly, that I can enable core/updates_testing and receive this patch without syncing and reinstalling? If so, I can test this afternoon or evening (GMT-6).

(In reply to Alan Augustson from comment #57)
> (In reply to Rémi Verschelde from comment #55)
> 
> > I've pushed mga-bg-res 0.7 in core/updates_testing that uses monitor-probe
> > instead of xrandr and runs as a systemd service, but I'd like to have more
> > feedback about it before getting it on the RC ISOs and possibly breaking
> > more stuff :)
> 
> Remi, do I understand correctly, that I can enable core/updates_testing and
> receive this patch without syncing and reinstalling? If so, I can test this
> afternoon or evening (GMT-6).

You do understand correctly, but IMO this is not related to the issue that you are having. But it's worth trying if you still have the system at hand and manage to perform updates even though GNOME won't start.

When GNOME fails, I have been able to exit to a command line, log in as root, obtain a journalctl, run drakconf from the command line, reset to ati driver and shutdown -r.

So it's no inconvenience.

But you don't expect your patch to work, so... are we back to Catalyst simply being incompatible with GNOME?

Created attachment 6342 [details]
Second boot attempt, 04/23/2015

No change in results.

Attachment 6287 is obsolete: 0 => 1
Attachment 6296 is obsolete: 0 => 1
Attachment 6319 is obsolete: 0 => 1
Attachment 6335 is obsolete: 0 => 1

Created attachment 6343 [details]
Patch containing workaround from GNOME bug 741581

This looks to be the same problem Alan is seeing:

  https://bugzilla.gnome.org/show_bug.cgi?id=741581

The bug reporter seems to have found a workaround. The attached patch for the mutter package should implement this, and is probably worth a try. I can't test it myself, as the bug doesn't manifest itself on my hardware.

(In reply to Martin Whitaker from comment #38)
> (In reply to Alan Augustson from comment #34)
> > "xdriver=ati" works! So is it possible that the AMD Catalyst driver is
> > simply no longer GNOME-compatible, or GNOME-compliant, or whatever?
> > 
> I can successfully boot to the desktop with the GNOME Live DVD using fglrx,
> so it must be sensitive to particular combinations of hardware. My guess is
> it relates to your display size (1600x900), as it fails on a call to an
> XRandR function, and XRandR is the module that handles changing the display
> resolution.

Martin, which AMD card are you using? I wonder if the answer might provide a clue. Mine is a 5870.

(In reply to Martin Whitaker from comment #61)
> Created attachment 6343 [details]
> Patch containing workaround from GNOME bug 741581
> 
> This looks to be the same problem Alan is seeing:
> 
>   https://bugzilla.gnome.org/show_bug.cgi?id=741581
> 
> The bug reporter seems to have found a workaround. The attached patch for
> the mutter package should implement this, and is probably worth a try. I
> can't test it myself, as the bug doesn't manifest itself on my hardware.

I'll be happy to test as soon as I'm notified it's in there...

(In reply to Martin Whitaker from comment #61)
> Created attachment 6343 [details]
> Patch containing workaround from GNOME bug 741581
> 
> This looks to be the same problem Alan is seeing:
> 
>   https://bugzilla.gnome.org/show_bug.cgi?id=741581
> 
> The bug reporter seems to have found a workaround. The attached patch for
> the mutter package should implement this, and is probably worth a try. I
> can't test it myself, as the bug doesn't manifest itself on my hardware.


I've submitted mutter-3.14.3-4.mga5 to Core Updates Testing with that patch applied, please test it

Created attachment 6346 [details]
Boot attempt 04/24/2015

Well, since that patch I cannot start gnome-session using either fglrx *or* the ati driver. Either results in the "Oh no" screen. Writing now from the Windows partition.

I seem to be the one holding up the release for everyone.  :/

Alan, in case you don't know the technique, you can get back to the previous state by:

  - booting in run level 3 (just add the number 3 on the boot command line)
  - log in as root
  - remove the updates_testing repository, e.g.
      urpmi.removemedia "Core Updates Testing"
  - reinstall the old package, e.g.
      urpmi --downgrade lib64mutter-private0

I've managed to reproduce the latest failure on my system, but can't figure out why it's not working. The call to gdk_error_trap_push() is causing a segfault. Nothing in the GDK documentation tells me why it wouldn't work.

Actually I was able to figure that out solo. I was rather proud of myself.  xD

So, in order to be able to get things done I've switched back to KDE. I can continue testing if and when new patches become available.

I've pushed fglrx 15.200 beta (from ubuntu prerelease) to Nonfree Updates Testing...

Can you test if that is any better / more stable with Gnome

Got Nonfree Updates Testing enabled. Just waiting for Thomas's fglrx beta push to appear among my updates and I'll test immediately.

As a precaution, can someone tell me how to change my session back to KDE from a command line, if Gnome should fail? Thanks.

Created attachment 6352 [details]
Boot attempt w/ fglrx 15.2 beta and GNOME

Sorry, got the same "Oh no" screen as always. Thankfully, I was smart enough (finally) to set KDM as my login manager, so Ctrl-Alt-Backspace got me back to a login where I could re-select KDE and keep working.

@Alan.

Could you try to do a clean install with classical iso and see if you get the same "Oh no"...

I will, but this will take quite some time. MageiaSync is refusing to download any faster than 100 kB/sec, at which rate I'll be fortunate to have a complete ISO in under twelve hours. Patience is appreciated.

@Thomas, if you haven't done so already, it would be a good idea to remove the patched mutter from updates testing in case anyone else accidentally installs it.

gnome-shell failed. Same symptoms using the full installer DVD.

First test of RC candidate, live, 64-bit, intel 810 and later graphic. The "Oh no" appears as in the beta versions. Since it seemed the problem was solved, I tried to follow suggestions that appeared after I log out with ctrl-alt-backspace. I load the live with failsafe, used drakx11 to set video, and typed init 5. The dreadful Oh No ! writing still appears. The only case I can get the Gnome shell is if, after the failsafe booting, I use the whole French option (language and keyboard). However, this still does not work if I boot normally, with whole French options.

CC: (none) => girlando
Hardware: i586 => x86_64

Confirmed reproducible on pre-final Gnome live DVD i586 (round 1) with virtualbox.

CC: (none) => yochenhsieh

Confirmed still present on real EFI hardware, Gnome Live x64 DVD, 1st Final ISO, choosing Boot Live from the boot menu.
But for me, only if booting from DVD. If booting from USB, it worked.

CC: (none) => lewyssmith

Tested 64 bit gnome Live on Virtual box. Initially, I get the screen, but with reduced dimensions, and I could not change it to full screen (black screen, no message). I tried to adjust some setting (PAE, video memory...) and I got the oh no ! message. Installed on virtual disk. Initially, after setting root and user passwd, I got a black screen. Then, as suggested in some messages, I shut off the machine, and this second time everything went well, no error message, the system works properly.

Curiously and inesplicably, I tried again to boot the live version, and this time everything went well. I also tried to reproduce the oh no! message by changing the virtual box setting, but this time whatever I made, it was OK.

Strange. Non reproducible bugs are the worst.

Regarding the inability of many AMD video cards to run gnome-shell, could there be any relationship to the breakage of hardware skinning by a recent update to the Catalyst driver? The newest 15.4 beta driver fixes that issue for Windows, but there is no mention of any plans to port that update to Linux.

Have the same with the Release Candidate (RC) Live-Gnome 32-Bit. The Live-KDE 32-Bit works.
Graficdriver error

wl              : Broadcom Corporation|BCM4311 802.11a/b/g [NETWORK_OTHER] (vendor:14e4 device:4312 subv:103c subd:1371) (rev: 02)
tg3             : Broadcom Corporation|NetLink BCM5906M Fast Ethernet PCI Express [NETWORK_ETHERNET] (vendor:14e4 device:1713 subv:103c subd:30c2) (rev: 02)
yenta_socket    : Ricoh Co Ltd|RL5c476 II [BRIDGE_CARDBUS] (vendor:1180 device:0476 subv:1000 subd:0000) (rev: b6)
Card:ATI Radeon HD 4870 and earlier: Advanced Micro Devices, Inc. [AMD/ATI]|RS690M [Radeon Xpress 1200/1250/1270] [DISPLAY_VGA] (vendor:1002 device:791f subv:103c subd:30c2)
k8temp          : Advanced Micro Devices, Inc. [AMD]|K8 [Athlon64/Opteron] Miscellaneous Control [BRIDGE_HOST] (vendor:1022 device:1103)
amd64_edac_mod  : Advanced Micro Devices, Inc. [AMD]|K8 [Athlon64/Opteron] DRAM Controller [BRIDGE_HOST] (vendor:1022 device:1102)
unknown         : Advanced Micro Devices, Inc. [AMD]|K8 [Athlon64/Opteron] Address Map [BRIDGE_HOST] (vendor:1022 device:1101)
unknown         : Advanced Micro Devices, Inc. [AMD]|K8 [Athlon64/Opteron] HyperTransport Technology Configuration [BRIDGE_HOST] (vendor:1022 device:1100)
unknown         : Advanced Micro Devices, Inc. [AMD/ATI]|SBx00 PCI to PCI Bridge [BRIDGE_PCI] (vendor:1002 device:4384)
unknown         : Advanced Micro Devices, Inc. [AMD/ATI]|SB600 PCI to LPC Bridge [BRIDGE_ISA] (vendor:1002 device:438d subv:103c subd:30c2)
snd_hda_intel   : Advanced Micro Devices, Inc. [AMD/ATI]|SBx00 Azalia (Intel HDA) [MULTIMEDIA_AUDIO_DEV] (vendor:1002 device:4383 subv:103c subd:30c2)
pata_atiixp     : Advanced Micro Devices, Inc. [AMD/ATI]|SB600 IDE [STORAGE_IDE] (vendor:1002 device:438c subv:103c subd:30c2)
i2c_piix4       : Advanced Micro Devices, Inc. [AMD/ATI]|SBx00 SMBus Controller [SERIAL_SMBUS] (vendor:1002 device:4385 subv:103c subd:30c2) (rev: 14)
ehci_pci        : Advanced Micro Devices, Inc. [AMD/ATI]|SB600 USB Controller (EHCI) [SERIAL_USB] (vendor:1002 device:4386 subv:103c subd:30c2)
ohci_pci        : Advanced Micro Devices, Inc. [AMD/ATI]|SB600 USB (OHCI4) [SERIAL_USB] (vendor:1002 device:438b subv:103c subd:30c2)
ohci_pci        : Advanced Micro Devices, Inc. [AMD/ATI]|SB600 USB (OHCI3) [SERIAL_USB] (vendor:1002 device:438a subv:103c subd:30c2)
ohci_pci        : Advanced Micro Devices, Inc. [AMD/ATI]|SB600 USB (OHCI2) [SERIAL_USB] (vendor:1002 device:4389 subv:103c subd:30c2)
ohci_pci        : Advanced Micro Devices, Inc. [AMD/ATI]|SB600 USB (OHCI1) [SERIAL_USB] (vendor:1002 device:4388 subv:103c subd:30c2)
ohci_pci        : Advanced Micro Devices, Inc. [AMD/ATI]|SB600 USB (OHCI0) [SERIAL_USB] (vendor:1002 device:4387 subv:103c subd:30c2)
unknown         : Advanced Micro Devices, Inc. [AMD/ATI]|SB600 Non-Raid-5 SATA [STORAGE_SATA] (vendor:1002 device:4380)
shpchp          : Advanced Micro Devices, Inc. [AMD/ATI]|RS690 PCI to PCI Bridge (PCI Express Port 2) [BRIDGE_PCI] (vendor:1002 device:7916)
shpchp          : Advanced Micro Devices, Inc. [AMD/ATI]|RS690 PCI to PCI Bridge (PCI Express Port 1) [BRIDGE_PCI] (vendor:1002 device:7915)
shpchp          : Advanced Micro Devices, Inc. [AMD/ATI]|Device 7914 [BRIDGE_PCI] (vendor:1002 device:7914)
shpchp          : Advanced Micro Devices, Inc. [AMD/ATI]|RS690 PCI to PCI Bridge (Internal gfx) [BRIDGE_PCI] (vendor:1002 device:7912)
unknown         : Advanced Micro Devices, Inc. [AMD/ATI]|RS690 Host Bridge [BRIDGE_HOST] (vendor:1002 device:7910 subv:103c subd:30c2)
hub             : Linux 3.19.8-desktop-1.mga5 ohci_hcd|OHCI PCI host controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0001)
hub             : Linux 3.19.8-desktop-1.mga5 ohci_hcd|OHCI PCI host controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0001)
hub             : Linux 3.19.8-desktop-1.mga5 ohci_hcd|OHCI PCI host controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0001)
hub             : Linux 3.19.8-desktop-1.mga5 ohci_hcd|OHCI PCI host controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0001)
hub             : Linux 3.19.8-desktop-1.mga5 ohci_hcd|OHCI PCI host controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0001)
btusb           : Broadcom Corp|HP Integrated Module [Wireless|Radio Frequency|Bluetooth] (vendor:03f0 device:171d)
hub             : Linux 3.19.8-desktop-1.mga5 ehci_hcd|EHCI Host Controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0002)

CC: (none) => linux

It shows Linux 3.19.8-desktop-1.mga5 because i used my insalled Mageia 5 for lspcidrake -v

@Thomas, Martin: Any idea of the last chance? Maybe a big hammer fix #2? :-)

Part of the problem is that there are several different bugs with the same "Oh no" end result. I've just done some testing with the QA pre-release 64-bit GNOME LiveDVD, and I'm seeing it occasionally fail  - maybe one in twenty boots (I'd never have noticed if it hadn't failed the first time I tried it!).

Looking in the journal from a failed attempt, the first abnormal message is

  systemd[1]: prefdm.service: main process exited, code=exited, status=1/FAILURE
  systemd[1]: Unit prefdm.service entered failed state.
  systemd[1]: prefdm.service failed.
  gdm-Xorg-:0[3004]: (EE)
  gdm-Xorg-:0[3004]: Fatal server error:
  gdm-Xorg-:0[3004]: (EE) Server is already active for display 0
  gdm-Xorg-:0[3004]: If this server is no longer running, remove /tmp/.X0-lock
  gdm-Xorg-:0[3004]: and start again.

following shortly after

  finish-install[1986]: calling ask_gnome_reboot

Looks like there is a race here, and gdm is trying to restart the server before it has finished shutting down.

Alan's problem is different. In his case GNOME (or more precisely, mutter) is calling an XRANDR function to set a display property, and fglrx doesn't support setting that property on all cards (it fails on Alan's hardware, but works on mine). In theory it should be possible to work round this by adding an X error trap around the offending XRANDR function call, but I couldn't get that to work (even on my hardware).

(In reply to Martin Whitaker from comment #83)
> Part of the problem is that there are several different bugs with the same
> "Oh no" end result. I've just done some testing with the QA pre-release
> 64-bit GNOME LiveDVD, and I'm seeing it occasionally fail  - maybe one in
> twenty boots (I'd never have noticed if it hadn't failed the first time I
> tried it!).
> 
> Looking in the journal from a failed attempt, the first abnormal message is
> 
>   systemd[1]: prefdm.service: main process exited, code=exited,
> status=1/FAILURE
>   systemd[1]: Unit prefdm.service entered failed state.
>   systemd[1]: prefdm.service failed.
>   gdm-Xorg-:0[3004]: (EE)
>   gdm-Xorg-:0[3004]: Fatal server error:
>   gdm-Xorg-:0[3004]: (EE) Server is already active for display 0
>   gdm-Xorg-:0[3004]: If this server is no longer running, remove
> /tmp/.X0-lock
>   gdm-Xorg-:0[3004]: and start again.
> 
> following shortly after
> 
>   finish-install[1986]: calling ask_gnome_reboot
> 
> Looks like there is a race here, and gdm is trying to restart the server
> before it has finished shutting down.

Likewise, I only noticed this because it occured on the first boot. My box uses a Nvidia870 graphics card and i7 - most of the above discussion centres around AMD.
The first instance caught me unaware. Next time I'll get a journal dump.

CC: (none) => vzawalin1

Created attachment 6558 [details]
Boot from usb of Gnome-live RC9

Luckily this bug appeared again on first boot. I selected the --all option so the dump is a bit verbose.

Despite the Nvidia graphics there are some messages relating to ATI related failures. Hope it's useful.

This is still from the RC.9 release, but 'a bird in the hand is worth two in the bush'.

I think Martin is right saying there is a timing problem (and that's why sometimes occurs, some other doesn't). Today tested LIVE gnome on another computer, 64 bit with AMD Radeon: I made several boots, all with the same conditions. In the normal boot (language: English, time: Italy, US keyboard) the usual Oh no ! message appears. Adding failsafe to kernel options, ending in maintenance screen, then typing "init 5" brings GNOME without errors.

I've clocked up 50 boots of the round 2 final GNOME Live DVD without seeing a failure. Given how infrequently I was seeing it fail, this is promising, but not conclusive.

maybe not blocker then.

CC: (none) => mageia

Well, that's for you guys to decide I guess. For now, the only workaround I can find is "switch to KDE".

(In reply to Nicolas Lécureuil from comment #89)
> maybe not blocker then.

I hit this again on a real EFI box with the latest Final Gnome Live DVD x64, booting from DVD, choosing Live from the boot menu. It happened after the initial configuration dialogues (keyboard). Twice successively.

But it did *not* happen booting to Live from USB. Nor when booting from DVD or USB and choosing Install.

I agree with Comment 90. Add "or use the Classic".

(In reply to Lewis Smith from comment #91)
> I hit this again on a real EFI box with the latest Final Gnome Live DVD x64,
> booting from DVD, choosing Live from the boot menu. It happened after the
> initial configuration dialogues (keyboard). Twice successively.
> 
Lewis, on a failing boot, can you check the journal to see if you get the messages I list in comment 83 - particularly

  gdm-Xorg-:0[3004]: (EE) Server is already active for display 0

coming shortly after

  finish-install[1986]: calling ask_gnome_reboot

This will indicate whether you are seeing the "timing race" bug or something different.

> I agree with Comment 90. Add "or use the Classic".

Unfortunately Alan is being hit by a different bug, which affects installed systems as well. If I had the right hardware, I might be able to figure out a workaround.

Created attachment 6591 [details]
Journal of latest Gnome Live booted from DVD ending "Oh no!"

In response to Comment 92, the entire Journal of the Live boot to failure. Real EFI hardware with AMD/ATI/Radeon video. Used # journalctl from a virtual console to a local file, copied that to USB.
It shows the second msg in that comment, but that is not followed by the first. Thought it better to upload the whole journal than risk to prune it; sorry.
This failure was the 3rd successive; but it did *not* happen booting to Live from USB, which worked.

Mai 20 10:40:26 localhost gdm-Xorg-:0[1519]: (EE) AIGLX error: dlopen of /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: undefined symbol: _glapi_tls_Dispatch)
Mai 20 10:40:26 localhost gdm-Xorg-:0[1519]: (EE) AIGLX: reverting to software rendering

(In reply to claire robinson from comment #94)
> Mai 20 10:40:26 localhost gdm-Xorg-:0[1519]: (EE) AIGLX error: dlopen of
> /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: undefined
> symbol: _glapi_tls_Dispatch)
> Mai 20 10:40:26 localhost gdm-Xorg-:0[1519]: (EE) AIGLX: reverting to
> software rendering

Again this makes me suspicious that we're looking at the "hardware skinning" functions that were broken by a recent release of the AMD Catalyst driver.

AMD's 15.4 beta driver restores those functions for Windows, but there is no word of any plans to port that fix to Linux. I'd like to think that would be a no-brainer, but AMD's support for Linux is so bad that many distributions appear to be admitting defeat.

An application called Singularity (a viewer for Second Life) has a new patch that actually re-enables hardware skinning, for that application anyway. Tested and confirmed for myself that it works. Would it be possible to learn anything useful from that patch? I can try to contact them.

(In reply to Alan Augustson from comment #95)
> Again this makes me suspicious that we're looking at the "hardware skinning"
> functions that were broken by a recent release of the AMD Catalyst driver.
> 
No, because the failure Lewis is reporting comes from the free radeon driver, not fglrx.

(In reply to claire robinson from comment #94)
> Mai 20 10:40:26 localhost gdm-Xorg-:0[1519]: (EE) AIGLX error: dlopen of
> /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: undefined
> symbol: _glapi_tls_Dispatch)
> Mai 20 10:40:26 localhost gdm-Xorg-:0[1519]: (EE) AIGLX: reverting to
> software rendering

So this is not the timing race bug. The radeon driver is failing to load one of the modules needed for hardware 3D acceleration, so falls back to software acceleration. GNOME checks for this, and won't start without hardware acceleration (the old fallback mode has been removed).

The puzzling thing here is this is working from a USB stick but failing from DVD. I can't think of a mechanism that would cause this (other than a bad burn). I'll try this myself tomorrow - all my tests so far have been from a USB stick.

I can confirm Lewis's findings. The GNOME 64-bit Live DVD ISO, when dd'd to a USB stick and booted via UEFI, boots to the GNOME desktop without problems on my machine with Radeon HD 7850 graphics. The same ISO, burned to a DVD, boots to the "Oh No" screen, with the same error messages in the journal (see Claire's comment 94).

Created attachment 6622 [details]
Journal from Final round 4 Live Gnome x64 DVD

STILL the error running from DVD at least, chosing 'Live' from the boot menu.
Full journal attached.
No time yet to try from USB.

(In reply to Lewis Smith from comment #98)
> STILL the error running from DVD at least, chosing 'Live' from the boot menu.
> Full journal attached.

The journal shows the same failure to load /usr/lib64/dri/r600_dri.so, causing the X server to fall back to software rendering.

Unfortunately my tests running from USB stick show the "timing race" bug

  (EE) Server is already active for display 0

is back with the round 4 DVD.

So we still have three separate bugs.

Could we try to split this clone this bug into three separate bug reports with a proper summary then, and close this one as RESOLVED MOVED?
It will be hard to follow the resolution of all three bugs in this already too long bug report IMO.

Ok, the three bugs identified by Martin have now been splitted. Please make sure that you comment further in the bug that corresponds to your issue:
- This bug report (bug 15653) is meant to track Alan's issue, as best described in comment 84.
- The "timing race" bug described in comment 83 should now be worked on in bug 16032.
- The "GNOME fails from DVD, not from USB" bug (Lewis' bug) described in comment 96 should now be worked on in bug 16033.

I don't think that we can realistically fix this issue right now, it looks like GNOME 3.14 is just *not compatible at all* with this hardware and the proprietary driver.

We'll have to document this in the Errata, and hopefully a fix can be found after the release to make GNOME usable by users of such hardware (even though we won't be able to fix the GNOME Live media).

Priority: release_blocker => High
Whiteboard: (none) => FOR_ERRATA

I'd like to re-test this bug once the new AMD Catalyst Driver 15.5 is packaged for Mageia. I don't seem to be able to install the generic.

Where may I request this package upgrade?

Well, 15.5 is only a beta released for SLES 12 with not much changes besides:

New Features
        Support for SUSE® Linux Enterprise Desktop 12

Resolved Issues
        [417630]: Fixes the issue of discrete GPU not being powered off in Power-Saving mode on some PowerXpress AMD GPU + AMD APU platforms
        [416499]: Fixes minor screen corruption when resuming from S3 caused by display hot plugging

Known Issues
        [419960]: Vari-Bright on some configurations is not decreasing brightness as expected



even the earlier ubuntu beta driver has more changes...

That driver may be a what salvages my ability to run the applications I need on M5. As things currently stand I'm back to using Windows full-time, after a years-long relationship with Mageia.

I'm still unable to write M5 to a USB stick using usbdumper for Windows. Keep getting a message that the ISO is not "hybrid". I'm sure I'm doing something wrong, as no one else appears to have complained. And no, I cannot use isodumper. My Linux partition needs a clean install.

(In reply to Alan Augustson from comment #105)
> That driver may be a what salvages my ability to run the applications I need
> on M5. As things currently stand I'm back to using Windows full-time, after
> a years-long relationship with Mageia.

There is now the new official fglrx / Catalyst 15.7 in nonfree updates testing that you can try

I enabled nonfree updates testing, and I see only 14.5 and 15.2.

Yeah,. Amd keeps playing with the versioning....


the Catalyst 15.7 has version number: 15.200.1046

Is this bug still valid in latest cauldron?

Keywords: (none) => NEEDINFO

(In reply to Samuel Verschelde from comment #110)
> Is this bug still valid in latest cauldron?

As fglrx is not compatible with the latest X.org server (and as I understand, never will be), I think we can say no.

Can you try a fix from #19956 whether that will help also for this problem?

The fix is basically to patch a mutter with couple of patches released after the 3.22.2 version. It was a common problem on fedora users and I had same problem on Mageia with intel drivers.

CC: (none) => lamikr

fglrx has been replaced by amdgpu, so this bug is no longer relevant.

Status: REOPENED => RESOLVED
Resolution: (none) => OLD