From an other bug report I learned I could use
"xdriver=fbdev" was it fbcon? I don't think so.

So I used Boot Live, F6, but it passed to Install mode.
Somehow I escaped to return to Boot Live and replaced "quiet splash" by "xdriver=fbdev".
Now I realized I could/should have try "xdriver=vesa".

Got same "Oh no! Something has gone wrong"

So with fbdev driver I got:
re-discovered: "journalctl" to see the logs:

AIGLX Error: dlopen of /usr/lib64/dri/swrast_dri.so failed to load ...
undefined symbol: _glapi_tls_Dispatch
Could not load software renderer

O.k. I removed the "xdriver=fbdev" on kernel options, to figure out what was the problem and it is mostly the same as previous post:

/usr/lib64/dri/r600_dri.so failed to load:
undefined symbol _glapi_tls_Dispatch

Googling it I found some possible infos:

http://www.mesa3d.org/dispatch.html
section 3.2

https://www.libreoffice.org/bugzilla/show_bug.cgi?id=73778
"It sounds like either the drivers or libGL wasn't built with --enable-glx-tls."

https://lists.debian.org/debian-x/2014/07/msg00431.html suggests to use:
# readelf -Ws /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so |grep _glapi

What about ldd /usr/lib/i386-linux-gnu/libglapi.so.0?

$ nm -D /usr/lib/libGL.so | grep glapi

well yes, on my cauldron x86-64 system I have a reference to _glapi_tls_Dispatch in /usr/lib64/libGL.so.1 and this reference gets resolved (by libglapi.so.0 I would think), so modules loaded from ~libGL also have access to that symbol. And indeed the r600 driver was loaded and neverball worked earlier.

In what package is your /usr/lib64/libGL.so.1 ?

$ rpm -qf /usr/lib64/libGL.so.1
lib64mesagl1-10.3.2-2.mga5.tainted

CC: (none) => cjw

I'll try to answer your question, but first I'd like to note that
xdriver=vesa did give me the same "Oh no! Something have gone wrong".
Reading log suggest that it could either be because no 3D acceleration was found, which seems normal or ... 
Could not register with accessibility bus ...

Some suggested when seems in applications (rather than in this case Xorg):
export NO_AT_BRIDGE=1 in /etc/environment

$rpm -qf /usr/lib64/libGL.so.1
lib64mesagl1-10.3.2-2.mga5
So the diff with you is that mine is not tainted.

Well, when I did first read tls in --enable-glx-tls I first thought about tls as Transport Layer Security. Maybe someone have made the same error than me and have think that using --enable-glx-tls would taint OpenGL in using some encryption???

But reading http://www.mesa3d.org/dispatch.html I now realize that TLS here is Thread Local Storage.

Don't know, that's a wild guess.

Anyway, it looks a bit like if OpenGL was compiled without GLX using TLS.
And lib64_dri_drivers-10.3.2-2.mga5 would have been compile to use TLS.

To be frankly, I don't know too much about programming... I might very well be very wrong.

My wild guess is that there is a mix-up with (e.g.) fglrx so swrast_dri.so is using a different libGL.so.1 and that's why it doesn't work.

I just switched to non-tainted (core) version of libGL.so.1 and it looks the same - OK. BTW you did not list the dynamic symbols of /usr/lib64/libGL.so.1 (using nm -D) ?

Well, each time I boot the DVD, type commands, write the results on paper, reboot in my OS, and go here to give results... so don't expect me to give you all the symbols in libGL.so.1.

Also I am not an expert, I really needed you to tell me to sue nm -D
so all functions in _glapi_ was U(ndefined).

In particular, readelf shows me that contrary to other symbols beginning by
_glapi_ _glapi_tls_dispatch is not of type function, but of type TLS.

I see in some web pages that it should be defined in libglapi.

Finally realised that a USB key does better than a pencil and a paper.

