[elrepo-devel] We have fglrx packages and X does not behave. How to proceed ?

[Phil Perry]

On 23/12/15 12:48, Manuel Wolfshant wrote:

Hi Wolfy,

> Hello
> 
>     As some of you already know, for sometime I am the maintainer of the
> fglrx (AMD video drivers ) packages.
>     Things look fine on EL6 ( at least I have not heard about any
> complains ) but on EL7 there is a problem which seems to occur more or
> less randomly. I for one was not able to identify the pattern triggering
> it ( and to make things worse, I still do not have an actual EL7 system
> to test with my own set of hands and eyes ).  To cut a long story short,
> despite the presence of a file named /etc/X11/xorg.conf.d/20-fglrx.conf
> which contains
>     Section "Files"
>         ModulePath   "/usr/lib64/xorg/modules/extensions/fglrx"
>         ModulePath   "/usr/lib64/xorg/modules"
>     EndSection
> Xorg randomly decides to load
> /usr/lib64/xorg/modules/extensions/libglx.so rather than
> /usr/lib64/xorg/modules/extensions/fglrx/libglx.so . This leads to:
> [    38.173] (II) "glx" will be loaded by default.
> [    38.173] (II) LoadModule: "glx"
> [    38.174] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
> which later on leads to a SIG11 given that the fglrx.so hates stock
> libglx.so
> 

If this were an Xorg bug then you'd expect the same (or similar)
behaviour with the nvidia driver, which potentially has the exact same
issue?

I install /etc/X11/xorg.conf.d/99-nvidia.conf:

Section "Files"
	ModulePath   "/usr/lib64/xorg/modules/extensions/nvidia"
	ModulePath   "/usr/lib64/xorg/modules"
EndSection

so the only difference there being the numbering, 99-nvidia.conf vs
20-fglrx.conf

For what it's worth I have never seen this issue with the nvidia driver.
If you do think you have a reproducer then I have real (nvidia) hardware
and could certainly test.


>     Now, the obvious solution would be the one originally implemented by
> AMD (and disabled in elrepo packages ): renaming the stock libglx.so to
> something else when the package is installed and restoring it at removal
> time. However this leads the system prone to issues if/when
> xorg-x11-server-Xorg is updated given that the file will get recreated.
> 
>     Therefore I come to you with this question: beside trying to file a
> bug against RHEL/xorg  and asking for their help in identifying the
> reason why the behaviour of X is erratic, what can I ( emphasize on I )
> can do to make the users of the fglrx packages on EL7 happier  ? I've
> never used it before in my 9 years of packaging but I wonder if
> something along
> 
>             %triggerin  -- xorg-x11-server-Xorg
>                     mv /usr/lib64/xorg/modules/extensions/libglx.so
> /usr/lib64/xorg/modules/extensions/libglx.so.elrepo
> 
> (and the corresponding %triggerun to restore the file ) would be fine
> for this case.
> 
>     Thoughts, anyone ?
> 

This is exactly the type of case you would use %triggerin and I would
expect it to work as described. It's not ideal (IMHO) and almost a last
resort, but if it's the kind of brute force approach required to get it
to work then feel free to use it.

Refining a little:

%triggerin -- xorg-x11-server-Xorg
[ -f %{_libdir}/xorg/modules/extensions/libglx.so ] && \
  mv %{_libdir}/xorg/modules/extensions/libglx.so \\
  %{_libdir}/xorg/modules/extensions/libglx.so.elrepo &>/dev/null



I wouldn't worry about using %triggerun - if a user is uninstalling Xorg
then you don't need to worry about it, but you *would* need to restore
the file upon uninstalling the fglrx package(s) in either %preun or
%postun. But I'm guessing that's probably what you meant :-)


As a point of note, the nvidia packages I inherited from rpmforge when
we first started elrepo used a %triggerin script as apparently
xorg-x11-server-Xorg had a tendency to empty the "Files" section of
xorg.conf so it needed to be recreated each time. It's still there in
the current el5 driver:

https://github.com/elrepo/packages/blob/master/nvidia-x11-drv/el5/nvidia-x11-drv.spec

but got removed when I ported the package to el6 upon it's release. I
have no idea if it's still needed, it's been there over 6 years and does
no harm.

Phil