Is there a way to upgrade my 32-bit version of Ubuntu to 64-bit version? I use Ubuntu 9.10.

If there is no simple way, what if I simply copy my home and /etc directories to new installation, will it work?

  • 2
    Hint: use etckeeper on the old system and the new system and after installing all extra packages (dselect and dpkg -l) installed on the old system, merge your changes compared to the dist config files into the new system ;) ... Mar 8, 2011 at 3:11

4 Answers 4


Unfortunately, like other OS's, there is no 'upgrade path' to do this. You'll almost certainly need to do a reinstall.

As for preserving your data, backing up your home directory would be a good idea along with any other data and should be easily imported into your new installation.

Always backup your data before attempting anything!


I wouldn't just copy /etc over in case of slight differences between the configuration requirements for 64-bit compiles of packages, but taking a copy and then diffing the copy against the newly installed 64-but system would work. Chances are the number of changes isn't massive so doing this and making the required changes manually will hopefully be no great hardship.

Copying /etc over as you suggest should work OK though - I would just do it the longer way around for the sake of paranoia. Copying /home, the main area of concern when migrating from one install to another, is more likely to be completely safe.

If you are just looking to move to 64-bit to make use of more RAM rather than because you specifically need to use 64-bit applications then you can just use a 64-bit kernel with a 32-bit userspace. Debian actually provide a64 kernel packages in their i386 repositories, so it can be done as simply as aptitude install linux-image-2.6-amd64, but Ubuntu unfortunately don't so you'd have to compile up your own kernel which might not be worth the time+hassle if you are no that technically experienced (i.e. this is simple, but only if you have compiled your own kernel before so are comfortable with the process). If you do run a 64-bit kernel with a 32-bit userland an individual app can still only access ~3Gb at most (in some cases just ~2Gb), but the system as a whole (all processes together plus the kernel's stuff like IO cache and buffers) can use as much as you have. Each VMWare VM counts as a single app for these purposes - I run one of my older VM hosts this way (the VMs use ~7Gb in total with 64-bit kernel, 32-bit userland and 32-bit VMWare) as it was quicker than a full 64-bit host OS upgrade when I upgraded the machines CPU to a 64-bit capable one and added the extra RAM - I would guess that similar VM solutions would act the same way too.

  • Isn't it the same that using 'linux-image-server' kernel with PAE enabled? Apr 12, 2010 at 18:25
  • It is my understanding that AMD64 based/compatible processors don't need to switch between modes to run 32 bit and 64 bit code together so there isn't extra inefficiency there, and there isn't the memory mapping jiggery-pokery that PAE uses either (32 bit apps just only ever seem to use the lower 4Gb or less of their virtual address space). I could be wrong, but I believe mixing 32 & 64 bit code this way to get the extra addressable RAM is less inefficient than PAE. Apr 12, 2010 at 18:47

I reinstalled my machine from 32bit 10.10 to 64bit 10.10 last month, without losing any data. The only trick is to choose disk resizing tools, not to format the whole disk, when you reinstall the 64bit ubuntu 10.10.

  • +1. Actually I've seen this done, too (Debian and Ubuntu) and it seemed to work flawlessly. Mar 8, 2011 at 3:10

Running a 32-bit userland on a 64-bit kernel is likely to cause problems as soon as system facilities get involved. For example, using the 32bit libalsa on a 64bit kernel will almost work but be quite unreliable and unstable because the ioctl data structures defined in asound.h have different sizes and arrangements when compiled with 64bit and 32bit architectures.

So using jackd -d alsa -X alsaraw (or its jackd2 equivalent) will abort with a failed assertion when calling a 32bit utility on a 64bit kernel. Standard audio operation will be a lot less reliable since buffer counts get interpreted wrong.

In general, any kernel data structures have to be declared in a way where their sizes don't differ between 32- and 64bit kernels, or the 32bit code has to be smart about using different structure definitions in correspondence with the kernel architecture.

So all in all, you are likely better off reinstalling from scratch and transferring your home partition/directory.

  • This was asked (and answered) over 7 years ago. Can you be a little clearer on what new information you are bringing along? Please see How to Answer and take our tour.
    – Burgi
    Jul 26, 2017 at 8:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .