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. <rant, snort>
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
On Mar 14, 2013, at 10:17 AM, m.roth@5-cent.us wrote:
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.
Which card?
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...
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.
Found the proprietary installer on the NVidia site, and I'm up. <rant, snort>
Unnecessary. You need the elrepo nvidia version detector to see if you need the 304 legacy driver.
Also, is dkms coming in, or deprecated?
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.
Lamar Owen wrote:
On Mar 14, 2013, at 10:17 AM, m.roth@5-cent.us wrote:
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.
Which card?
GF100GL/Quadro 4000
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...
You may need the legacy version; this is clearly documented on the current elrepo wiki pages about their nvidia modules.
Nope, it does *not* use the legacy version. <snip>
Found the proprietary installer on the NVidia site, and I'm up. <rant, snort>
<snip>
Also, is dkms coming in, or deprecated?
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.
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
On 03/14/2013 09:17 AM, m.roth@5-cent.us wrote:
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. <rant, snort>
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?
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?
Johnny Hughes wrote:
On 03/14/2013 09:17 AM, m.roth@5-cent.us wrote:
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.
<snip>
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...?
<snip>
Also, is dkms coming in, or deprecated?
None of those modules are in CentOS, but a 3rd party repo.
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.
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?
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
On 14/03/13 15:01, m.roth@5-cent.us wrote:
Johnny Hughes wrote:
On 03/14/2013 09:17 AM, m.roth@5-cent.us wrote:
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.
<snip> >> 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...? <snip> >> Also, is dkms coming in, or deprecated? > > None of those modules are in CentOS, but a 3rd party repo.
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.
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?
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.
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:
On 14/03/13 15:01, m.roth@5-cent.us wrote:
Johnny Hughes wrote:
On 03/14/2013 09:17 AM, m.roth@5-cent.us wrote:
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.
<snip> >> 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...?
<snip>
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.
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
<snip>
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.
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
On 14/03/13 16:34, m.roth@5-cent.us wrote:
Ned Slider wrote:
On 14/03/13 15:01, m.roth@5-cent.us wrote:
Johnny Hughes wrote:
On 03/14/2013 09:17 AM, m.roth@5-cent.us wrote:
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.
<snip> >> 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...?
<snip> > 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.
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
The package is there on that mirror:
http://mirror.symnds.com/distributions/elrepo/elrepo/el6/x86_64/RPMS/nvidia-...
which means the issue is your end.
Please show your /etc/yum.repos.d/elrepo.repo
On Thu, Mar 14, 2013 at 10:01 AM, Ned Slider ned@unixmail.co.uk wrote:
On 14/03/13 16:34, m.roth@5-cent.us 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
The package is there on that mirror:
http://mirror.symnds.com/distributions/elrepo/elrepo/el6/x86_64/RPMS/nvidia-...
which means the issue is your end.
Please show your /etc/yum.repos.d/elrepo.repo
Also check your exclude= line(s).
Akemi
Akemi Yagi wrote:
On Thu, Mar 14, 2013 at 10:01 AM, Ned Slider ned@unixmail.co.uk wrote:
On 14/03/13 16:34, m.roth@5-cent.us 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
The package is there on that mirror:
http://mirror.symnds.com/distributions/elrepo/elrepo/el6/x86_64/RPMS/nvidia-...
which means the issue is your end.
Please show your /etc/yum.repos.d/elrepo.repo
Also check your exclude= line(s).
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
On Thu, Mar 14, 2013 at 12:43 PM, m.roth@5-cent.us 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
So, what you've found is that this is a recurrence of the old problem you had before?
http://lists.centos.org/pipermail/centos/2012-July/127950.html
If so, just curious why this resurfaced.
Akemi
Akemi Yagi wrote:
On Thu, Mar 14, 2013 at 12:43 PM, m.roth@5-cent.us 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.
So, what you've found is that this is a recurrence of the old problem you had before?
http://lists.centos.org/pipermail/centos/2012-July/127950.html
If so, just curious why this resurfaced.
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
On 14/03/13 20:32, m.roth@5-cent.us wrote:
Akemi Yagi wrote:
On Thu, Mar 14, 2013 at 12:43 PM, m.roth@5-cent.us 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.
So, what you've found is that this is a recurrence of the old problem you had before?
http://lists.centos.org/pipermail/centos/2012-July/127950.html
If so, just curious why this resurfaced.
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.
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.
On Fri, Mar 15, 2013 at 9:58 AM, Ned Slider ned@unixmail.co.uk wrote:
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.
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?
On 03/15/2013 08:32 AM, Les Mikesell wrote:
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
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.
On Fri, Mar 15, 2013 at 10:58 AM, Gordon Messmer yinyang@eburg.com wrote:
On 03/15/2013 08:32 AM, Les Mikesell wrote:
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
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.
On 03/15/2013 09:29 AM, Les Mikesell wrote:
Agreed, but those repositories don't have everything - by policy - and everything can't be coordinated or tested together.
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.
Thus the requirement for the manual configuration to attempt to control updates
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.
On Fri, Mar 15, 2013 at 2:10 PM, Gordon Messmer yinyang@eburg.com wrote:
Agreed, but those repositories don't have everything - by policy - and everything can't be coordinated or tested together.
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.
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.
Thus the requirement for the manual configuration to attempt to control updates
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.
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:
On 03/15/2013 09:29 AM, Les Mikesell wrote:
Agreed, but those repositories don't have everything - by policy - and everything can't be coordinated or tested together.
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.
Thus the requirement for the manual configuration to attempt to control updates
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.
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
On 03/15/2013 12:52 PM, m.roth@5-cent.us 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.
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.
On 03/15/2013 10:32 AM, Les Mikesell wrote:
On Fri, Mar 15, 2013 at 9:58 AM, Ned Slider ned@unixmail.co.uk wrote:
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.
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?
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
On Fri, Mar 15, 2013 at 11:38 AM, Johnny Hughes johnny@centos.org wrote:
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.
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.
Les Mikesell wrote:
On Fri, Mar 15, 2013 at 9:58 AM, Ned Slider ned@unixmail.co.uk wrote:
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.
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?
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
On 15 Mar 2013, at 18:16, m.roth@5-cent.us wrote:
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).
Seems unfair to continue to blame them when the solution was pointed out to *you* a year ago.
Ben
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)
On Thu, 2013-03-14 at 09:25 -0500, Johnny Hughes wrote:
On 03/14/2013 09:17 AM, m.roth@5-cent.us wrote:
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. <rant, snort>
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?
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?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
W dniu 14.03.2013 20:37, b.j. mcclure pisze:
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)
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.
On Thu, 2013-03-14 at 09:25 -0500, Johnny Hughes wrote:
On 03/14/2013 09:17 AM, m.roth@5-cent.us wrote:
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. <rant, snort>
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?
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?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 14/03/13 19:37, b.j. mcclure wrote:
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)
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.
Am 14.03.2013 15:17, schrieb m.roth@5-cent.us:
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.
No link, but while I was still using the proprietary driver I did it like this:
${NVDRV}.run -sKk ${KERNELRELEASE}
Sorry, clicked "send" too soon.
Am 14.03.2013 15:37, schrieb Tilman Schmidt:
Am 14.03.2013 15:17, schrieb m.roth@5-cent.us:
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.
No link, but while I was still using the proprietary driver I did it like this:
${NVDRV}.run -sKk ${KERNELRELEASE}
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.
Tilman Schmidt wrote:
Sorry, clicked "send" too soon.
Am 14.03.2013 15:37, schrieb Tilman Schmidt:
Am 14.03.2013 15:17, schrieb m.roth@5-cent.us:
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.
No link, but while I was still using the proprietary driver I did it like this:
${NVDRV}.run -sKk ${KERNELRELEASE}
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
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
On Thu, Mar 14, 2013 at 8:03 AM, m.roth@5-cent.us wrote:
a lot of us need the proprietary driver because we use two monitors, and *bleah* nouveau doesn't support twinview).
mark
Then you want to read this CentOS *FAQ*:
http://wiki.centos.org/FAQ/CentOS6#head-012846a4e422267a34e81c4c905654fc8f36...
Akemi
Akemi Yagi wrote:
On Thu, Mar 14, 2013 at 8:03 AM, m.roth@5-cent.us wrote:
a lot of us need the proprietary driver because we use two monitors, and
*bleah* nouveau doesn't support twinview).
Then you want to read this CentOS *FAQ*:
http://wiki.centos.org/FAQ/CentOS6#head-012846a4e422267a34e81c4c905654fc8f36...
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
On 14.03.2013 14:17, m.roth@5-cent.us wrote:
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.
Install and run nvidia-detect from Elrepo, it will tell you which packages you need to install.
HTH
-
Akemi Yagi -
b.j. mcclure -
Benjamin Donnachie -
Gordon Messmer -
I.Piasecki -
Johnny Hughes -
Lamar Owen -
Les Mikesell -
m.roth＠5-cent.us -
Ned Slider -
Nux! -
Tilman Schmidt