I have ldd -r .../r600.dri.so 
	linux-vdso.so.1 (0x00007fff213fe000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f91ea956000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f91ea752000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f91ea527000)
	libdrm.so.2 => /lib64/libdrm.so.2 (0x00007f91ea31b000)
	libdrm_nouveau.so.2 => /lib64/libdrm_nouveau.so.2 (0x00007f91ea114000)
	libelf.so.1 => /lib64/libelf.so.1 (0x00007f91e9efd000)
	libdrm_radeon.so.1 => /lib64/libdrm_radeon.so.1 (0x00007f91e9cf0000)
	libLLVM-3.5.so => /lib64/libLLVM-3.5.so (0x00007f91e8748000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f91e843b000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f91e8135000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f91e7d83000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f91e7b6b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f91eb723000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f91e7941000)
undefined symbol: _glapi_tls_Dispatch	(/usr/lib64/dri/r600_dri.so)
undefined symbol: _glapi_tls_Context	(/usr/lib64/dri/r600_dri.so)
undefined symbol: _glapi_set_dispatch	(/usr/lib64/dri/r600_dri.so)
undefined symbol: _glapi_check_multithread	(/usr/lib64/dri/r600_dri.so)
undefined symbol: _glapi_set_context	(/usr/lib64/dri/r600_dri.so)
undefined symbol: _glapi_add_dispatch	(/usr/lib64/dri/r600_dri.so)
undefined symbol: _glapi_get_proc_address	(/usr/lib64/dri/r600_dri.so)
undefined symbol: _glapi_get_dispatch_table_size	(/usr/lib64/dri/r600_dri.so)
undefined symbol: _glapi_get_context	(/usr/lib64/dri/r600_dri.so)

it does not seems to need libGL.so (which indeed seems to need libglapi) and I have seen that _glapi_tls_Dispatch is defined in libglapi.

I guess it works for Christiaan because he have the tainted version of r600 driver. Would like to know how ldd -r differs however.

I have exactly the same. It works because this is not a normal shared library but a loadable module. Whatever loads it must provide these symbols.

Can you post your /var/log/Xorg.0.log as attachment?

You have /var/log/Xorg.0.log?
When I searched for it previously, I did not found it.
So I suspected that it was because it use systemd, and that's where I began to use journalctl. Inside I see what would be in /var/log/Xorg.0.log but I guess there some unit I need to filter it.

Created attachment 5596 [details]
journalctl after Oh no!

Similar problem: http://forums.opensuse.org/showthread.php/500911-recent-update-breaks-Mesa
Seems to be linked to fglrx being installed:
"According to that error message, you seem to have at least parts of the fglrx driver (libglx probably) still installed. This breaks the Mesa drivers, in your case r600g _and_ the software renderer swrast.
So how did you install fglrx in the first place? How did you uninstall it?"

(we have certainly duplicate bugs...)

CC: sysadmin-bugs => olav
Component: Release (media or process) => RPM Packages

I was beginning to think that this was only a GNOME problem.
So I downloaded Mageia5 beta 1, KDE4, this time 32 bits (was using 64 bits GNOME).
And it does works fine, as I am writing this with it.

A bit strangely to me, journalctl is almost empty, almost as if it was resetted.
In it I see:
W: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupporte

Which seems to suggest that maybe it run without D-BUS...
Think I have read Accessibility bus could be an other name for D-BUS.
So I began to think if it is not why GNOME refuse to start now...

