Cross-grading from i686 to x86_64: it is possible (but unsupported)

[Roberto Ragusa]

Hi,

after reading a lot of advice about not doing it, and only a couple
of reports from guys who did it, I finally decided to try to
cross-grade my Fedora installation from i686 to x86_64.

Everyone says you should just reinstall; they probably do not
value their customizations. My system has been upgraded from Fedora
Core 3, and has been moved on a multitude of different hardware.
Preserving /home, /usr/local, /opt, /etc is still not enough,
you then have to be sure everything you had installed is there
again: big job (maybe you do not have the installation package
anymore).

I can't describe all the details for the cross-grading, but I want
to try to be helpful for others wanting to try that.

The transition was a F14-i686 to F14-x86_64 (end-of-life!).
On a second step there will be an upgrade to F15 and F16.

The system had many rpms from additional repos (fusion, atrpms,
java-sun from jpackage, a few rpms from some vendors).

The system was running the latest x86_64 (!) kernel for F16 (!!) .

For the record: running an x86_64 kernel instead of the i686.PAE
works perfectly, and it is better for speed and stability (why Fedora
did not push this feature I do not know). I also discovered that
running a F16 kernel on F14 is OK; yum complains about some dependencies
(module-init-tools, IIRC), but it solved some hibernation issues.

FIRST STEP: TOTAL FILE-LEVEL BACKUP OF THE SYSTEM (rsync to another machine;
this is a habit for me)

I've actually done the migration by yum in a graphical shell. (!)
So we already have collected a good quantity of "no, do not do that"
things. :-)

The most difficult part came now.
I wanted to start installing x86_64 stuff in parallel to i686 and
it was not exactly clear to me on what base rpm and yum decide the arch.
The final trick was, IIRC, just install rpm.x86_64; it appears to
contain the "info" about the running architecture. Some things
were required to be installed at the same time (mostly glibc).
I had a complete local mirror of F14 packages to avoid going to the network.

The "file `which rpm`" command started to say that it is an ELF64,
so I moved to yum. This is more complicated because it takes some
Python dependencies with it.
I repeated tried "rpm -ihv --test" and added more and more dependencies
on that command until it succeeded. Then "yum clean all".

In this phase I discovered that if you have a 64bit rpm and a 32 bit yum
the rpm database gives you strange errors. Every time you switch
from one tool to another the database appears to be corrupted, but it
isn't. The solution is to just remove a few tmp files: see RH bugzilla 553998.

At this point I started to use yum to install x86_64 stuff.
Started with small things (grep, bash), then moved to things with more
dependencies and then started to involve heavy things (for example, evince
will drag some GNOME, and so on). As I was running KDE, I used the GNOME
desktop as a guinea pig. :-)
Having both i686 and x86_64 version fails in some cases because the shared
files are not identical. I had to remove the i686 version in some cases and
just install the x86_64 one. Some "rpm -e --test" and "rpm -e --nodeps" were
necessary to understand how big was the risk of breaking the system at every
step.

A really big issue: i686 rpms from atrpms which I was not able to move to x86_64
because the f14-atrpms repository has been deleted from the net. Aaaargh.
Only a couple of stale mirrors were still there, I catched everything from them,
and also had to downgrade versions or remove some stuff and take a note of
reinstalling it later (maybe on F15). Why doesn't atrpms have an archive
repository like fedora???

For safety, I installed the rpms for KDE by logging in via ssh. The kde environment
was still running and it was unaffected by the process, anyway.

Some bash tricks involving "rpm -qa", "grep" and "yum install" took care of
installing as much as possible as x86_64, removing i686 when necessary to resolve
(apparent) conflicts.
It is fun to see there are -devel packages for both archs.
At the end I had an almost completely biarch system.

So.... reboot. (No change to grub, the kernel is still f16 x86_64).
The boot goes well.
X doesn't start: no driver. I had a /usr/lib path in /etc/X11/xorg.conf, which I had
to replace with /usr/lib64. Solved.
But KDE doesn't start. Hmmm. GNOME does, XFCE does, fluxbox does.
After some deep investigation, the solution was to just remove the content of
/var/tmp/kdecache-*, which is probably saved in an architecture dependent format.

As a cleanup, I started to remove i686 stuff. My idea is to only keep some
libs for compatibility with i686 only applications.
Started doing some of the work manually (yum remove and be sure you are only removing
stuff you have on x86_64 too).
Then wrote more bash one-liners: list all the rpms, find everything i686 which is not
dependent on anything else and exists in x86_64 format too; remove the i?86.
Repeat it a few times to escalate deeper in dependencies.

Target reached: more than 3000 rpms, all x86_64 and a few i686 dragged here by
vendor's rpm only available as i386 (mostly some GNOME libs). KDE completely
switched to x86_64 and running great.
Rebuilt the jpackage java-sun rpms so the JVM is 64bit now.
Removed 32bit kernels, now useless.

The entire process took me a couple of days, mostly because I had to research things
and decide my strategy at every step. The hardware was powerful and SSD based, so
the disk operations were quite fast.
The system appears now faster.
The only issue I've seen so far is the HTML validator extension for Firefox
complaining about having 32bit internal libs, while wanting 64. Will fix that.

Some web pages say you can do everything in a single step through yum.
I don't know, maybe I've been more prudent and step-by-step than necessary.
Certainly I've learned a lot doing it. And had some fun with bash.

The robustness of the system, while modifications to its roots were happening,
was incredible. I switched from glibc f14 to glibc f15 and back a few times
(to try to use f15-atrpms to fill in missing x86_64 packages) and everything
still worked.
Great job: Linux, Fedora, rpm, yum, and all the rpm packagers.
I can't imagine to attempt that on any other operating system.

(backupped everything and upgrading to F15 and F16 x86_64 right now)

-- 
   Roberto Ragusa    mail at robertoragusa.it