I have an Athlon/64, 1 GB RAM, 80 GB IDE system and I'm intending to use it for combination workstation/Dev server duties.
I've gotten a consistent failure when I try to groupinstall KDE. After grinding through all the deps, it comes up with the below:
Install 228 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 331 M Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test
Transaction Check Error: file /usr/share/man/man1/asn1parse.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man1/nseq.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man1/s_client.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man1/s_server.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man1/sslpasswd.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man5/fonts-conf.5.gz from install of fontconfig-2.2.3-7 conflicts with file from package fontconfig-2.2.3-7
It appears that packages openssl and fontconfig are conflicting with themselves! (?!?)
This is a clean, minimal install of CentOS 4.3/64, (installed with all optional packages unchecked, so only disk 1 was needed) I haven't even done a yum update, but that doesn't change anything when I try it. (I've now wiped it twice to try to figure out what I'm missing. Both packages are already installed, with the versions complained about...
I've tried running rpm --rebuilddb, and yum clean all to no positive change.
What's going on here? What can I try from here?
-Ben
It appears that packages openssl and fontconfig are conflicting with themselves! (?!?)
Yes, they are. You're suffering from x86 vs x86_64. You need to exclude i386 in your yum configs
This is a clean, minimal install of CentOS 4.3/64, (installed with all optional packages unchecked, so only disk 1 was needed) I haven't even done a yum update, but that doesn't change anything when I try it. (I've now wiped it twice to try to figure out what I'm missing. Both packages are already installed, with the versions complained about...
I've tried running rpm --rebuilddb, and yum clean all to no positive change.
What's going on here? What can I try from here?
create a ~/.rpmmacros file containing: %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}
and this will clue you into when i386 packages are conflicting with x86_64 packages.
-- Any sufficiently advanced technology is indistinguishable from magic. -Arthur C. Clarke
Thanks.
What you wrote led me to a google search which resulted in this link:
https://lists.dulug.duke.edu/pipermail/yum/2005-August/007269.html
which had a line to do a yum exclude which allowed me to get it to fly. It's now going thru 171 packages.... w00T...
Thanks!
-Ben
On Monday 17 April 2006 11:27, Jim Perrin wrote:
It appears that packages openssl and fontconfig are conflicting with themselves! (?!?)
Yes, they are. You're suffering from x86 vs x86_64. You need to exclude i386 in your yum configs
This is a clean, minimal install of CentOS 4.3/64, (installed with all optional packages unchecked, so only disk 1 was needed) I haven't even
done a
yum update, but that doesn't change anything when I try it. (I've now
wiped
it twice to try to figure out what I'm missing. Both packages are already installed, with the versions complained about...
I've tried running rpm --rebuilddb, and yum clean all to no positive
change.
What's going on here? What can I try from here?
create a ~/.rpmmacros file containing: %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}
and this will clue you into when i386 packages are conflicting with x86_64 packages.
-- Any sufficiently advanced technology is indistinguishable from magic. -Arthur C. Clarke _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Benjamin Smith wrote:
Thanks.
What you wrote led me to a google search which resulted in this link:
https://lists.dulug.duke.edu/pipermail/yum/2005-August/007269.html
which had a line to do a yum exclude which allowed me to get it to fly. It's now going thru 171 packages.... w00T...
wait!
dont just add that line in there, first make sure you yum erase all your 32bit apps and rpm's ( yum erase *.i386 *.i586 *.i686 ), otherwise you are going to leave behind a large number of orphaned rpm's.
if you need those 32bit apps, consider just excluding the fontconfig.i386 rpm. its a problem known since early 4.0 release days :(
Karanbir Singh spake the following on 4/17/2006 1:45 PM:
Benjamin Smith wrote:
Thanks. What you wrote led me to a google search which resulted in this link: https://lists.dulug.duke.edu/pipermail/yum/2005-August/007269.html
which had a line to do a yum exclude which allowed me to get it to fly. It's now going thru 171 packages.... w00T...
wait!
dont just add that line in there, first make sure you yum erase all your 32bit apps and rpm's ( yum erase *.i386 *.i586 *.i686 ), otherwise you are going to leave behind a large number of orphaned rpm's.
if you need those 32bit apps, consider just excluding the fontconfig.i386 rpm. its a problem known since early 4.0 release days :(
Or do rpm -e --justdb --nodeps fontconfig
Scott Silva wrote:
Karanbir Singh spake the following on 4/17/2006 1:45 PM:
Benjamin Smith wrote:
Thanks. What you wrote led me to a google search which resulted in this link: https://lists.dulug.duke.edu/pipermail/yum/2005-August/007269.html
which had a line to do a yum exclude which allowed me to get it to fly. It's now going thru 171 packages.... w00T...
wait!
dont just add that line in there, first make sure you yum erase all your 32bit apps and rpm's ( yum erase *.i386 *.i586 *.i686 ), otherwise you are going to leave behind a large number of orphaned rpm's.
if you need those 32bit apps, consider just excluding the fontconfig.i386 rpm. its a problem known since early 4.0 release days :(
Or do rpm -e --justdb --nodeps fontconfig
are you sure this wont create any orphans ?
Karanbir Singh spake the following on 4/17/2006 4:41 PM:
Scott Silva wrote:
Karanbir Singh spake the following on 4/17/2006 1:45 PM:
Benjamin Smith wrote:
Thanks. What you wrote led me to a google search which resulted in this link: https://lists.dulug.duke.edu/pipermail/yum/2005-August/007269.html
which had a line to do a yum exclude which allowed me to get it to fly. It's now going thru 171 packages.... w00T...
wait!
dont just add that line in there, first make sure you yum erase all your 32bit apps and rpm's ( yum erase *.i386 *.i586 *.i686 ), otherwise you are going to leave behind a large number of orphaned rpm's.
if you need those 32bit apps, consider just excluding the fontconfig.i386 rpm. its a problem known since early 4.0 release days :(
Or do rpm -e --justdb --nodeps fontconfig
are you sure this wont create any orphans ?
It just removes the database entry for fontconfig. When you do the groupinstall, it will re-install fontconfig, and the database is back to normal.
Scott Silva wrote:
Karanbir Singh spake the following on 4/17/2006 4:41 PM:
Scott Silva wrote:
Karanbir Singh spake the following on 4/17/2006 1:45 PM:
Benjamin Smith wrote:
Thanks. What you wrote led me to a google search which resulted in this link: https://lists.dulug.duke.edu/pipermail/yum/2005-August/007269.html
which had a line to do a yum exclude which allowed me to get it to fly. It's now going thru 171 packages.... w00T...
wait!
dont just add that line in there, first make sure you yum erase all your 32bit apps and rpm's ( yum erase *.i386 *.i586 *.i686 ), otherwise you are going to leave behind a large number of orphaned rpm's.
if you need those 32bit apps, consider just excluding the fontconfig.i386 rpm. its a problem known since early 4.0 release days :(
Or do rpm -e --justdb --nodeps fontconfig
are you sure this wont create any orphans ?
It just removes the database entry for fontconfig. When you do the groupinstall, it will re-install fontconfig, and the database is back to normal.
but which one ? i386 and x86_64 both have fontconfig pkgs, each of which is Arch specific - and expose different _libdir data.
because a couple of files overlap, does not mean the rest do as well!
--nodeps is a bad idea. dont use it.
Have a inter-interface routing issue, hoping someone can either throw a clue or point me where I can get one. This is on a CentOS 3.7 system.
Have interfaces eth0 and eth1. eth0 is connected to internal network, eth1 to separate distinct network. The default route on the box is set to the roter address on the eth1 network. I have static routes defined to send local network traffic to eth0 and eth0's router.
I have a mail server (and a test program as well) that binds to an address on eth1, and tries to connect to an address on eth0's network. Connections just time out. I've tested connections where I did not bind to a specific interface and I can make the connection.
I've set rp_filter=0, and ip_forward=1 for all interfaces, and still cannot get a connection from eth1's address to something off of eth0's networks. Firewalls are disabled on the host.
Is there additional voodoo that needs to be set to allow traffic to cross from one interface to the other?
Thanks in advance for any advice or pointers. I hope I've made the problem clear enough... -Alan
On 4/17/06, Alan Sparks asparks@doublesparks.net wrote:
Have interfaces eth0 and eth1. eth0 is connected to internal network, eth1 to separate distinct network. The default route on the box is set to the roter address on the eth1 network. I have static routes defined to send local network traffic to eth0 and eth0's router.
I've set rp_filter=0, and ip_forward=1 for all interfaces, and still cannot get a connection from eth1's address to something off of eth0's networks.
This all sounds right ... though I'm not entirely sure what you mean by "ip_forward=1 for all interfaces"; are you using /etc/sysctl.conf to set this?
net.ipv4.ip_forward = 1
If you wouldn't mind sending the output of "route -n" that might offer additional clues.
Alan Sparks wrote:
Is there additional voodoo that needs to be set to allow traffic to cross from one interface to the other?
Thanks in advance for any advice or pointers. I hope I've made the problem clear enough...
At the point you think things should be working and they aren't, it's time to fire up tcpdump on both interfaces and see what the packets are actually doing.
tcpdump -ni eth0 ip
and
tcpdump -ni eth1 ip
for example
On Mon, 2006-04-17 at 22:20 -0700, Keith Morse wrote:
Alan Sparks wrote:
Is there additional voodoo that needs to be set to allow traffic to cross from one interface to the other?
I trust you have "net.ipv4.ip_forward = 1" set in your /etc/sysctl.conf file? If not, make that change and run "sysctl -p"
HTH, Barry
Keith Morse said:
At the point you think things should be working and they aren't, it's time to fire up tcpdump on both interfaces and see what the packets are actually doing.
A while later it occurred to me the problem wasn't the server. It was fine. But the packets with eth1's source address, going out eth0, couldn't be responded to. Duh. Have solved the problem with a little SNAT. Thanks for the responses. -Alan
=========== Alan Sparks, UNIX/Linux Systems Administrator asparks@doublesparks.net
Scott Silva wrote:
Karanbir Singh spake the following on 4/17/2006 1:45 PM:
if you need those 32bit apps, consider just excluding the fontconfig.i386 rpm. its a problem known since early 4.0 release days :(
Or do rpm -e --justdb --nodeps fontconfig
Eek. IMO, bad advice. You'll leave orphaned(unowned) files behind.
-- Rex
On Tuesday 18 April 2006 04:23, Rex Dieter wrote:
Scott Silva wrote:
Karanbir Singh spake the following on 4/17/2006 1:45 PM:
if you need those 32bit apps, consider just excluding the fontconfig.i386 rpm. its a problem known since early 4.0 release days :(
Or do rpm -e --justdb --nodeps fontconfig
Eek. IMO, bad advice. You'll leave orphaned(unowned) files behind.
...and I don't want to do that, right?
I put in lines like mentioned below in /etc/yum.conf to stop installing 32-bit packages, and finally got KDE to install, but now I'm running into the exact same issues trying to install OpenOffice.org.
What's recommended practice for getting this to install on a (primarily) 64-bit athlon/64 system? It's pretty much required since this will be a workstation...
When I try to install OpenOffice, I get complaints (again) about openssl, fontconfig, and now libIDL:
Transaction Check Error: package libIDL-0.8.4-1.centos4 (which is newer than libIDL-0.8.4-1) is already installed
in /etc/yum.conf, I've tried the following: exclude=*fontconfig.x86_64 openssl.x86_64 libIDL.x86_64 which gives these errors ################################# Transaction Check Error: package libIDL-0.8.4-1.centos4 (which is newer than libIDL-0.8.4-1) is already installed file /usr/share/man/man5/fonts-conf.5.gz from install of fontconfig-2.2.3-7 conflicts with file from package fontconfig-2.2.3-7 file /usr/share/man/man1/asn1parse.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man1/nseq.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man1/s_client.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man1/s_server.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man1/sslpasswd.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
as well as exclude=*fontconfig.i386 openssl.i686 libIDL.i386 which then gives these: ################################# Error: Missing Dependency: libfontconfig.so.1 is needed by package gtk2 Error: Missing Dependency: libfontconfig.so.1 is needed by package xorg-x11-libs Error: Missing Dependency: libcrypto.so.4 is needed by package gnome-vfs2 Error: Missing Dependency: libssl.so.4 is needed by package gnome-vfs2 Error: Missing Dependency: libIDL-2.so.0 is needed by package ORBit2 Error: Missing Dependency: libfontconfig.so.1 is needed by package pango Error: Missing Dependency: libcrypto.so.4 is needed by package openldap Error: Missing Dependency: libssl.so.4 is needed by package openldap Error: Missing Dependency: libcrypto.so.4 is needed by package cyrus-sasl
// Shrug //
Any idea where to go from here? I'm tempted at this point to punt on X86_64 for workstation use and just use 32 bit. It does not seem not all that usable when basic package installation fails like this.
(Does %upstream-provider% actually consider this "release quality"?)
-Ben
On Tue, 2006-04-18 at 14:12 -0700, Benjamin Smith wrote:
On Tuesday 18 April 2006 04:23, Rex Dieter wrote:
Scott Silva wrote:
Karanbir Singh spake the following on 4/17/2006 1:45 PM:
if you need those 32bit apps, consider just excluding the fontconfig.i386 rpm. its a problem known since early 4.0 release days :(
Or do rpm -e --justdb --nodeps fontconfig
Eek. IMO, bad advice. You'll leave orphaned(unowned) files behind.
...and I don't want to do that, right?
I put in lines like mentioned below in /etc/yum.conf to stop installing 32-bit packages, and finally got KDE to install, but now I'm running into the exact same issues trying to install OpenOffice.org.
That is because there is no 64-bit version of open office ... I recommend that if you need anything installed that is i386 (ie, openoffice ...) that you just use the i386 distro.
The x86_64 distro contains both x86_64 and i386 parts ... and while you can mix them, it causes issues. This is especially true if you want to compile anything on the machine with both 32 and 64 bit files installed.
What's recommended practice for getting this to install on a (primarily) 64-bit athlon/64 system? It's pretty much required since this will be a workstation...
For workstations, I would recommend i386 installs
When I try to install OpenOffice, I get complaints (again) about openssl, fontconfig, and now libIDL:
Transaction Check Error: package libIDL-0.8.4-1.centos4 (which is newer than libIDL-0.8.4-1) is already installed
in /etc/yum.conf, I've tried the following: exclude=*fontconfig.x86_64 openssl.x86_64 libIDL.x86_64 which gives these errors ################################# Transaction Check Error: package libIDL-0.8.4-1.centos4 (which is newer than libIDL-0.8.4-1) is already installed file /usr/share/man/man5/fonts-conf.5.gz from install of fontconfig-2.2.3-7 conflicts with file from package fontconfig-2.2.3-7 file /usr/share/man/man1/asn1parse.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man1/nseq.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man1/s_client.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man1/s_server.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8 file /usr/share/man/man1/sslpasswd.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
as well as exclude=*fontconfig.i386 openssl.i686 libIDL.i386 which then gives these: ################################# Error: Missing Dependency: libfontconfig.so.1 is needed by package gtk2 Error: Missing Dependency: libfontconfig.so.1 is needed by package xorg-x11-libs Error: Missing Dependency: libcrypto.so.4 is needed by package gnome-vfs2 Error: Missing Dependency: libssl.so.4 is needed by package gnome-vfs2 Error: Missing Dependency: libIDL-2.so.0 is needed by package ORBit2 Error: Missing Dependency: libfontconfig.so.1 is needed by package pango Error: Missing Dependency: libcrypto.so.4 is needed by package openldap Error: Missing Dependency: libssl.so.4 is needed by package openldap Error: Missing Dependency: libcrypto.so.4 is needed by package cyrus-sasl
// Shrug //
Any idea where to go from here? I'm tempted at this point to punt on X86_64 for workstation use and just use 32 bit. It does not seem not all that usable when basic package installation fails like this.
That is what I do ... I use x86_64 for server installs and i386 for workstation installs.
(Does %upstream-provider% actually consider this "release quality"?)
-Ben
Benjamin Smith wrote:
as well as exclude=*fontconfig.i386 openssl.i686 libIDL.i386
you dont need to exclude these pkgs anymore, we've fixed them in the centos repo's - it should just work out of the box with no excludes now.
let us know how you get along...
On Mon, 17 Apr 2006, Jim Perrin wrote:
It appears that packages openssl and fontconfig are conflicting with themselves! (?!?)
Yes, they are. You're suffering from x86 vs x86_64.
create a ~/.rpmmacros file containing: %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}
This one seems to come up a lot. Should this be the default, or the default on all non-i386 platforms?
A year ago, it was reasonable to assume that anyone with non-i386 hardware knew enough to find this trick. I don't think this assumption is true now; my neighbor's 14-year-old son has a x86_64 laptop and claims to never have heard of AMD.
-David
create a ~/.rpmmacros file containing: %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}
This one seems to come up a lot. Should this be the default, or the default on all non-i386 platforms?
Should it be? Yes, however it should come from the upstream vendor as the default. If we're trying to be 100% like upstream, then you have to replicate the annoyances as well. It does need to be a prominently displayed FAQ.
A year ago, it was reasonable to assume that anyone with non-i386 hardware knew enough to find this trick. I don't think this assumption is true now; my neighbor's 14-year-old son has a x86_64 laptop and claims to never have heard of AMD.
Make something idiot-proof and they'll build a better idiot. There's a fine line between assisting people, and interfering with natural selection.
-- This message has been double ROT13 encoded for security. Anyone other than the intended recipient attempting to decode this message will be in violation of the DMCA
On Mon, 1 May 2006, Jim Perrin wrote:
create a ~/.rpmmacros file containing: %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}
This one seems to come up a lot. Should this be the default...?
Should it be? Yes, however it should come from the upstream vendor as the default. If we're trying to be 100% like upstream, then you have to replicate the annoyances as well. It does need to be a prominently displayed FAQ.
I just saw this in bugzilla.redhat.com: ------- Additional Comments From n3npq@mac.com 2006-05-02 18:40 EST FWIW, this is fixed in rpm-4.4.2 and later.
-David
-
Alan Sparks -
Barry Brimer -
Bart Schaefer -
Benjamin Smith -
Jim Perrin -
Johnny Hughes -
Karanbir Singh -
Keith Morse -
Lists -
Rex Dieter -
Scott Silva