Moving from 32-bit to 64-bit Fedora

Roberto Ragusa mail at robertoragusa.it
Mon Jun 11 18:40:31 UTC 2012


On 06/11/2012 08:10 PM, Geoffrey Leach wrote:
> I'm currently running a 32-bit Fedora 16 on a 64-bit capable system. I 
> intend to upgrade to a 64-bin install for Fedora 17.
> 
> My way of moving between releases is to install (from DVD), 
> reformatting / and /boot, leaving /home and /usr/local (which have 
> their own partitions) untouched.
> 
> My question is what steps do I need to take to ensure that the 
> necessary 32-bit libraries that I'll need to the stuff I have built 
> locally get installed, or would it be better to just recompile 
> everything?
> 
> Thoughts?

I suppose that things you have manually recompiled din /usr/local
are not critical for the system.
So you could just do the reinstallation in 64bit mode and then
fix the /usr/local stuff.

Try to run the programs; missing libraries will give an immediate
error. You have two choices:
a) just recompile in 64bit mode (probably the best choice);
b) install the 32bit libraries you need.

As regards b), if the error is about a missing libjpeg.so.62,
you can identify the equivalent 64bit (e.g. "locate libjpeg.so.62"
will hint you to "/usr/lib64/libjpeg.so.62"), then discover which rpm
provides them ("rpm -qif /usr/lib64/libjpeg.so.62" will give you
"libjpeg-turbo"), then install the 32-bit equivalent ("yum install
libjpeg-turbo.i686").
Some of the libs will be easy to identify (just have a look
of what lib*i686* you have in a 64 bit DVD, they are probably important
for compatibility).
If you have some difficult ones, not present in the 64bit DVD,
you can as last resort try installing the i686 version coming from
the 32bit Fedora repo (without removing the 64bit ones!).

Anyway... again, just recompile. More speed, more easy.

About keeping /home. If you see something not correctly working
it could be that you have 32-bit specific data files which are badly
interpreted by 64bit apps.
In my recent 32->64 migration I got two of these problems:
/var/tmp/kdecache-* and kdevelop3 files (*.pcs) files.
The binary format was not 32-64 proof; solved by just deleting
them (they were regenerated automatically).

-- 
   Roberto Ragusa    mail at robertoragusa.it


More information about the users mailing list