Is it possible to "upgrade" from a 32bit to a 64bit installation?

As per title, I wish to know if I can, after a successful 32bit setup and consequent software installations, update to a 64bit version.

I know how to partition (actually one of the solutions is to set /, /etc, /home, /var/www, and /opt as separate partitions) and I know that a clean install is way better than a dirty one, yet I would like to know if/how it's possible to do that.

Solution 1:

You will find a clean install a lot less hassle than any other unusual, obscure, unsupported method.

Your suggest of partitioning the config files, home directories, etc is probably the best idea, and it is possible to install the same packages on a clean install as on another install.

On the other hand, what you requested is possible, there is a little guide for Debian based systems but remember "this really is for professional-level sysadmins" and "this procedure is, in every possible respect, a bad idea. If it eats your firstborn, please don't come crying to me"... (so good luck)

Solution 2:

I shall cast raise dead, because this thread is one of the top results for "upgrade ubuntu to 64 bits", and the chosen answer, while admittedly the smart choice, is not the full story.

It is, in fact, possible to upgrade Ubuntu from 32 to 64 bits. You can do it.

I just finished doing such an upgrade.

That said, the words "can" and "should" look nothing alike, and that is also true of an upgrade and a fresh installation. Can you do it? Yes. Should you do it? Eeeeeh...

Upgrading from 32 to 64 bits without explodifying my system took me the better part of a week. Including manually fixing 600+ broken packages in aptitude, because the automatic resolver started looping, apparently due to PERL:i386 (required by installed packages) being incompatible with PERL:amd64 (required by the packages you are trying to install).

This was after I manually installed a bunch of packages, including the correct version of PERL, to fix an apt screwup: you see, apt-get -f install (which is required to get a mostly-working 64-bits system) will uninstall PERL32 in order to install PERL64... Then merrily proceed to try removing 1234 other packages before getting 'round to actually reinstalling PERL. Needless to say, this is not a good idea, when a sizable portion of the apt system (an lots of other things, really) depends on a working PERL.

The reinstallation was performed entirely from console (aptitude FTW, of course), because the console pretty much only requires a working bash (and working curses for aptitude, but if you try to do this, curses will be plentiful, you can bet on it), whereas X requires... Way too much stuff to trust it to keep working while you perform open heart surgery on your system.

All that said, the following Debian article explains how to cross-grade your system:

https://wiki.debian.org/CrossGrading

This is not the same article described in the original accepted answer, because in the mean time things have changed, mostly for the better.

The basics are:

 dpkg --add-architecture amd64

 apt-get update

 apt-get install linux-image-amd64:amd64

 reboot

 apt-get clean

 apt-get --download-only install dpkg:amd64 tar:amd64 apt:amd64

 dpkg --install /var/cache/apt/archives/*_amd64.deb

At which point you will be able to do this:

dpkg --print-architecture 

Resulting in the following line:

amd64

Yay. Ubuntu thinks it's a proper 64-bits system. How cute. You know better, of course.

Now you can run:

apt-get update

This will download the list of all 64-bits packages, which you will need to finish crossgrading your system.

At this point, your system acts very much like nothing happened, except that your ability to install anything is well and truly broken.

You see, you now have multiple i386 packages that don't have an actual multiarch equivalent, so you will be stuck with various technically "unavailable" dependencies. You already have them installed, so your system will run, but at this stage... I wouldn't trust apt any farther than I can throw it.

The article recognizes the need for a fix, and suggests you do so thusly:

 apt-get -f install

This will cause apt to try and fix the ungodly mess you just made. And believe me, you just made an ungodly mess.

One minor hiccup of this procedure is that it will cause portions of the apt system (and other critical subsystems) to be uninstalled partway through, causing errors during the remainder of the process (you don't say), and leaving you up the creek.

Luckily, not without a paddle. You can install the now-missing packages via:

dpkg -i/var/cache/apt/archives/(package)*amd64.deb

Note that, at least for me, the network stopped working at one... Well, several... Points. This was due to apt removing a number of packages that are necessary to keep your network working (such as your dhcp client).

Then, apt cheerfully informed me that it needed to download some additional packages. Without a working network.

If this sounds like you are officially boned... Well, that's because you are.

Unless you have a wired nework (your WiFi packages have already been uninstalled, and WiFI is rather more complicated to get to work anyway), know its configuration information, and are able to use ifconfig, route, etc.

Just keep trying apt-get -f install until you get no more errors.

After apt is satisfied with the state of your system you can run aptitude and manually fix the 600 broken packages you will find. Apparently apt and aptitude have different ideas of what a working system looks like. Don't ask me why.

Also, as I mentioned, the aptitude resolver enters an infinite loop if you try to let it do its thing automatically. Can't blame it, really, it was designed to start on a working system and help the user add or remove some packages, not fix this kind of abomination.

This is the part that took me several days to fix, a little bit at a time, using a different system to occasionally go online and make sure I wasn't accidentally reformatting the family dog.

If all this hasn't discouraged you yet, note that this was my second attempt at a live upgrade.

The first one ended with an mkfs.

Hint, hint, big fscking hint. Or rather, big mkfsing hint.

But again, it actually worked in the end.

The system is running, it mostly uses 64-bits packages (there are a couple of exceptions that I will have to fix eventually), and can run applications requiring a 64-bits installation.

It is possible.

If it's your only option, for whatever reason, you can do it by following the procedure described above - if you have the required domain knowledge.

If you don't know the difference between sync and rsync, if you aren't comfortable with insmod, if you don't know how to use ifconfig, if you don't routinely prefer aptitude to the graphical installer whose name escapes me at the moment... Just make a backup of your data and install from scratch.

It's way less painful, it will save you a lot of time, and it will leave you with a fresh installation, without any unexpected leftovers ready to bite you in the rear 11 months from now.

If you already made a backup of the stuff you don't want to lose, and have no other choice - or just like learning by banging your head against things (particularly the wall)... Well, you can try.

It might even work.

Solution 3:

This might be a much more reasonable thing to do once the multiarch spec is implemented. https://wiki.ubuntu.com/MultiarchSpec -- currently postponed to 11.04, but keep in mind it's been postponed for about 6 releases now. That said, actual progress was made in 10.10, so maybe it'll happen this time.

Until then, don't bother. Backup your data, repartition if you want, and reinstall.