Moderate Rant Un Updates

Home » CentOS » Moderate Rant Un Updates
CentOS 32 Comments

So, another admin I work with rolled out most (but not kernel) updates to
6.4… but including xorg. I log out the end of the day, and I’m hosed –
no X.

Now, my not-two-year-old workstation has an nvidia card, and I’d installed kmod-nvidia from elrepo. I figured I’d fix my problem by finishing the upgrade and rebooting.

Nope.

I try to upgrade kmod-nvidia from elrepo. Anyone got any good explanations as to why they’d put kmod-nvidia-310.40 in the repo, with the previous version not obvious… AND NOT HAVE THE *REQUIRED* nvidia-x11-drv-310.40
in there? Why not wait until both pieces could be uploaded, since kmod-nividia WILL NOT INSTALL without the other…?

I then stupidly uninstalled the previous kmod-nvidia & nvidia-x11-drv, hoping it would allow a good install.

Nope.

Found the proprietary installer on the NVidia site, and I’m up.

On a related note, does anyone have a link to a howto build the NVidia proprietary driver on a kernel that’s *not* running, so we could prebuild it before the reboot? I see there are options in the script, but no examples.

Also, is dkms coming in, or deprecated?

mark

32 thoughts on - Moderate Rant Un Updates

  • Which card?

    You may need the legacy version; this is clearly documented on the
    current elrepo wiki pages about their nvidia modules.

    If you do, you need to:

    yum install nvidia-x11-drv-304xx

    and all should be good.

    Unnecessary. You need the elrepo nvidia version detector to see if
    you need the 304 legacy driver.

    Deprecated. The elrepo kmod works fine on any EL6 kernel thus far;
    my laptop, which needs the 304 legacy driver, updated to CentOS 6.4
    just fine, before any elrepo updates.

  • None of those modules are in CentOS, but a 3rd party repo.

    How about you test your setup and how 3rd party repos interact with it
    … THEN ask on the 3rd party repo’s own mailing list how or why their packages no longer work with the update?

  • Sorry, clicked “send” too soon.

    Am 14.03.2013 15:37, schrieb Tilman Schmidt:

    That was from a kernel install script that had previously set
    ${KERNELRELEASE} to the name of the module directory and
    ${NVDRV} to the base name of the nVidia installer. So the actual command would look something like this:

    ~/Download/NVIDIA-Linux-x86_64-270.41.06.run -sKk 2.6.37.6-24-desktop

    HTH
    T.

  • Lamar Owen wrote:
    I’m

    GF100GL/Quadro 4000
    the previous

    Nope, it does *not* use the legacy version.

    Ah, thanks on the dkms. So I’m back to figuring out a script to automagically build the driver when the user’s workstation reboots (and make sure it prints out a warm fuzzy so they don’t worry while it does it).

    mark

  • Tilman Schmidt wrote:

    It does, indeed. Thanks a lot, Tillman, that’s what I needed (I’ll check to make sure it doesn’t replace xorg.conf – a lot of us need the proprietary driver because we use two monitors, and *bleah* nouveau doesn’t support twinview).

    mark

  • Johnny Hughes wrote:
    hosed –

    That’s fine. I found it annoying, but was trying to figure out whether to set that up with the proprietary driver or not. Thanks.

    I’d Have Been Glad To Test First… but read the first para, above….

    Actually, also, I note that this does *not* happen with CentOS base; I
    just can’t imagine why someone would do something that stupid as elrepo seems to have.

    mark

  • Akemi Yagi wrote:
    I sure did. Last time we looked, a few years ago, it did not. When I have time, and a system to try it on (I’d really rather not disable my system for a couple hours while I play with it), I’ll look into it.

    Thanks, Akemi.

    mark

  • We (elrepo) didn’t. Both components were pushed together, I can assure you. Both packages were signed and pushed on 9th March, some 5 days ago.

    Can you please provide evidence to support your claims. Please provide a link to the mirror with the missing file then we can investigate and fix IF there is indeed an issue.

    Don’t get me wrong – I take reports of issues very seriously. But in this case you make accusations without any evidence to support them. You don’t seem interested in requesting or receiving support, but rather just want to have a rant, evidenced in part by the title of your thread and the fact you have yet to provide any useful details that would actually help someone determine what your issue is and how to best fix it. And as Johnny pointed out, this isn’t even the correct forum for your rant.

    Anyway, I am glad to see elsewhere in this thread that you no longer intend to use the elrepo NVIDIA packages. I am glad you have found a solution that works for you and wish you good luck with that.

  • Ned Slider wrote:

    yum install kmod-nvidia nvidia-x11-drv –disablerepo=\* –enablerepo=elrepo Loaded plugins: fastestmirror, presto, ps, security Loading mirror speeds from cached hostfile
    * elrepo: mirror.symnds.com Setting up Install Process No package nvidia-x11-drv available. Resolving Dependencies
    –> Running transaction check
    —> Package kmod-nvidia.x86_64 0:310.40-1.el6.elrepo will be installed
    –> Processing Dependency: nvidia-x11-drv = 310.40 for package:
    kmod-nvidia-310.40-1.el6.elrepo.x86_64
    –> Finished Dependency Resolution Error: Package: kmod-nvidia-310.40-1.el6.elrepo.x86_64 (elrepo)
    Requires: nvidia-x11-drv = 310.40
    You could try using –skip-broken to work around the problem You could try running: rpm -Va –nofiles –nodigest

    Obviously, you didn’t read it closely. I found a solution to get me back to work. I strongly preferred the kmod-nvidia, since it does not require me to manually build the drivers every time I upgrade the kernel, and I
    have a number of users I support with similar issues.

    mark

  • This may be slightly off topic on this thread but on all my workstations using the Nvidia kmod from elrepo, the update to xorg removed the symbolic link ‘libglx.so in /usr/lib64/xorg/modules/extensions/nvidia that points to nvidia’s libglx.so.304.64. Restoring that symbolic link restored normal operation. Perhaps a

    ‘yum –enablerepo=elrepo reinstall kmod-nvidia’

    would have accomplished the same thing but did not try it. Seems like it might not be the elrepo package that is the probleb.

    B.J.

    CentOS release 6.4 (Final)

  • Akemi Yagi wrote:

    Thanks, both of you, and good catch. Now I need to dig into what happened on *my* end: the elrepo.conf was dated last summer, and I had kmod-nvidia and nvidia-x11-drv installed… but when you folks pointed me to it, it
    *only* had includepkgs=kmod-nvidia. I know I didn’t do a localinstall, so I need to figure out how I installed it, if the repo file was like that, or if it got backed up to some in-progress repo from before I got the install working.

    mark

  • Akemi Yagi wrote:
    me to it, it that,

    I’d forgotten about that, but yep, that’s it. Hmmm… thank you I think, I
    see it now: that was *right* around the time that I got this workstation, and was building it.

    Wonder if I explicitly, on a command line, got that, and then didn’t add it, or whether this got restored from something during that initial build….

    I’ll make sure *that* doesn’t happen again.

    Again, thanks to all who helped me pinpoint what went wrong.

    I’m still ticked at the other admin who pushed me into this, rather than waiting for me to walk through it step by step….

    mark

  • You’re welcome.

    Mark – as a general word of advise, next time you have an issue, rather than ranting because something isn’t working as you expect and calling people stupid, perhaps you could try describing the problem you are experiencing in a rational manor and provide supporting information. It seems you had already decided it was someone else’s fault and were more interested in blaming others than examining your own issues.

    Most people in the community are happy to provide free support for the free software we ship, but when you start a thread accusing my colleagues and myself of being stupid, well it does not endear yourself to me nor put me in a state of mind where I particularly want to go out of my way to help you, for free. This isn’t the first time; it will be the last.

  • This is a generic issue that deserves at least some ranting, although not particularly at you. As long as the distro requires the use of a repository that by policy excludes things that almost everyone needs we are pretty much forced to use 3rd party repositories that almost by definition are uncoordinated in a way that makes their interaction unpredictable and any defensive configuration measures likely to fail.
    I don’t see any possibility of changing this, so what else is there to do but rant?

  • Les, calm down. Both CentOS and ELrepo are fine. The problem was caused by the OP’s own manual configuration, not the distro or the 3rd party repository.

  • Agreed, but those repositories don’t have everything – by policy – and everything can’t be coordinated or tested together. Thus the requirement for the manual configuration to attempt to control updates, and the likelihood that it will be wrong in the future or that problems with it will be exposed later.

  • Well, if you know what the goal of CentOS is, then ranting about something that is not in RHEL (and therefore also not in CentOS) is quite silly.

    If it is in RHEL, it is here .. if not, then it isn’t

    I don’t see that changing in the foreseeable future.

    But feel free to start a 100 post rant about how screwed up CentOS is if you like.

    However, a better action would be to buy an RHEL subscription and then convince them that you need more stuff in RHEL.

    Thanks, Johnny Hughes

  • Les Mikesell wrote:

    I responded to Ned in the way I suggested to him – offlist.

    And as the o/p, let me note to everyone else the following points:
    a) I called it a *moderate* rant – I wasn’t spitting, screaming in ALL
    CAPS, or calling names (except, by implication, the other admin
    I work with who did this to me).
    b) when people started making suggestions pointing me in the correct
    direction, I neither i) got huffy and deny it was on my end;
    ii) did not continue to scream and yell, but investigated as
    time allowed here at work, and iii) when I found the problem,
    worked to check the fix, and thanked the folks who’d helped.

    And I’m *sure* none of you have *ever* had something happened, and gotten pissed, and screamed all over…..

    mark “is that the Tooth Fairy I see?”
    deny

  • No, I’m not blaming you for it, and RH won’t change (and can’t unless US law changes drastically or they relocate). I’m just pointing out that the situation is problematic to the point that it causes trouble for even very experienced admins and everyone needs to be aware of it.

  • That was not the case in this instance, and lacking an example of such an instance, there’s no reason for you to continue this ranting thread.

    No, there probably isn’t any good reason to manually configure ELrepo as it was. Like EPEL, they don’t put packages in their repository that are also featured in the base distribution.

  • I’ll be done ranting when people understand that using 3rd party repos very often causes trouble if you don’t make manual configuration entries to control them. And those manual configuration entries are likely themselves to cause trouble. Which was the case.

    Nobody said this configuration was right. I said it was enough of a problem that that experienced admins get it wrong. You can’t really generalize about it because even with repos that have a policy of not overwriting base packages you can conflict with other 3rd party repos or even subsequently have one of those packages show up in base or one from CentOS extras show up in epel. It is one of those thing that bothers me because there should be a technical solution to getting matching components together but there isn’t for policy reasons.

  • Gordon Messmer wrote:

    Well, yes there is: it’s a matter of security. We’re supposed to only use certain repos, and no others, to guarantee, as much as we can, what we’re getting, and that it won’t conflict with anything else. Therefore, I got a dispensation from my manager for this purpose, and so I want to guarantee that I am getting nothing from elrepo other than what’s necessary for this driver.

    mark

  • That seems reasonable. I think the lesson that your admin should learn is that if they want to lock something down, do it from the start. It sounds like he probably install kmod-nvidia first, then locked the repo down not to get other packages. If he’d applied the filter from the beginning, it would have had to be correct to install the module.

  • W dniu 14.03.2013 20:37, b.j. mcclure pisze:
    This issue is similar to: my Fedora 19 install , rpmfusion kmod-nvidia and always is after xorg-x11-server-Xorg updates. I must manually restore this symbolic link, to gnome-shell to work not in fallback mode. My oftop to the thread.

    I.P.

  • I’m not able to replicate this. If you can clearly define a replicator and we can see what’s going on then I can fix the issue.

    What used to happen in this scenario was that updates to xorg-x11-server-Xorg reset the “Files” section of xorg.conf (see below)
    where the path to /usr/lib64/xorg/modules/extensions/nvidia/libglx.so is defined:

    Section “Files”
    ModulePath “/usr/lib64/xorg/modules/extensions/nvidia”
    ModulePath “/usr/lib64/xorg/modules”
    EndSection

    This can be reset by running ‘nvidia-config-display enable’ as root.

    But I can’t imagine why xorg-x11-server-Xorg would want to touch anything under /usr/lib64/xorg/modules/extensions/nvidia/

    Further, on el6 the scripts that used to cause the above behaviour are long gone.

LEAVE A COMMENT