On Wed, Nov 5, 2014 at 6:36 PM, Konstantin Olchanski <[log in to unmask]> wrote:
> A few days ago an updated linux kernel and updated xorg packages were
> pushed into the SL6 updates. These updates are automatically installed
> by the default yum configuration of SL6.5.
>
> Unfortunately these updates are incompatible with pre-installed X11 video
> drivers for NVIDIA (GeForce 210) and AMD/ATI (AMD E-350/E-450 and socket AM1
> on-board video) from ELREPO.

Then you really need to talk to ELREPO, not Scientific Linux which is
doing rebuilds from RHEL which are aimed at production servers.
Support of non-frreware and non-opensource drivers for NVidia.

If what you need is the latest graphics drives, you need to hop to SL
7 or consider a non-server-based OS.


> These are the ELREPO kmod-fglrx and kmod-nvidia packages.
>
> So all computers with these video cards promptly broke.

This seems unlikely. I can easily believe that sophisticated graphics
drivers broke, but services such as SSH, httpd, and NFS are probably
rock stable even with ELREPO enabled.

> This incompatibility seems to be well known to the perpetrators (X.org API change, leading to crash of Xorg).
>
> I think such a disruptive update should have been announced a little
> bit more widely and maybe some technical solution could have been implemented
> to avoid breaking X11 outright (i.e. refuse to install new X.org packages
> if known-incompatible NVIDIA or AMD/ATI drivers are loaded).

That gets difficult. It's a nightmare for our favorite upstream vendor
to try to stay compatible with all bleeding edge 3rd-party
repositories, with software that is not open source and published as
binary blobs by NVidia.

Let me offer a suggestion that may help for production environments.
Use something like "rsnapshot" to make locked copies of an rsync
mirror of Scientific Linux, and ensure that your local yum setup is
aimed at a locked down version of the local repo whose contents have
been evaluated. It takes thought and a configuraiton management tools
like cfengine or puppet or chef, but it can be done.

> It looks like corrected drivers are available from ELREPO, but automatic updates
> from ELREPO are normally disabled because they break themselves (newly installed
> package fails to reload the old kernel module resulting in Xorg not starting
> because of mismatch between newly installed userland drivers and old kernel module).

See above. "Talk to ELREPO". An if you need that kind of support for
your particular 3rdparty requirements, I can recommend some people who
can do that sort of work. They're not cheap.. I used to do that sort
of thing for Akamai more than a decade ago, it takes thought and work.

Now, if you'd like some friendly suggestions about how to keep that
sort of thing resolved, I just offered a few.


> As end result, what could have been planned scheduled maintenance is now an emergency
> "patch Wednesday" with many computers requiring reboot and many end users disturbed.
>
> I have to fix about 6 computers with AMD/ATI drivers and only (what?) 20 computers with NVIDIA drivers.
>
> Please have a nice day.
>
>
> P.S. To add injury to insult, the super advanced Red Hat kernel module management
> system (dracut) does the super slow (bzip2 -9) rebuilt of initramfs not once,
> but twice - once on install of new driver and second time on removal of old driver.
> What should have taken 5 seconds takes a good 2-3 minutes (/usr/bin/time yum update kmod-nvidia).

I'm afraid you may have to just get over this one. Compressing
initramfs with maximum compression is a legacy, and a reasonable one,
of supporting systems with extremely limited RAM, and leaving as much
as possible for other applications.