This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!

Feature: System Administration

Upgrade from 32-bit to 64-bit Fedora Linux without a system reinstall

By Ben Martin on January 11, 2008 (9:00:00 AM)

Share    Print    Comments   

One great thing about Linux is that you can transplant a hard disk from a machine that runs a 32-bit AMD XP processor into a new 64-bit Intel Core 2 machine, and the Linux installation will continue to work. However, if you do this, you'll be running a 32-bit kernel, a C library, and a complete system install on a processor that could happily run 64-bit code. You'll waste even more resources if your new machine has 4GB or more of system memory, and you'll be forced to either not use some of it or run a 32-bit Physical Address Extension (PAE) kernel. Cross-grading to the 64-bit variant of your Linux distribution can help you use your resources more wisely.

This happened to me with a Fedora Linux installation, and I finally decided to migrate. Over the years, I've talked to Fedora enthusiasts and Red Hat employees at Linux conferences about doing a cross-grade to 64-bit. I generally heard one solution: reinstall. However, I like to reserve this approach for when a critical number of system disks fail at once and I have absolutely no other option. I wanted to see if a cross-grade was feasible at a whole distribution level.

A disclaimer: changing the architecture of your Fedora installation from 32 to 64-bit isn't recommended or supported in any way. Perform this at your own risk after creating a suitable backup.

As a test, I installed Fedora 7 i386 in a VMware server instance, then modified the CPU architecture of the hosted virtual machine to be 64-bit. I then booted the virtual machine from the Fedora 8 x86_64 DVD image. After I selected the option to upgrade an existing Linux installation, the installer warned me that my existing install and the DVD were for different architectures. The warning was ominous, along the lines of "don't do this." I dismissed the warning; the upgrade proceeded, and I rebooted the virtual machine as normal. Everything still seemed to work in the virtual machine after the cross-grade. With that success, I then moved on to the real thing: cross-grading a real live system.

If you tackle this task, I recommend using something like Clonezilla to create a full system backup. That way, if the cross-grade doesn't go well, you can quickly revert to the way the system was before you attempted the migration.

I also recommend downloading all the RPM files you might need before you begin. If you mirror the Fedora 8 Everything directory and the updates directory, you'll download more than you strictly need, but once you're in the throes of upgrading, the last thing you want is to wait for 600MB of data to download. The DVD image, Fedora-8-x86_64-DVD.iso, is 3.7GB, the Fedora 8 Everything directory for x86_64 is 12GB, and the updates directory for x86_64 is 3.2GB, as of December 2007. Use the following script to grab the Everything directory and set up a local yum repository for it. You need to change the URL for wget to your fastest Fedora mirror. Creating yum.repo files for the new local repositories allows you to use them in preference to the default fedora.repo and fedora-updates.repo files. Note that /yum-repo-mirrors should be a large enough partition to contain all this data:

# cat #!/bin/bash mkdir -p /yum-repo-mirrors/f8everything cd /yum-repo-mirrors/f8everything wget -Y off -m "ftp://mirror.../pub/fedora/linux/releases/8/Everything/x86_64/os/Packages/" cd /yum-repo-mirrors/f8everything nice createrepo `pwd` /etc/yum.repos.d]# cat f8everything.repo [f8everything] name=Fedora $releasever - $basearch baseurl=file:///yum-repo-mirrors/f8everything/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora

Updating a real installation

Once I downloaded all the packages and made a solid system backup in preparation, I booted the Fedora 7 i386 machine from the Fedora 8 x86_64 DVD. If you're running database servers, dump them to a text SQL file to back them up before the update. Also, anything using a native binary on disk format might be susceptible to changes from 32-bit to 64-bit.

Initially, the upgrade complained about /usr/tmp not being a correct symlink. It turned out that I was using the XFS filesystem for /usr, and in /etc/fstab I list the filesystem type as auto. The Fedora 8 DVD didn't like this and failed to mount /usr. Changing the filesystem type to xfs in /etc/fstab fixed this issue.

The upgrade warned me about the different architectures, and I proceeded just as I did in the virtual machine. For some reason, the installation didn't want to upgrade GNU GRUB for me. I chose to leave the old boot configuration in place and fix that later.

After the update finished, I rebooted. The new kernel was listed in GRUB, and I selected and booted it. I'm not sure what caused the problem with updating GRUB, but at least it presented no bar to booting.

Initially, I had issues getting audio to play. Fedora 8 has moved to PulseAudio, and it wasn't working as it should. To fix things, I added my user to the pulse-access group and made sure that the PulseAudio daemon was running by adding pulseaudio -D to my ~/.xinitrc file. Also, some of the media players didn't work properly, mainly because the system libraries updated to new versions and the media player executables were looking for a shared library that was no longer there. But this issue was not specific to the 64-bit cross-grade and would have been there if I updated to 32-bit Fedora 8.

One area in which I expected the update to cause problems was with the differing size of integers. If an application stores its state in a binary file by dumping and loading the contents of RAM directly, then such 32-bit configuration files wouldn't work under the 64-bit installation. Applications using boost::serialization in binary format suffered from the update, so I had to fix them manually.

At this point, my system had an odd mix of i386 and x86_64 RPMs on it. Most of the devel RPMs were only for i386, because the updates weren't included on the Fedora 8 DVD. Also, an RPM file will likely still report that it is running on a 32-bit machine. Here's the initial report from RPM as to what architecture it was running on before and after removing the i386 RPM packages:

# rpm --eval '%{_arch}' i386 # rpm -e rpm.i386 rpm-python- rpm-build- # rpm --eval '%{_arch}' x86_64

Once both i386 and x86_64 packages were installed, I told RPM to report which architecture each package was compiled for, so I could easily tell what still needed updating and what could be removed:

# vi /etc/rpm/macros %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} %_query_fmt %%{name}-%%{version}-%%{release}.%%{arch}

You may also have to update the rpm platform file so that rpm and yum to pick x86_64 packages by default.

# cat /etc/rpm/platform x86_64-redhat-linux

Because I had a mix of i386 and x86_64 packages installed, I needed to use yum's exclude option. Generally, specifying the foo.x86_64 RPM explicitly tells yum to install the 64-bit dependencies as well:

# yum install --exclude="*.i386 *.586 *.686" foo

At this point, I noticed that a partition wasn't being mounted anymore. A look at /etc/fstab showed that the update had cleaned up this file and removed anything it didn't understand, including a partition I had with a filesystem type auto. This was annoying, as I had many comments in /etc/fstab and some filesystems mounts that were commented out. I had to manually merge the new /etc/fstab with the one from my backups (you made backups, right?).

The cross-grade's cleaning up fstab also broke /dev/shm, the shared memory device. I had four filesystems mounted as tmpfs types for various uses. The cleanup only kept the first tmpfs filesystem, which didn't happen to be the /dev/shm one. Without /dev/shm mounted as tmpfs, shared memory didn't work.

To make the cross-grade legitimate, I updated the i386 devel packages and also included the new updates from the Fedora 8 updates repository. Here I had to do some package tinkering by hand. A simple yum update tried to resolve dependencies and reported about 25 libraries that were broken. Most of the time, you can fix this by doing an RPM -e package.i386 followed by a yum install package.x86_64. Sometimes the Fedora 8 x86_64 distribution ships with both an i386 and an x86_64 RPM for a package. Incompatibilities can exist between the Fedora 7 i386 RPM and the newer x64 RPMs. For example, the following code shows incompatibility for CinePaint. You can resolve this either by removing the package or by moving to the local repository mirror directory and force-updating the package to the newer version:

file /usr/lib/python2.5/site-packages/gimpui.pyc from install of cinepaint-0.22.1-5.fc8 conflicts with file from package cinepaint-0.22.1-4.fc7 ...

Some of the few packages that behave this way include koffice-krita, NetworkManager, mono, gstreamer, and ruby. I fixed the Mono and GStreamer issues by updating their i386 RPMs to the Fedora 8 RPM files manually with the rpm command.

A subsequent attempt to yum update reported a total download size of 339MB, but during the transaction test, it failed again with some incompatible files. You can fix some of these clashes by removing the i386 version of the incompatible RPM from the system, leaving only the x86_64 RPM installed. In the case of i386 packages with large dependency trees, such as gnome-keyring, gphoto2, nas, and openldap, a better approach is to force-update the RPM file from the Everything or updates repository mirror. By force-updating the package, you remove the path clashes, and yum happily updates the rest of the system.

When crossgrading a second system, I used commands similar to the following to make sure that x86_64 versions of all development packages were installed before removing the i386 packages. Once there are no i386 development packages, running the rpm query again and making sure that there are also x86_64 versions of every package installed is a good idea.

# cd /tmp # rpm -qa --queryformat '%{name}.%{arch}\n' |grep i386 >| /tmp/i4 # yum install $( grep devel /tmp/i4|sed 's/.i386/.x86_64/g' | tr '\n' ' ' ) # yum remove $( grep devel /tmp/i4 | tr '\n' ' ' )

You will also want to add lib64 to the shared library's search path.

# cat /etc/ /usr/local/lib /usr/local/lib64


Updating from Fedora 7 i386 to Fedora 8 x86_64 isn't supported, and many folks will tell you to just reinstall in order to move to a 64-bit Linux. However, I managed to resolve the main problems when doing a yum update in a single day. Your mileage will vary depending on what third-party repositories you're using, how much software you've installed by hand, and how dependent your software is on the system libraries.

Ben Martin has been working on filesystems for more than 10 years. He completed his Ph.D. and now offers consulting services focused on libferris, filesystems, and search solutions.

Share    Print    Comments   


on Upgrade from 32-bit to 64-bit Fedora Linux without a system reinstall

Note: Comments are owned by the poster. We are not responsible for their content.

Upgrade from 32-bit to 64-bit Fedora Linux without a system reinstall

Posted by: Anonymous [ip:] on January 14, 2008 03:32 AM
Talk about making something complicated! I upgraded Kubuntu from 32-bit to 64-bit on an AMD64 system and it took me only 1-1/2 hours, from start to a complete finished system, including all the downloading from the internet for stuff not on the CD, the latest nVidia proprietary driver (via Envy, which I keep on my home partition-- I did have to upgrade to the latest Envy script, which I was prompted to do when I clicked on the old one-- it was automatic after that) and all the codecs necessary to play movies, listen to music MP3s, etc.. I do have a DSL connection which delivers between 1.5 MB and 6.0 MB depending on what time of day it is. I did it during mid morning hours, after 9 am. I started by formatting my OS partition (I have a separate /home partition, which I never format for a new upgrade) and installing everything from scratch with the Gutsy Gibbon 7.10 Kubuntu Alternate CD (not the live CD) and when I finished, everything worked perfectly. I cannot imagine spending an entire day doing this. With Kubuntu, I have NEVER had to spend more than an hour or two upgrading, and everything always works. If doing it WITHOUT a system reinstall takes a whole day, I'd rather do it with a clean install in 1-1/2 hours, and be done with it. All of my hardware was fully recognized, including my nVidia (on the motherboard) chip, and there were absolutely no hitches whatsoever. Even all of my passwords for accessing websites were still intact. My user and administrator passwords were the same as before the install, because I typed them in during the OS installation, as prompted.


Nautilus Problem with fedora 7

Posted by: Anonymous [ip:] on January 14, 2008 04:45 AM
Hello ,
This site really helps me lot.
I have some problem my machine is very slow now a days.
I checked with command 'top', it is displaying 102% of cpu usage by nautilus.
Please sole my problem and response at
Thanks and regards,
Shaili Vaish



Posted by: Anonymous [ip:] on February 01, 2008 04:14 PM


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya