I've got a 32-bit Ubuntu installation running on 64-bit hardware. Now that multi-arch has been implemented, I would like to switch to 64-bit without having to reinstall the OS.

This is one of the user stories addressed by the spec:

Shawn installed his system using the 32-bit version of Ubuntu, but his hardware is 64-bit and he wants to switch over. He manually installs the amd64 versions of dpkg and apt, replacing the i386 versions and changing which architecture is used as the default; then he installs the amd64 ubuntu-minimal package; then he installs the amd64 ubuntu-desktop package. Over time the remaining i386 packages are replaced automatically on upgrade.

However, when trying to follow the instructions in there, I cannot find any 64-bit version of dpkg or apt.

Did this user story got implemented in a different way in the final spec, or do I need to do something differently?

In short, how can I switch my 32-bit installation to 64-bit?


12 Answers 12


Such an approach is very complicated, and is unlikely to ever result in all your packages being the amd64 version instead of the i386 version. Only packages that actually receive upgrades will likely be changed in architecture, and probably only if no other packages not being upgraded rely on their being of the i386 architecture. Since some packages will not receive any updates throughout the entire support cycle of your Ubuntu release, you will likely never have a fully amd64 system using such a technique. Furthermore, there is certainly no official support for such an approach.

You would be well-advised to instead replace your existing Ubuntu system with a new, 64-bit installation.

However, if you do wish to attempt this technique, you will have to manually download the .deb files for dpkg and apt. You can find them at the dpkg in Ubuntu and apt in Ubuntu pages on Launchpad--expand the latest version under "The Oneiric Ocelot" that is marked as release, security, and/or updates (but you probably don't want a version marked only proposed and/or backports, if there ever is one). Then download the .deb files marked amd64. Specifically, the files you'll want are: this one for dpkg (and the others listed, too, if you have those packages installed) and this and this and this and this and this for apt.

Before you do anything with these files, you should make sure to back up all important documents in your installed Ubuntu system and any other important files (e.g., music, ebooks, videos), because it is rather likely that attempting this technique will backfire badly and leave your Ubuntu system completely unusable.

You can install all these packages by putting them in a folder that contains nothing else (suppose the folder is called debs and is inside your Downloads directory), and then running this command:

sudo dpkg -Ri ~/Downloads/debs

Of course, once you've installed them, they won't actually run, because their executables are 64-bit and your 32-bit Ubuntu system is running a 32-bit kernel (which will only run 32-bit executables). In fact, they might not even finish installing, as they might have post-install scripts that invoke their unrunnable 64-bit executables.

There are various ways of attempting to install a 64-bit kernel onto a 32-bit system, but they are all extremely complicated, so instead I recommend that you boot from a 64-bit Oneiric live CD (which itself runs a 64-bit kernel), chroot into the installed Ubuntu system, and use the recently installed 64-bit apt and dpkg to install a 64-bit kernel.

Here are specific instructions for doing that...but please do not take this to mean that I'm saying it will work. I have not attempted this. (I have chrooted into installed Ubuntu systems from live CD's and performed package management and other operations, but I have not attempted the cross-architecture operations suggested here.)

  1. In your installed Ubuntu system, open a Terminal window (Ctrl+Alt+T) and run mount | grep ' on / ' (by pasting it into the Terminal and pressing enter). You should see something like /dev/sda2 on / type ext4 (rw,errors=remount-ro,commit=0). The part you're interested is the device name before on (in this example, it's /dev/sda2). Remember that, or write it down.

  2. Step 1 gave you the device name of the / partition. If you have a separate /boot partition, then you'll need to know the device name for that as well. So in that case, run mount | grep ' on /boot '. You'll see something like /dev/sda1 on /boot type ext2 (rw). Remember or write this down as well.

  3. Boot from an Oneiric amd64 (i.e., 64-bit) live CD and select "Try Ubuntu" rather than "Install Ubuntu".

  4. Go into a web browser and make sure that Internet connectivity is fully functional. If it isn't, set it up.

  5. Open a Terminal window and run sudo mount /dev/sda2 /mnt (replace /dev/sda2 with the device name you got in step 1, if different).

  6. If your installed system has a separate /boot partition, run sudo mount /dev/sda1 /mnt/boot (replace /dev/sda1 with the device name you got in step 2, if different).

  7. Now, run these commands to chroot into your installed system:

    sudo mount --bind /dev /mnt/dev  
    sudo chroot /mnt  
    mount -t proc none /proc  
    mount -t sysfs none /sys  
    mount -t devpts none /dev/pts  
  8. Run ping -c 4 launchpad.net to see if Internet connectivity works fully from within the chroot. You're hoping for something like this:

    PING launchpad.net ( 56(84) bytes of data.
    64 bytes from launchpad-net.banana.canonical.com ( icmp_req=1 ttl=41 time=141 ms
    64 bytes from launchpad-net.banana.canonical.com ( icmp_req=2 ttl=41 time=143 ms
    64 bytes from launchpad-net.banana.canonical.com ( icmp_req=3 ttl=41 time=142 ms
    64 bytes from launchpad-net.banana.canonical.com ( icmp_req=4 ttl=41 time=140 ms
    --- launchpad.net ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3003ms
  9. If, instead, you were unable to transmit or receive packets, then you'll have to set up Internet connectivity in the chroot. To do that, run these commands (to leave the chroot, copy the relevant configuration files from the live CD system into the chroot, and re-enter the chroot):

    sudo cp /mnt/etc/resolv.conf /mnt/etc/resolv.conf.old  
    sudo cp /mnt/etc/hosts /mnt/etc/hosts.old  
    sudo cp /etc/resolv.conf /mnt/etc/resolv.conf  
    sudo cp /etc/hosts /mnt/etc/hosts

    While generally you should stop this process if there is an error, don't worry if the first and/or second of those four commands fail, provided that the specific way in which it fails is by telling you that /mnt/etc/resolv.conf (or /mnt/etc/hosts) does not exist.

    The chroot back in and try again:

    sudo chroot /mnt  
    ping -c 4 launchpad.net  
  10. Run these commands to make your chrooted environment fully ready to use:

    export HOME=/root  
    export LC_ALL=C  
  11. If you haven't installed the .deb files for the 64-bit versions of dpkg and apt, so do now. If you did install them but there were configuration errors, run dpkg --configure -a to fix them. (Hopefully that will work...it might be better to wait to attempt to install them until you're in the live CD environment, in case installing the 64-bit dpkg while booted into the installed system leaves dpkg in an unusable state.)

  12. With the 64-bit versions of dpkg and apt installed, assuming that they will automatically install 64-bit packages, you can now remove all your 32-bit kernels and install a 64-bit kernel. To remove your 32-bit kernels, run dpkg -l | grep linux-. This lists installed packages that start with linux-. You're more specifically interested in packages that start like linux-generic, linux-image, linux-server, and/or linux-headers. Remove these files with apt-get purge ... where ... is replaced with a space-separated list of the packages you're removing.

  13. Now reinstall the packages you removed. (Actually, for packages that contain version numbers in the package name, like for example linux-image-3.0.0-13-generic, you only need to install the latest versioned package names.) Do this by running apt-get install ... where ... is replaced with a space-separated list of the packages you're installing.

  14. Update the boot loader configuration, unmount some devices, and leave the chroot:

    umount /proc || umount -lf /proc  
    umount /sys  
    umount /dev/pts  
    sudo umount mnt/dev  
  15. If you ran sudo cp /mnt/etc/resolv.conf /mnt/etc/resolv.conf.old and it did not fail, then now run sudo cp /mnt/etc/resolv.conf.old /mnt/etc/resolv.conf.

  16. If you ran sudo cp /mnt/etc/hosts /mnt/etc/hosts.old and it did not fail, then now run sudo cp /mnt/etc/hosts.old /mnt/etc/hosts.

  17. If your installed system has a separate /boot partition, unmount that: sudo umount /mnt/boot

  18. Unmount your installed system's / partition: sudo umount /mnt

  19. Leave the Terminal window (run exit), then reboot (or shut down) the live CD system and boot into the installed system.

  20. See if the system is usable and running a 64-bit kernel (uname -m should say the architecture is x86_64).

There might well be additional packages you need to install, such as ia32_libs and/or the 64-bit version of libc6, for this to work. For some of them, you might be informed you need them when attempting to install the 64-bit version of dpkg and/or apt. For others, you might not be informed.

(The above instructions for chrooting and operating in the chrooted environment are based in significant part on this related but different procedure and also on some Launchpad Answers posts of mine, especially #6 here and #6 here. And special thanks to Caesium for pointing out that the 64-bit dpkg and apt executables won't run on a system running a 32-bit kernel.)

  • 2
    Will those binaries run under a 32bit kernel, Eliah?
    – Caesium
    Nov 22, 2011 at 19:55
  • @Caesium Good call. Of course not. I'd edit my post to indicate how to get the 64-bit kernel running...except that I have no idea how to install a 64-bit kernel package on a 32-bit Ubuntu system (running on 64-bit hardware, of course) when apt and dpkg are still 32-bit and will (presumably) refuse to install a 64-bit kernel package. (Building the kernel from source, and using cross-compilation, would work, but this is very complicated and I don't want to recommend it. I'm sure there's a better, easier way. If you know it, please feel free to edit my or your post or comment about it.) Nov 22, 2011 at 19:59
  • @Caesium Actually, I think I do know how to get the 64-bit kernel installed. I'll edit my post shortly to reflect this. Once I do, if you feel like my proposed technique would work, please feel free to copy and/or paraphrase it into your answer...or, alternatively, so long as both the info in your answer that's not in mine and the info in my answer that's not in yours are preserved, you could combine our answers into a single answer. (It could be your answer--that's fine with me. You did post a bit before I did. Then I'd delete my answer.) Nov 22, 2011 at 20:02
  • @Caesium Edits completed; I look forward to your comments. Nov 22, 2011 at 20:58
  • Wow, nice work :) At this point you've put far more effort in than me so I wouldn't dream of copying into my answer, yours should remain for the credit. It does drift away from the original aim of using the multiarch technology but I'll be interested to hear whether it works nonetheless :) Guess we'll have to wait for the original poster :)
    – Caesium
    Nov 22, 2011 at 21:03

As given above, I did:

echo foreign-architecture amd64 | sudo tee /etc/dpkg/dpkg.cfg.d/multiarch
sudo apt-get update
sudo apt-get install linux-image:amd64
sudo apt-get install gcc-multilib
sudo update-grub

It worked. I am able to run my 32-bit userland with 64-bit kernel, in Ubuntu 12.04.

  • 6
    This answer rocks. I can confirm it still works with saucy. The one difference is that the procedure of adding an architecture has changed: use sudo dpkg --add-architecture amd64 instead. It will yell at you if you do it the other way. I needed to do this so I could chroot into a 64 bit installation from a (previously) 32 bit one and it worked exactly as expected with no hitches.
    – Wug
    Jan 10, 2014 at 10:22
  • I tried this on Mint, but I'm having some problems, did you do anything else? Details: superuser.com/q/927830/150718 Jun 28, 2015 at 11:16
  • 1
    In addition to Wug's change, you also need to use linux-image-generic:amd64 on Ubuntu 16.04. It worked fine for, even without the last two commands.
    – qznc
    Mar 17, 2017 at 12:24

Although the question is similar to Is it possible to "upgrade" from a 32bit to a 64bit installation? (If you have not read it before I encourage you to try it. The answer provided there is good.) I also recommend reading the following links:

For better performance should I install 32-bit or 64-bit?

How can I switch a 32-bit installation to a 64-bit one?

What are the differences between 32-bit and 64-bit, and which should I choose?

Is it possible: Yes

Is it easy: NO!

If your issue is with memory, then you should know that Ubuntu 32 Bit can read more than 4GB of RAM (Up to 64 GB). So using the latest Ubuntu 32 Bit version with a computer that has 32 Bit or 64 Bit architecture and putting in more RAM will not be a problem. It will simply read the extra RAM and work.


These answers are somewhat outdated. Cross-grading is now documented for Debian on the Debian wiki, but it's still not recommended.

Installing a kernel from a different architecture is now as easy as described there, but the new 'apt' won't recognise packages from a previous architecture, and so all its front-ends may report lots of broken packages. This either requires changing all dependencies to the other architecture, or reverting apt and dpkg to 32-bit.

So the best approach may be to first save results of dpkg --get-selections, strip :i386 from that, and download an amd64 package for each of the dependencies to the cache:

apt-get --download-only install perl:amd64 python3:amd64 python3-gi:amd64 xorg:amd64...

At best it's likely to be slow and time-consuming resolving the dependencies.


These instructions make your system boot with a 64-bit kernel but does not change most of the userland programs.

After upgrading my system with 64-bit CPU, I also wanted to install a 64-bit kernel on my 32-bit 14.04.2 Ubuntu (codename: Trusty). To do this I entered the following commands as root user:

dpkg --add-architecture amd64   
apt-get update
apt-get install linux-generic-lts-utopic:amd64


  1. This might remove your 32-bit kernel as trusty - by default - ships with an updated kernel (the kernel from utopic), see 14.04 Release Notes. In this case your current kernel conflicts with the 64-bit kernel to-be-installed and therefore gets removed. If you do not like this idea, you might want to try the older 64-bit kernel package "linux-generic-lts-trusty:amd64" instead.

  2. The "--add-architecure" command is essential. Without it, the package system does not support packages from different architectures, see Multiarch-HowTo

  3. To see what apt-get will do to your system, run it with the options -Vs which enables "verbose simulation mode". This will print all packages to be installed and removed.

  4. Whether you system boots using the new kernel depends on the grub configuration. As root user, run update-grub to make grub update and print the current boot configuration. The first image in the list will be booted as default.

  5. To select a different kernel image, I removed the line GRUB_HIDDEN_TIMEOUT=0 from /etc/default/grub and ran as root user update-grub. At boot time, you can now select a different kernel (you've got 10 seconds to hit any key otherwise grub will continue with the default kernel).

  6. The answer with the top most votes is from 2011 and is hopelessly outdated in my opinion. Multiarch lets you install library packages from multiple architectures on the same machine without much ado.

  • That's a nice simple advice that almost worked for me on 14.10 (Utopic) (however I did apt-get install linux-generic:amd64 which mustn't be very important for the experiment)! If I go through the "rescue" boot option, the system runs, but X doesn't use nouveau video driver and stuff. If I boot normally, the startup breaks at some point and the system reboots. (But the very first time, I was able to boot successfully.) I'm not sure whether the problem is with the video driver during the "normal" boot or something else. Sep 9, 2015 at 1:57
  • The video driver and X turned out to be not (statistically) related to my crashes/reboots with the amd64 kernel. It's just a mystery as for now -- bugs.launchpad.net/ubuntu/+source/upstart/+bug/1495116 . Sep 12, 2015 at 16:28

Update: I completed a script for upgrade Ubuntu 18.04 from i386 to amd64 at https://raw.githubusercontent.com/muwlgr/scripts/main/upgrade-lubuntu3264.sh , please review and test

(answer for older Ubuntu is kept below -- )
My recipe for Ubuntu 16.04 Xenial, tested on freshly-installed 32-bit Ubuntu VM with standard system and SSH server but without GUI :

sudo -s
dpkg --get-selections > pkg1
dpkg --add-architecture amd64
apt update
apt install linux-image-generic:amd64 thermald 

(else it would install thermald:amd64 and fail to restart it under 32-bit kernel)


after rebooting with 64-bit kernel :

sudo -s
unset LANG
apt install apt:amd64 apt-utils:amd64

type 'Yes, do as I say!' when asked, it is going to be safe

mkdir /tmp/upgrade 
cd /tmp/upgrade
pkgs() { dpkg -l | awk '$4=="'$1'"{print $2}' | awk -F: '{print $1}' | sort -u
apt download $(comm -23 <(pkgs i386) <(pkgs amd64))
while ls *amd64*deb
do dpkg -i *amd64*deb
   dpkg -l | awk '$1=="ii" && $4=="amd64" {print $2}' | awk -F: '{print $1}' |
   while read a
   do [ -f ${a}_*amd64*deb ] && rm ${a}_*amd64*deb

in the loop above, we remove .deb files which have been successfully installed and got 'ii' status in the dpkg list.

we need to repeat dpkg -i runs, as it does not succeed from the very first attempt


now, with both 64-bit kernel and userspace, remaining i386 packages can be removed :

dpkg --purge $(dpkg -l | awk '$4=="i386"{print $2}')

the list you have saved in pkgs1 file you can use for any your further needs.

  • That's kind of magic, but it helped me to do 32 to 64 bit transition via SSH on remote pc.
    – fresher_tm
    Feb 24, 2018 at 21:24

Perhaps, as I face the same problem, this will work, it is what I was planning to do:

Obtain a 64-bit version of the OS, install into a partition, when complete copy the documents and other stuff from the 32-bit install, when everything is safely copied you can format the rest of the drive and use it.


Yeah, the foreign-architecture line is most definitely vital for installing ANY cross-arch packages. But after that, do as several other users mentioned:

sudo apt-get update
sudo apt-get install linux-image:amd64
sudo apt-get install linux-modules:amd64
sudo init 6 #reboot into new kernel
sudo apt-get install apt:amd64
sudo apt-get install ubuntu-desktop:amd64

That should just about do it...

  • did you try it? it doesn't really work, i get problems once it starts replacing dpkg and perl by their amd64 counterparts Jun 6, 2014 at 16:17

Good question. I have had a hunt around and other than the user story you quote, I can't find any details on how to do this. All the documentation indicates it's only for running 32-bit applications on an already 64-bit OS.

However, if you're willing to experiment, you could try the following (derived from my link at [1])

 echo foreign-architecture amd64 | sudo tee /etc/dpkg/dpkg.cfg.d/multiarch
 sudo apt-get install linux-image:amd64

I think you will have to start off with an amd64 kernel, as the 32-bit one won't be able to run any 64-bit binaries. However the 64-bit one should run 32-bit binaries (if ia32-libs is installed?).

If you get the 64bit kernel installed and booted, you can go from there to install apt:amd64, then follow the user-story as previously quoted, ubuntu-minimal, ubuntu-desktop, etc.

After apt:amd64 is installed, I think you can remove the foreign-architecture line since you have essentially switched over at that point.

Disclaimer: I have no 32bit system to test so this is all guesswork. Good luck!

[1] https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview/Beta1#Improved_handling_of_32-bit_compatibility_on_amd64_systems


Crossgrading (upgrading to a different architecture) isn't supported yet.


To add to the excellent answer of @Wladimir Mutel, the only sane and working one. I was trying to do this with Linux Mint, but got unmet dependencies error at the apt installation stage. So the process was to convert it to Ubuntu first, then update to next Ubuntu release in my case.

Then everything went smoothly with apt installation. But the most important thing, is I was getting errors on the stage of uninstalling old packages. Specifically I couldn't uninstall dash:i386 (and its dependencies).

Preparing to unpack .../dash_0.5.8-2.10_amd64.deb ...
Ignoring request to remove shared diversion 'diversion of /bin/sh to /bin/sh.distrib by dash'.
dpkg-divert: error: 'diversion of /bin/sh to /bin/sh.distrib by bash' clashes with 'diversion of /bin/sh to /bin/sh.distrib by dash'
dash.preinst: dpkg-divert exited with status 2
dpkg: error processing archive /var/cache/apt/archives/dash_0.5.8-2.10_amd64.deb (--unpack):
 new dash:i386 package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

To solve this, I ended up first removing /bin/sh and /bin/sh.distrib (both symlinks of /bin/dash, but you may backup instead to be sure). Then dash:i386 could uninstall fine. But APT was tripping over the lack of sh. So i temporarily did link /bin/bash /bin/sh (redirecting sh to bash). I also needed to execute the following:

dpkg-divert --remove "/usr/share/man/man1/sh.1.gz"
dpkg-divert --remove "/bin/sh"

With this I was able to do apt install dash to finally install it, it fixed the diversions and made correct symlinks properly on its own. Then I could resume purging i386 packages and finished my conversion of Ubuntu 18.04 LTS to an x64 system.

Hope this helps someone in the future, who is forced to do this rather than just reinstall.


There is a tool capable of automating such crossgrades. Hope it helpes: https://blog.rimuhosting.com/2018/03/21/32-to-64-bit-distro-crossgrades/

It is called distrorejuve and may help with crossgrade process (while still in beta). --to-64bit switch is doing it; see --help for details

  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. Sep 6, 2021 at 13:21
  • Added tool name and relevant command line switches
    – unxed
    Sep 7, 2021 at 8:20

You must log in to answer this question.

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