So much for elrepo being a painless way to get working Nvidia drivers...
Yum update (or just update glibc) says:
--> Processing Dependency: /usr/sbin/ldconfig for package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 --> Finished Dependency Resolution Error: Package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 (@elrepo) Requires: /usr/sbin/ldconfig Removing: glibc-2.17-55.el7.x86_64 (@anaconda) Not found Updated By: glibc-2.17-55.el7_0.1.x86_64 (updates) Not found You could try using --skip-broken to work around the problem
What do those 'not found's mean?
On 09/09/2014 10:49 AM, Les Mikesell wrote:
So much for elrepo being a painless way to get working Nvidia drivers...
This isn't elrepo's fault.
The glibc update changes the location of the ldconfig binary. It's still in root's path, but anything that had a hardcoded path as a requirement will break.
The original glibc package provides both /usr/sbin/ldconfig and /sbin/ldconfig, while the updated package only provides /sbin/ldconfig.
Yum update (or just update glibc) says:
--> Processing Dependency: /usr/sbin/ldconfig for package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 --> Finished Dependency Resolution Error: Package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 (@elrepo) Requires: /usr/sbin/ldconfig Removing: glibc-2.17-55.el7.x86_64 (@anaconda) Not found Updated By: glibc-2.17-55.el7_0.1.x86_64 (updates) Not found You could try using --skip-broken to work around the problem
What do those 'not found's mean?
It means there's no more /usr/sbin/ldconfig provided in the newer packages.
On Tue, Sep 9, 2014 at 10:54 AM, Jim Perrin jperrin@centos.org wrote:
On 09/09/2014 10:49 AM, Les Mikesell wrote:
So much for elrepo being a painless way to get working Nvidia drivers...
This isn't elrepo's fault.
The glibc update changes the location of the ldconfig binary. It's still in root's path, but anything that had a hardcoded path as a requirement will break.
Ummm, great... I thought that was just the sort of breakage that 'Enterprise' OS versions were supposed to avoid. (I realize it's not CentOS's fault either).
The original glibc package provides both /usr/sbin/ldconfig and /sbin/ldconfig, while the updated package only provides /sbin/ldconfig.
The whole 's' concept was a bad idea to begin with. Why did they have to make it worse?
Yum update (or just update glibc) says:
--> Processing Dependency: /usr/sbin/ldconfig for package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 --> Finished Dependency Resolution Error: Package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 (@elrepo) Requires: /usr/sbin/ldconfig Removing: glibc-2.17-55.el7.x86_64 (@anaconda) Not found Updated By: glibc-2.17-55.el7_0.1.x86_64 (updates) Not found You could try using --skip-broken to work around the problem
What do those 'not found's mean?
It means there's no more /usr/sbin/ldconfig provided in the newer packages.
Seems odd to say it twice. But what's the right fix here?
On 09/09/14 17:02, Les Mikesell wrote:
On Tue, Sep 9, 2014 at 10:54 AM, Jim Perrin jperrin@centos.org wrote:
On 09/09/2014 10:49 AM, Les Mikesell wrote:
So much for elrepo being a painless way to get working Nvidia drivers...
This isn't elrepo's fault.
The glibc update changes the location of the ldconfig binary. It's still in root's path, but anything that had a hardcoded path as a requirement will break.
Ummm, great... I thought that was just the sort of breakage that 'Enterprise' OS versions were supposed to avoid. (I realize it's not CentOS's fault either).
The original glibc package provides both /usr/sbin/ldconfig and /sbin/ldconfig, while the updated package only provides /sbin/ldconfig.
The whole 's' concept was a bad idea to begin with. Why did they have to make it worse?
Yum update (or just update glibc) says:
--> Processing Dependency: /usr/sbin/ldconfig for package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 --> Finished Dependency Resolution Error: Package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 (@elrepo) Requires: /usr/sbin/ldconfig Removing: glibc-2.17-55.el7.x86_64 (@anaconda) Not found Updated By: glibc-2.17-55.el7_0.1.x86_64 (updates) Not found You could try using --skip-broken to work around the problem
What do those 'not found's mean?
It means there's no more /usr/sbin/ldconfig provided in the newer packages.
Seems odd to say it twice. But what's the right fix here?
Hi Les,
Actually I think Jim is being generous and I do take at least some responsibility for the breakage.
I've already committed a fix (below) but it won't show up until the next nvidia legacy driver release:
https://github.com/elrepo/packages/commit/760a09a8147c4bc676dfa05c03d682255d...
For now, one workaround is to install the glibc update with --nodeps (using rpm).
On 09/09/2014 10:49 AM, Les Mikesell wrote:
So much for elrepo being a painless way to get working Nvidia drivers...
Yum update (or just update glibc) says:
--> Processing Dependency: /usr/sbin/ldconfig for package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 --> Finished Dependency Resolution Error: Package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 (@elrepo) Requires: /usr/sbin/ldconfig Removing: glibc-2.17-55.el7.x86_64 (@anaconda) Not found Updated By: glibc-2.17-55.el7_0.1.x86_64 (updates) Not found You could try using --skip-broken to work around the problem
What do those 'not found's mean?
https://bugzilla.redhat.com/show_bug.cgi?id=1063607
On Tue, Sep 9, 2014 at 12:14 PM, Ian Pilcher arequipeno@gmail.com wrote:
On 09/09/2014 10:49 AM, Les Mikesell wrote:
So much for elrepo being a painless way to get working Nvidia drivers...
Yum update (or just update glibc) says:
--> Processing Dependency: /usr/sbin/ldconfig for package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 --> Finished Dependency Resolution Error: Package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 (@elrepo) Requires: /usr/sbin/ldconfig Removing: glibc-2.17-55.el7.x86_64 (@anaconda) Not found Updated By: glibc-2.17-55.el7_0.1.x86_64 (updates) Not found You could try using --skip-broken to work around the problem
What do those 'not found's mean?
Seems odd that with both the new and old glibc versions, rpm -q --whatprovides /usr/sbin/ldconfig says glibc-2.17-55.el7.x86_64 or glibc-2.17-55.el7_0.1.x86_64 yet yum doesn't think so.
I guess symlinks really are evil and only useful for job security...
On 09/09/2014 12:25 PM, Les Mikesell wrote:
Seems odd that with both the new and old glibc versions, rpm -q --whatprovides /usr/sbin/ldconfig says glibc-2.17-55.el7.x86_64 or glibc-2.17-55.el7_0.1.x86_64 yet yum doesn't think so.
RPM has been able to handle symlinks for a long time:
$ rpm -ql kdelibs | grep libkunittest.so.4.13.3 /usr/lib64/libkunittest.so.4.13.3 $ rpm -qf /lib64/libkunittest.so.4.13.3 kdelibs-4.13.3-1.fc20.x86_64
I presume that yum is querying RPM for information about installed packages, causing the installed version of glibc to "automagically" provide /usr/sbin/ldconfig. Let's test:
# ln -s /usr/sbin /foo # rpm -qf /foo/ldconfig glibc-2.17-55.el7_0.1.x86_64 # yum provides /foo/ldconfig ... glibc-2.17-55.el7_0.1.x86_64 : The GNU libc libraries Repo : @updates Matched from: Filename : /foo/ldconfig
So yum has (and uses) more information about installed packages.
-
Ian Pilcher -
Jim Perrin -
Les Mikesell -
Ned Slider