The r600 symbol not found is still here in KDE.
I now have a /var/log/Xorg.0.log file and in it:
[   181.270] (EE) AIGLX error: dlopen of /usr/lib/dri/r600_dri.so failed (/usr/lib/dri/r600_dri.so: undefined symbol: _glapi_tls_Dispatch)
[   181.270] (EE) AIGLX: reverting to software rendering
[   181.277] (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
[   181.277] (EE) GLX: could not load software renderer
[   181.277] (II) GLX: no usable GL providers found for screen 0

I also note in this file, before previous one:
[   175.574] (EE) systemd-logind: failed to get session: PID 1577 does not belong to any known session

Maybe I will try to download the (still live) Gnome version, but in 32 bits, which I could test on at least an other computer.

D-Bus seems to run in KDE:

[live@localhost log]$ systemctl |grep dbus
  dbus.service                                                                                          loaded active running   D-Bus System Message Bus
  dbus.socket                                                                                           loaded active running   D-Bus System Message Bus Socket
[live@localhost log]$

gnome-shell uses OpenGL so if something is wrong with the OpenGL configuration, GNOME fails completely (in my test in a VM it managed to use software rendering, however). KDE still works on a plain X11 display.

Hi! I tested with the KDE live DVD and I see the same or at least a very similar error message. What should fix it for me was a simple:

  ldconfig

(as root). The nvidia binary driver GL configuration was cached in /etc/ld.so.cache while the real config in /etc/ld.so.conf and /etc/ld.so.conf.d/*.conf was good.

I checked with
  ldd /usr/lib64/xorg/modules/drivers/radeon_drv.so
which should have an entry for /lib64/libGL.so.1, not any other libGL.so.1 .

So maybe the fix is to run ldconfig after GL libraries are automatically configured (I don't know anything about that)...

I didn't manage to restart X (screen kept flashing).

Thanks! I am now running the LiveDVD Mageia5 beta 1!
So the workaround was...
-Run until the screen "Oh no! Something have gone wrong." appears
-Ctrl-Alt F2          # to switch to console mode
-root [enter]         # to login as root
#systemctl isolate multi-user.target
#ldconfig
#systemctl isolate graphical.target
There, Gnome started!

I'd like to note that I have tried on an other computer today, and seen that the i915 driver was also affected by this: undefined symbol _glapi_tls_Dispatch too.

But I am a bit confused as how the problem have happens.
The package manager should run ldconfig after installing packages but did not?

rpm -qf /etc/ld.so.cache say that it come from 
glibc-2.20-11.mga5

and rpm -qi glibc tell me that:
"This package now also provides ldconfig which was package seperately in
the past. Ldconfig is a basic system program which determines run-time
link bindings between ld.so and shared libraries."

I wish to reinstall glibc to test if it cause the problem but I was not able:
[root@localhost ovlsize]# rpm --reinstall glibc
error: open of glibc failed: No such file or directory

But I do suspect that glibc should not package /etc/ld.so.cache, that it should be generated by running ldconfig.

The problem persists in beta3 ! And once using the workaround  described here, I cannot logout to start again. So I cannot make tests. I cannot help (I am not an expert) but I strongly believe this problem should be fixed as soon as possible, at least for the release candidate. Otherwise you cannot have the support of the community (ot at least of those like me) for the testing.

CC: (none) => girlando

Colin: Any ideas?

CC: (none) => mageia
Summary: #ldconfig fix "Oh no! Something has gone wrong" in GNOME and fix 3D accelaration in Gnome and KDE Mageia5 Beta 1 Live CD or DVD => Outdated ldconfig cache resulting in "Oh no! Something has gone wrong" in GNOME

(In reply to Olav Vitters from comment #22)
> Colin: Any ideas?

Well, I suspect the ldconfig thing might be a bit of a red herring. Certainly it should be done after changing the glconf alternative (via update-alternatives) and indeed this should happen at package installation time (it's a filetrigger). I'm not sure if there is code to run it after changing it in the GUI however (if not, there should be).

So, e.g. when switching to the nvidia prop. driver, it should certainly be run (and if it's not I'd say that's a bug).



However, I'm not sure this is the same issue as:

(In reply to Paul Dufresne from comment #19)
> Thanks! I am now running the LiveDVD Mageia5 beta 1!
> So the workaround was...
> -Run until the screen "Oh no! Something have gone wrong." appears
> -Ctrl-Alt F2          # to switch to console mode
> -root [enter]         # to login as root
> #systemctl isolate multi-user.target
> #ldconfig
> #systemctl isolate graphical.target
> There, Gnome started!

This is certainly strange... For me this problem seemed somewhat intermittent, sometimes GNOME would start fine, other times it would get this error (due to the dlopen/symbol missing problem). I do not see how, in this case, running ldconfig should fix anything. I'd expect a simple "systemctl restart display-manager" would do also (at least in some cases) "solve" the problem. Annoyingly, I cannot reproduce the problem here for now with my i586 VM (I know it will be reproducible tho', - I've seen it plenty of times - x86_64 seemed to do it all the time, so I will look at this when I get home with this version)

(In reply to Paul Dufresne from comment #20)
> rpm -qf /etc/ld.so.cache say that it come from 
> glibc-2.20-11.mga5

> 
> But I do suspect that glibc should not package /etc/ld.so.cache, that it
> should be generated by running ldconfig.

It does not, it only carries a %ghost reference to it

Sorry but, i write a commnt to the bugs #15248, without know this bug file, I download the MG5beta3 yesterday, and I tested in two machines real hardware, one with intel integrated compaq presario and one H61 chipset integrated, this comment is the https://bugs.mageia.org/show_bug.cgi?id=15248#c3 Xorg journal section If need more tests ask me in an email

Thanks

CC: (none) => neoser10

*** Bug 15248 has been marked as a duplicate of this bug. ***

CC: (none) => wilcal.int

*** Bug 14033 has been marked as a duplicate of this bug. ***

CC: (none) => 231036448

While 00-ldconfig.filter does include /etc/ld.so.conf.d/*.conf, if the package isn't actually installing GL.conf but is merely changing it as a symlink via update-alternatives, that will not trigger the filetrigger.  Any package that calls update-alternatives for GL.conf needs to explicitly run ldconfig -X.

It looks like our packages do list /etc/ld.so.conf.d/GL.conf as a %ghost file, but I don't think that's sufficient to trigger the filetrigger.

If the %ghost is triggering it, then it could be as Colin said, that maybe it's just drakx11 that needs to explicitly run ldconfig -X when changing video drivers that need to change the GL.conf link.

All nonfree drivers calls ldconfig -X in %post(un) to cope with the alternatives.

but all drivers are installed on a live iso during iso build

(In reply to Thomas Backlund from comment #30)
> but all drivers are installed on a live iso during iso build

Does that mean that the %post(un) scripts are not called since the drivers are already installed, hence the ldconfig cache might stay outdated?
Would there be an easy (or better, clean) way of enforcing ldconfig -X when switching drivers, regardless of whether they are installed already or not?

Reporter please can we have a status on that one? It should be fixed in last isos

CC: (none) => ennael1

Sigh: Short answer, Beta3 still show the problem.
Longer answer: My downloaded file is Mageia-5-beta3-LiveDVD-GNOME-x86_64-DVD, but it reacts like an installation DVD, was in installer before having the possibility to test live. 

Now that I think about it, maybe there was (install and test options in Grub, but I am used to be asked later if I want to test or install).

Auto-allocate, did resize my Windows, and tried to allocate, 3GB but it knows it need 6? 9? ... anyway I manualy did give it 15 GB for /

Was not finding french-canada for keyboard, so took the french option (I did suppose it was french-canada, that it combined with previous info, but no, was in french (Azerty) keyboard, and had to type my root password without seeing it in Azerty rather than Qwerty.

When I booted my installed system, it finaly shown the Oh, no! message. But the window with release notes, wiki, forums, was there, but the cursor was not.

I managed to open forums (in browser), and be able to go to the address bar, but seeing the AZERTY keyboard, I cannot change again, I give up and closed computer to reboot computer in Windows where I am writing this long complain where it does not belong.

Ok, this is not so simple: fixed in Live DVD mode (well I am writing this from it).

First, I tried to boot in safe-mode on my installed system, but it stop at 16 sec, after radeon initializing on minor 0 message, after that at 64 secs, random said it had done something... but then nothing more until screen became black after waiting too long.

Then retried my USB key.
I discovered my mistake of booting install mode is the F6 options glitch: when you are on first Boot Live DVD, and press F6, you are push to second line Install mode, I did not look enough and just removed quiet and splash, then booted install mode.

This time in Live mode, I choose America/Canada (Eastern) timezone, rather than EST5EDT. And then after, I did have Canadien(Québec) for the keyboard, so that my keyboard is fine.

And then Gnome 3 Desktop did happens fine, which seems like partial fix for this bug.

But remember that installed system did give me the "Oh no message!".

I might retry this again, to see if it is transient problem, or if it works always flawlessly in Live mode.

Tried Live 3 times in a row without problem.

To my surprise installed version also works 3 times in a row
so that seems to be only first time had the message

Problem I did not select the Canada keyboard this time ::: changed in drakonf; close session reenter it; drakonf remembered Canada but my keyb still french ::: I expect reboot computer will fix it::: but should have already changed

Even after reboot; drakconf shows Canada quebec; but still have french keyb::: need to search this to see if already reported

Sorry question was for QA team as they have already RC isos with some more fixes inside

Fixed in last isos

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