Hi Everyone,
Are there any risks in installing i386 binaries (via rpm) on a x86_64 installation of CentOS 4.4?
Thanks
On Sat, 2007-01-20 at 17:59 +1100, Devraj Mukherjee wrote:
Hi Everyone,
Are there any risks in installing i386 binaries (via rpm) on a x86_64 installation of CentOS 4.4?
I don't know if risk is the right word .. and if you stay with the i386 RPMS that are in the x86_64 repo you will have minimum headaches.
The problem comes in if you want to have BOTH the i386 and x86_64 version of a package installed. In that case, there are sometimes shared files to both packges (ie, files in /etc/, /usr/share/, etc.)
If those "Support Files" are not EXACTLY the same, there is an error installing or updating them.
We try very hard to make sure the i386 files in x86_64 tree work as planned. If you install the i386 RPMS from outside that tree, you will have to make them work yourself.
Personally, I would only install the x86_64 distro if I was reasonably sure that I would not require i386 RPMS (or minimal i386 RPMS).
I just use i386 on all workstations and I use x86_64 on servers ... and even on servers, only ones that will really be under heavy load or will definitely not need i386 packages.
Some tricks to make i386 packages install ... use:
rpm -Uvh --nodocs rpmname1 rpmname2
(rpmname1 and 2 are the names of the rpms you want to install)
This prevents the install of docs for the i386 packages .. which cuts out the usual source of the Duplicate file error.
Thanks Johnny.
On 1/20/07, Johnny Hughes mailing-lists@hughesjr.com wrote:
On Sat, 2007-01-20 at 17:59 +1100, Devraj Mukherjee wrote:
Hi Everyone,
Are there any risks in installing i386 binaries (via rpm) on a x86_64 installation of CentOS 4.4?
I don't know if risk is the right word .. and if you stay with the i386 RPMS that are in the x86_64 repo you will have minimum headaches.
The problem comes in if you want to have BOTH the i386 and x86_64 version of a package installed. In that case, there are sometimes shared files to both packges (ie, files in /etc/, /usr/share/, etc.)
If those "Support Files" are not EXACTLY the same, there is an error installing or updating them.
We try very hard to make sure the i386 files in x86_64 tree work as planned. If you install the i386 RPMS from outside that tree, you will have to make them work yourself.
Personally, I would only install the x86_64 distro if I was reasonably sure that I would not require i386 RPMS (or minimal i386 RPMS).
I just use i386 on all workstations and I use x86_64 on servers ... and even on servers, only ones that will really be under heavy load or will definitely not need i386 packages.
Some tricks to make i386 packages install ... use:
rpm -Uvh --nodocs rpmname1 rpmname2
(rpmname1 and 2 are the names of the rpms you want to install)
This prevents the install of docs for the i386 packages .. which cuts out the usual source of the Duplicate file error.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Are there any risks in installing i386 binaries (via rpm) on a x86_64 installation of CentOS 4.4?
Personally I find that the best solution is to install an i386, then swapout the kernel, install a few extra 64 bit libraries, and then potentially reinstall whatever packages you need to be 64bit for performance reasons.
[Mind you, you might need to mess around a bit to get this working, I can't remember the exact steps I took last time I did this to get the rpms to install without complaints, but I think I remember actually doing both a i386 and x86_64 install in seperate partitions and then doing a manual merge and removing one of them... should probably document it...]
Me? I use 32-bit everything, except kernel, libc, stdlibc++ and the compiler. But then all I need it for is development of short but extremely memory hogging C/C++ applications.
Maciej
While commenting on the subject of: "Re: [CentOS] Risks of installing i386 rpms on a x86_64 CentOS 4.4 installation" Johnny Hughes wrote:
[snip]
Personally, I would only install the x86_64 distro if I was reasonably sure that I would not require i386 RPMS (or minimal i386 RPMS).
I just use i386 on all workstations and I use x86_64 on servers ... and even on servers, only ones that will really be under heavy load or will definitely not need i386 packages.
If you wouldn't mind Johnny, could you elaborate on your "Personally..." recommendation? I am running 4.4 x86_64 on AMD hardware (x64 3500+, 1G, 3x160G SATA, Gigabyte nvidia nForce-4 Ultra chipset MB w/ Gigabyte 6200 series pci-e graphics) for a "personal workstation" (otherwise known as a heavily used home computer). I just counted in yumex and I have about 77 packages with both 64 and 32 bit versions installed. One (of several) reason I switched to Centos from Mandriva is the poor support Mandriva had for 64 bit versions. Most packages in their repos were only available in 32 bit versions, and some minor OS upgrades came out only in 32bit. Centos seems to be very even-handed about the architectures (at least i836 vs. x86_64).
So far the 64/32 bit issue has only come up a couple of times, and I was able to resolve it leaving any blood (from my head) on the wall. Should I be looking at switching to 32 bit? If so, how on earth does one do that without rebuilding the machine from scratch? I still don't have this one tweaked very well, and don't have all the programs I want installed. I'd rather not start over AGAIN.
If it helps, my use is the usual email, web surfing, OpenOffice, plus desktop publishing (scribus), graphics (gimp, cinepaint, and others), and audio editing (audacity, etc) and I am trying to learn C++ (eclipse based). I run VMWare server for those programs which I am forced to use in other operating systems (and also to isolate ipcop). I am not a newbie, but neither am I an experienced old hand. I have been using Linux for my personal computing for about a year (since I got this hardware). I have had a Linux file server in my basement for about four years, but I set it up once and mostly ignored it (I think it runs RH8).
Your personal comments on my situation are welcome, as well as anyone else who wants to chime in.
Ted Miller Indiana, USA
On Sun, 2007-01-21 at 16:56 -0500, Ted Miller wrote:
While commenting on the subject of: "Re: [CentOS] Risks of installing i386 rpms on a x86_64 CentOS 4.4 installation" Johnny Hughes wrote:
[snip]
Personally, I would only install the x86_64 distro if I was reasonably sure that I would not require i386 RPMS (or minimal i386 RPMS).
I just use i386 on all workstations and I use x86_64 on servers ... and even on servers, only ones that will really be under heavy load or will definitely not need i386 packages.
If you wouldn't mind Johnny, could you elaborate on your "Personally..." recommendation? I am running 4.4 x86_64 on AMD hardware (x64 3500+, 1G, 3x160G SATA, Gigabyte nvidia nForce-4 Ultra chipset MB w/ Gigabyte 6200 series pci-e graphics) for a "personal workstation" (otherwise known as a heavily used home computer). I just counted in yumex and I have about 77 packages with both 64 and 32 bit versions installed. One (of several) reason I switched to Centos from Mandriva is the poor support Mandriva had for 64 bit versions. Most packages in their repos were only available in 32 bit versions, and some minor OS upgrades came out only in 32bit. Centos seems to be very even-handed about the architectures (at least i836 vs. x86_64).
It is a headache (IMHO) to have to maintain a bunch of multiple arch RPMS. As I said before, IF you stay with only the 32bit items that are in the official x86_64 repository then you should be mostly fine.
I personally think that the way x86_64 is handled is a buggy kludge (yes, I know I am the maintainer of this $ARCH :P). An example is that if you install an i386 and x86_64 package of the same name ... then remove the i386 package ... some of the shared files (that were identical on install and worked ok) that are in both might be removed. These should stay as the x86_64 package is still installed.
This happens often enough that I wrote a script that figures out what should be there on x86_64 packages and gives me a list of packages that I need to reinstall to get the shared files back if they are missing.
If you install the packages and keep them there, this is not a problem.
I personally think that there should not be any i386 bits in the x86_64 repo and that all items should be x86_64 only ... or that they need to better engineer a solution to handle docs / shared files (for both installation and removal).
So far the 64/32 bit issue has only come up a couple of times, and I was able to resolve it leaving any blood (from my head) on the wall. Should I be looking at switching to 32 bit? If so, how on earth does one do that without rebuilding the machine from scratch? I still don't have this one tweaked very well, and don't have all the programs I want installed. I'd rather not start over AGAIN.
If you can live with the selection of RPMS in the x86_64 distro, then you should be OK.
If you are going to compile items that you expect to work on other x86_64 machines that are 64bit, then you will need a separate chroot that does not contain so many i386 libraries (or even use mock to build with) to build x86_64 packages ... and a chroot for i386 too if appropriate (ie, you want to build 32bit apps to run on the i386 distro).
(What will happen is that unless you are very careful, you will add 64bit libs to 32bit complied programs and also 32bit libs to 64bit compiled programs)
If it helps, my use is the usual email, web surfing, OpenOffice, plus desktop publishing (scribus), graphics (gimp, cinepaint, and others), and audio editing (audacity, etc) and I am trying to learn C++ (eclipse based). I run VMWare server for those programs which I am forced to use in other operating systems (and also to isolate ipcop). I am not a newbie, but neither am I an experienced old hand. I have been using Linux for my personal computing for about a year (since I got this hardware). I have had a Linux file server in my basement for about four years, but I set it up once and mostly ignored it (I think it runs RH8).
My personal opinion is that the benefits of x86_64 are marginal for normal workstation use (however I see you use cinepaint ... video processing can sometimes need the added x86_64 features).
If you need to bring in many i386 apps into x86_64, especially if you need to bring in many "non CentOS x86_64 repo" type i386 RPMS, then I would think that (at least for CentOS-4) and i386 distro would be better.
CentOS-5 beta will have an OOo version for x86_64 (at least the beta from upstream does), so that is one major obstacle overcome.
Your personal comments on my situation are welcome, as well as anyone else who wants to chime in.
If you are currently able to maintain your system and are happy with it, then keep it as is ... just understand what causes the problems and how to work around them. (using --nodocs or --force ... be very careful with --force though). Also the potential compile problems that can be introduced, etc.
Thanks, Johnny Hughes
Johnny Hughes wrote:
It is a headache (IMHO) to have to maintain a bunch of multiple arch RPMS. As I said before, IF you stay with only the 32bit items that are in the official x86_64 repository then you should be mostly fine.
I personally think that the way x86_64 is handled is a buggy kludge (yes, I know I am the maintainer of this $ARCH :P). An example is that if you install an i386 and x86_64 package of the same name ... then remove the i386 package ... some of the shared files (that were identical on install and worked ok) that are in both might be removed. These should stay as the x86_64 package is still installed.
This happens often enough that I wrote a script that figures out what should be there on x86_64 packages and gives me a list of packages that I need to reinstall to get the shared files back if they are missing.
It sounds to me that rpm has a bug. It might be a design flaw, but still a bug.
If it allows two packages to install the same file (it didn't used to), then it needs to maintain a use count. Like for modules.
Only when the use count reaches 0 can a file be removed.
Have you tried your fortunes with bugzilla@RH?
On Tue, 2007-01-23 at 07:13 +0900, John Summerfield wrote:
Johnny Hughes wrote:
It is a headache (IMHO) to have to maintain a bunch of multiple arch RPMS. As I said before, IF you stay with only the 32bit items that are in the official x86_64 repository then you should be mostly fine.
I personally think that the way x86_64 is handled is a buggy kludge (yes, I know I am the maintainer of this $ARCH :P). An example is that if you install an i386 and x86_64 package of the same name ... then remove the i386 package ... some of the shared files (that were identical on install and worked ok) that are in both might be removed. These should stay as the x86_64 package is still installed.
This happens often enough that I wrote a script that figures out what should be there on x86_64 packages and gives me a list of packages that I need to reinstall to get the shared files back if they are missing.
It sounds to me that rpm has a bug. It might be a design flaw, but still a bug.
If it allows two packages to install the same file (it didn't used to), then it needs to maintain a use count. Like for modules.
Only when the use count reaches 0 can a file be removed.
Have you tried your fortunes with bugzilla@RH?
RH is well aware of the problem and I just do not agree with their solution (or even their methodology to get the solution).
This is not just a RH problem either .... it is a multilib arches / package manager dilemma. Same issue at Debian too (just a different package manager). The problem is that none of the package managers handle sharing the same files between packages very well right now.
There needs to be major changes in that area ... and to be honest, I just do not think x86_64 with i386 packages incorporated is ready for prime time in any distro.
Personally, I would only install the x86_64 distro if I was reasonably sure that I would not require i386 RPMS (or minimal i386 RPMS).
I just use i386 on all workstations and I use x86_64 on servers ... and even on servers, only ones that will really be under heavy load or will definitely not need i386 packages.
What are advantages of 64 bit OS anyway? I was thinking with i386 the max RAM you could have was like 4 gigabyte or something? 64 bit allows quite a bit more, right?
I am upgrading a very heavilly used email server to a AMD64 dual core with CentOS. I am staying with i386 since the web GUI we use lists 64bit support as beta and I do not want any problems. The real draw back I see is the max RAM on i386 but perhaps I am wrong. 90 percent of our CPU load is Spamassassin. Disk I/O is likely a big bottle neck as well. Currently we run 2 gigabyte of RAM but will likely move to 4G of DDR2 RAM. Moving from PATA to SATA drives as well.
Matt
On Monday 22 January 2007 17:05, Matt wrote:
What are advantages of 64 bit OS anyway? I was thinking with i386 the max RAM you could have was like 4 gigabyte or something? 64 bit allows quite a bit more, right?
You can have alot of RAM even in a 32-bit system. However, there is also the issue of efficiency and applications being able to actually use alot of memory. Here are some random bits of information on the subject:
* you can have alot more than 4G on 32-bit with pae (hugemem kernels) * ...but, already at ~900M 32-bit has to start using highmem * ...which can cause problems for (old and badly designed) applications already at ~900M * 32-bit EL kernels have 4K kernel stacks, 64-bit has 8K, affects eg. XFS
I am upgrading a very heavilly used email server to a AMD64 dual core with CentOS. I am staying with i386 since the web GUI we use lists 64bit support as beta and I do not want any problems.
Not a bad choice, software functionality is probably one of the biggest differences between 32- and 64-bit.
/Peter
Peter Kjellstrom wrote:
On Monday 22 January 2007 17:05, Matt wrote:
What are advantages of 64 bit OS anyway? I was thinking with i386 the max RAM you could have was like 4 gigabyte or something? 64 bit allows quite a bit more, right?
You can have alot of RAM even in a 32-bit system. However, there is also the issue of efficiency and applications being able to actually use alot of memory. Here are some random bits of information on the subject:
- you can have alot more than 4G on 32-bit with pae (hugemem kernels)
PAE is something of a performance hit in the hardware.
without PAE, most newer architecuture boxes running 32bit will be restricted to 3GB or 3.25GB addressable physical ram, as the top 1GB or 750MB or so is needed for the PCI/PCI-X/PCI-E IO addressing spaces (much like how the original IBM PC 'realmode' systems could only have 640kB and not the theoretical 1MB 8086 addressable memory)
in 32bit, no user process can have more than about 2GB of application address space, with addresses > 2GB belonging to the shared kernel address space.
From where I'm sitting, the mainstream applications that benefits the most from the large address space of 64bit mode are big database servers.
On Mon, 22 Jan 2007 at 11:06am, John R Pierce wrote
From where I'm sitting, the mainstream applications that benefits the most from the large address space of 64bit mode are big database servers.
I'm not sure exactly what your definition of mainstream is, but x86_64 is a huge win for HPC and scientific visualization.
Peter Kjellstrom wrote:
On Monday 22 January 2007 17:05, Matt wrote:
What are advantages of 64 bit OS anyway? I was thinking with i386 the max RAM you could have was like 4 gigabyte or something? 64 bit allows quite a bit more, right?
You can have alot of RAM even in a 32-bit system. However, there is also the issue of efficiency and applications being able to actually use alot of memory. Here are some random bits of information on the subject:
- you can have alot more than 4G on 32-bit with pae (hugemem kernels)
- ...but, already at ~900M 32-bit has to start using highmem
- ...which can cause problems for (old and badly designed) applications
already at ~900M
- 32-bit EL kernels have 4K kernel stacks, 64-bit has 8K, affects eg. XFS
I am upgrading a very heavilly used email server to a AMD64 dual core with CentOS. I am staying with i386 since the web GUI we use lists 64bit support as beta and I do not want any problems.
Not a bad choice, software functionality is probably one of the biggest differences between 32- and 64-bit.
/Peter
Somebody feel free to slap me upside the head if I'm wrong, but as I understand it, you can utilize up to 16GB on the standard SMP kernel. The bigmem kernel allows up to 64GB, IIRC.
I have no idea the RAM limits on the x86_64 kernel. Didn't look.
Peter
Matt wrote:
back I see is the max RAM on i386 but perhaps I am wrong. 90 percent of our CPU load is Spamassassin. Disk I/O is likely a big bottle neck
Are you using spamd?
I ask, because me mate's system was rather busy, and it transpired he wasn't.
Other than extra RAM, AMD-64 CPUs have more registers, and they work best with 64-bit code, so for CPU-intensive work you should see better performance with 64-bit Linux than with 32-bit.
back I see is the max RAM on i386 but perhaps I am wrong. 90 percent of our CPU load is Spamassassin. Disk I/O is likely a big bottle neck
Are you using spamd?
Yes, and it almost always on the top of top.
I ask, because me mate's system was rather busy, and it transpired he wasn't.
Other than extra RAM, AMD-64 CPUs have more registers, and they work best with 64-bit code, so for CPU-intensive work you should see better performance with 64-bit Linux than with 32-bit.
I still doubt if I move to 64 bit since its still considered beta by the web GUI I am using and I have no intention of porting 2000 email accounts plus a few websites to a new platform. Doing a admin/reseller backup and restore is going to be nasty enough. If I initially have 4G of RAM can I actually jump up to 8G later on i386 CentOS?
Matt
On Monday 22 January 2007 08:05, Matt wrote:
I am upgrading a very heavilly used email server to a AMD64 dual core with CentOS. I am staying with i386 since the web GUI we use lists 64bit support as beta and I do not want any problems. The real draw back I see is the max RAM on i386 but perhaps I am wrong. 90 percent of our CPU load is Spamassassin. Disk I/O is likely a big bottle neck as well. Currently we run 2 gigabyte of RAM but will likely move to 4G of DDR2 RAM. Moving from PATA to SATA drives as well.
SATA is better than PATA, but it pales compared to SCSI. Even with SATA, an rsync of a large directory tree can hammer the performance of a server, but with SCSI, it doesn't register enough, on a much busier server, to even notice!
So, evaluate if the $500 for a *good* disk subsystem is actually worth it - in my case, the answer is a resounding.... YES!!!!
On Tue, 23 Jan 2007, Benjamin Smith wrote:
On Monday 22 January 2007 08:05, Matt wrote:
I am upgrading a very heavilly used email server to a AMD64 dual core with CentOS. I am staying with i386 since the web GUI we use lists 64bit support as beta and I do not want any problems. The real draw back I see is the max RAM on i386 but perhaps I am wrong. 90 percent of our CPU load is Spamassassin. Disk I/O is likely a big bottle neck as well. Currently we run 2 gigabyte of RAM but will likely move to 4G of DDR2 RAM. Moving from PATA to SATA drives as well.
SATA is better than PATA, but it pales compared to SCSI. Even with SATA, an rsync of a large directory tree can hammer the performance of a server, but with SCSI, it doesn't register enough, on a much busier server, to even notice!
So, evaluate if the $500 for a *good* disk subsystem is actually worth it - in my case, the answer is a resounding.... YES!!!!
I'm pretty sure this has nothing to do with PATA, SATA or SCSI. Simply disks for SCSI are usually 10k or 15k versions with much smaller capacities in multi-disk RAID setups instead of 4.2k 5.4k or 7.2k PATA/SATA single disks with extreme capacities and smaller on-board buffers.
Vide: my SCSI system has: 192 MB raid card + 6 x 15k 73 GB disks in RAID5 compare that with my PATA/SATA systems which are lucky if they have a 7.2k disk with 8 MB cache.
Maciej (not saying SATA is better, just saying the difference between the two is very small, the difference is not from the protocol, it's from the inherently more expensive and better hardware which is made for SCSI - as a point of fact many of the cheaper PATA/SATA/SCSI drivers have the same internals just different external connectors and possibly differing firmware [different optimizations turned on - for server apps instead of desktop single file streaming])
[plus servers have more RAM on the CPU for disk caching to begin with]
-
Benjamin Smith -
Devraj Mukherjee -
John R Pierce -
John Summerfield -
Johnny Hughes -
Joshua Baker-LePain -
Maciej Ĺťenczykowski -
Matt -
Peter Kjellstrom -
Peter Serwe -
Ted Miller