Skip to main content

1. Introduction

This brief HOWTO shows how to take a working 32 bit 14.04 installation and convert it into a 64 bit system. You will be able to keep all your programs, settings and data. You start with a 32 bit system that can run 64 bit programs, then convert it to a 64 bit system that can run 32 bit programs.

With the release of Debian GNU/Linux wheezy, a new feature called multiarch was introduced. The facility permits the installation of executable files (such as libraries and programs) from multiple architectures simultaneously on the same system. The primary use of this is to allow 32 bit programs to be run on a 64 bit system, but it has other uses.

With the release of Ubuntu LTS 14.04 (Trusty Tahr), the ability to use the multiarch facility to upgrade to 64 bit is easier than ever. Much simpler than upgrading 12.04 and an evolution of upgrading Debian 7 or 8.

If you are using Ubuntu LTS 18.04 (Bionic Beaver) the process is quite different so please use the dedicated guide on the newer page instead of this guide.

2. Preparation

Before we change any packages, preserve the list of the packages we have installed. At the end we can run a comparison or reconciliation to see if there are any omissions or remaining work. All steps should be performed using a VT text console rather than the GUI because the GUI will become unavailable during parts of the process. In addition, the steps should be run as root directly, avoiding the use of sudo. Please refer to this comment for further details about this.

dpkg --get-selections "*:i386"|grep -v deinstall >dpkg-get-selections.cp.00.i386
dpkg --get-selections "*:amd64"|grep -v deinstall >dpkg-get-selections.cp.00.amd64
dpkg --get-selections "*:all"|grep -v deinstall >dpkg-get-selections.cp.00.all

3. Backups

Have I mentioned the importance of backups? Ensure you have a tested recoverable backup of your entire system, and also a means to access it should the network or kernel be unavailable. If you have encrypted files or home directories then verify that you can restore these successfully.

Some packages store their data in a binary format that differs between architectures. We must grab the data in an architecture-independent manner now, in order to restore it in the 64 bit system later. Such packages I have installed are OpenLDAP and PostgreSQL.

3.1. OpenLDAP

Dump the OpenLDAP database and preserve its configuration. We'll have to purge the package as it will attempt and fail to upgrade its database upon migration.

umask 77
slapcat -n 1 >slapcat-n1
service slapd stop
mkdir -p etc/ldap
rm -Rf etc/ldap/slapd.d
cp -ai /etc/ldap/slapd.d etc/ldap

3.2 PostgreSQL

Dump the PostgreSQL cluster data and preserve its configuration.

su - postgres -c "umask 77; pg_dumpall >/tmp/pg_dumpall_9_3.sql"
mv /tmp/pg_dumpall_9_3.sql .
bzip2 -f pg_dumpall_9_3.sql
mkdir -p etc/postgresql/9.3/main
cp -pi /etc/postgresql/9.3/main/pg_hba.conf etc/postgresql/9.3/main

4. Boot into a 64 bit kernel

The 32 bit kernel does not allow the execution of 64 bit programs. However the 64 bit kernel allows the execution of both 32 bit and 64 bit programs, so this 64 bit kernel is the first thing needed. Run the following in turn to allow 64 bit programs to be installed as an additional architecture, then install the 64 bit kernel. We will also install debootstrap and we will use it later to download the base system.

The steps below will replace the 32 bit kernel with the 64 bit kernel. If you do not have any other 32 bit kernels installed then I recommend backing up the current kernel and initrd before running the commands.

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

Now reboot with the newly installed 64 bit amd64 kernel before continuing.

5. Prepare base systems

Cross-grading the whole existing system is prone to error due to the mass of dependencies, tied with the fact that dpkg currently cannot cross-grade (change architecture) and upgrade (change version) a package in the same operation.

Download the base system's essential packages in 32 bit and 64 bit varieties. The less we download here, the quicker the base system migration will be as we will need to cross-grade them all from 32 bit to 64 bit. If you don't require networking then do not include openssh-client, openssh-server, network-manager and systemd-shim in the --include list below. If you do not require the kernel, which is very slow to migrate, do not include linux-generic and grub-pc. If you don't need LVM then do not include lvm2, base-files and bash.

mkdir -p bootstrap-i386
rm -Rf bootstrap-i386/*
debootstrap --arch=i386 --download-only --include=openssh-client,openssh-server,network-manager,systemd-shim,linux-generic,grub-pc,lvm2,base-files,bash trusty ./bootstrap-i386

mkdir -p bootstrap-amd64
rm -Rf bootstrap-amd64/*
debootstrap --arch=amd64 --download-only --include=openssh-client,openssh-server,network-manager,systemd-shim,linux-generic,grub-pc,lvm2,base-files,bash trusty ./bootstrap-amd64

Now build a package list of the intended stripped-down base system.

ls -1 bootstrap-amd64/var/cache/apt/archives/|egrep "\.deb$"|cut -d "_" -f1|awk '{print $1 " install"}' >dpkg-get-selections.base

6. Purge architecture-independent packages

Purge any packages that cannot be migrated to 64 bit directly. I also recommend removing non-standard package repositories and removing (or preferably purging) any packages installed from those now.

apt-get purge slapd
apt-get purge postgresql-9.3
apt-get remove myspell-en-au # due to missing dependency on dictionaries-common

7. Strip to 32 bit base system

Remove all non-essential packages from the system. Note that rebooting during this process is not recommended as the system will be unbootable until the process has completed and the 64 bit kernel reinstalled.

Update our package list from the base system prepared earlier.

dpkg --clear-selections
dpkg --set-selections <dpkg-get-selections.base

Now remove all the non-essential packages that are not part of the base system.  This will take some time to complete.

apt-get dselect-upgrade

Downgrade any packages to the versions downloaded by debootstrap. This will strip updates and security fixes. We must have the same versions of packages in the 32 bit and 64 bit base system to be able to cross-grade them. They will of course be upgraded again later.

dpkg -i bootstrap-i386/var/cache/apt/archives/*.deb

Finally, install (migrate to) the 64 bit base system. To avoid complex dependency calculations, cross-grade the packages multiple times until all dependencies have been met. If we chose a small base system to download with debootstrap earlier then this step will be significantly faster.

dpkg --clear-selections
RC=1; while [ $RC -ne 0 ]; do
  dpkg --abort-after=1000 -i bootstrap-amd64/var/cache/apt/archives/*.deb

Now the 64 bit kernel has been reinstalled (okay, probably an older one), so if you need to reboot, you could do so from this point onwards.

dpkg -l "linux-image-*"

| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
un  linux-image-3.               (no description available)
ii  linux-image-3. 3.13.0-24.46 amd64        Linux kernel image for version 3.
rc  linux-image-3. 3.13.0-29.53 amd64        Linux kernel image for version 3.
ii  linux-image-ex 3.13.0-24.46 amd64        Linux kernel extra modules for ve
rc  linux-image-ex 3.13.0-29.53 amd64        Linux kernel extra modules for ve
ii  linux-image-ge amd64        Generic Linux kernel image

Checkpoint the list of installed packages and then upgrade the base system.

dpkg --get-selections "*:i386"|grep -v deinstall >dpkg-get-selections.cp.01.i386
dpkg --get-selections "*:amd64"|grep -v deinstall >dpkg-get-selections.cp.01.amd64
dpkg --get-selections "*:all"|grep -v deinstall >dpkg-get-selections.cp.01.all

apt-get autoremove
apt-get dselect-upgrade

If you excluded the kernel from the above installation steps, then install it again now. This step will also ensure that all dependencies are met. Capture another package list checkpoint at the end of this process in case we need to refer back to it.

apt-get install locales linux-generic grub-pc lvm2

dpkg --get-selections "*:i386"|grep -v deinstall >dpkg-get-selections.cp.02.i386
dpkg --get-selections "*:amd64"|grep -v deinstall >dpkg-get-selections.cp.02.amd64
dpkg --get-selections "*:all"|grep -v deinstall >dpkg-get-selections.cp.02.all

8. Install virtual packages (optional)

To speed up the installation progress of the remaining 64 bit packages you may wish to manually install some of them now, especially the larger ones. Performing this step will also allow apt to take care of the dependencies for us.

Before proceeding, note the following error and its resolution. Any package (typically library packages) could raise this error during the 64 bit installation.

Unpacking libsensors4:amd64 (1:3.3.4-2ubuntu1) ...
dpkg: error processing archive /var/cache/apt/archives/libsensors4_1%3a3.3.4-2ubuntu1_amd64.deb (--install):
 trying to overwrite shared '/etc/sensors.d/.placeholder', which is different from other instances of package libsensors4:amd64
Errors were encountered while processing:

If the 32 bit and 64 bit versions of the package are not able to co-exist you will need to purge the 32 bit package (and manually reinstall the 64 bit package if you hit the error above). For example.

dpkg --purge libsensors4

(Reading database ... 100613 files and directories currently installed.)
Removing libsensors4:i386 (1:3.3.4-2ubuntu1) ...
Purging configuration files for libsensors4:i386 (1:3.3.4-2ubuntu1) ...

dpkg -i /var/cache/apt/archives/libsensors4_1%3a3.3.4-2ubuntu1_amd64.deb

(Reading database ... 100615 files and directories currently installed.)
Preparing to unpack .../libsensors4_1%3a3.3.4-2ubuntu1_amd64.deb ...
Unpacking libsensors4:amd64 (1:3.3.4-2ubuntu1) ...
Setting up libsensors4:amd64 (1:3.3.4-2ubuntu1) ...
Processing triggers for libc-bin (2.19-0ubuntu6) ...

dpkg --configure -a

With this in mind, purge the 32 bit packages now that are known to cause issues with cross-grading to 64 bit. Then install the major pseudo-packages. I also had gnome-shell and texlive installed. Installing them now will ease the effort later in the process.

dpkg --purge libldap-2.4-2:i386 libpython2.7-minimal:i386 libgtk-3-0 libsensors4 libpulse0 libgl1-mesa-dri libqtcore4 libsane sni-qt libgnomevfs2-extra

apt-get install ubuntu-desktop ubuntu-minimal ubuntu-standard gnome-shell texlive

When configuring gdm I was given a choice of which windows manager to use. I chose the default lightdm.

Now that the desktop packages are installed you may wish to restart the display manager.

service lightdm restart

9. Install remaining packages

Now we can calculate the list of packages outstanding for reinstallation and install them. Firstly purge all library packages as they are no longer required and their 32 bit configurations may not be able to co-exist with their 64 bit replacements (as detailed earlier).

apt-get install dselect aptitude
dselect update
aptitude keep-all
aptitude forget-new
aptitude purge '~c^lib'

Build the final package list of all the packages we wish installed (i.e. the 64 bit versions of the original 32 bit packages and all of the previously-installed architecture-independent packages). Then we can finally remove the old 32 bit architecture.

cat dpkg-get-selections.cp.00.all|grep -v deinstall >
cat dpkg-get-selections.cp.00.i386|grep -v ":i386"|grep -v deinstall|cut -f1|awk '{print $1 " install"}' >>
cat dpkg-get-selections.cp.00.i386|grep ":i386"|grep -v deinstall|cut -d: -f1|awk '{print $1 " install"}' >>
cat dpkg-get-selections.cp.00.amd64|grep ^linux-image|grep -v deinstall|cut -d: -f1|awk '{print $1 " install"}' >>

dpkg --clear-selections
dpkg --remove-architecture i386
dselect update
cat|dpkg --set-selections

We need to use various strategies to get all the packages we want installed. As yet I have been unable to determine the precise reason for this and orginally thought it was caused by this feature. When running the below dselect-upgrade you may see packages marked for removal. For example I found that apache2:i386 was in dpkg's available cache, but apache2:amd64 was not and saw an error such as this when attempting to set it as a dpkg selection. It was in the available file so I could not get to the bottom of this behavior. I would see an error such as this.

dpkg: warning: package not in database at line 876: apache2:amd64

We will resolve this along the way because if we don't then we will start pulling back in 32 bit packages.

Purge any known problematic packages that will not cross-grade to 64 bit and begin the first installation.

dpkg --purge openjdk-6-jre-headless openjdk-7-jre-headless
apt-get dselect-upgrade

Keep trying to install the remaining packages and clean up any dependency issues as we go. Apt will triumph over the earlier issues with dpkg and install the missing packages (such as apache2). I found an issue with flashplugin-installer as I had forgotten to disable the partner repository before starting.

apt-get install `dpkg --get-selections "*:i386"|grep -v deinstall|cut -f1|cut -d: -f1|sed ':a;N;$!ba;s/\n/ /g'`
apt-get install `dpkg --get-selections "*:all"|grep -v deinstall|cut -f1|cut -d: -f1|sed ':a;N;$!ba;s/\n/ /g'`
apt-get purge flashplugin-installer
apt-get install `dpkg --get-selections "*:amd64"|grep -v deinstall|cut -f1|cut -d: -f1|sed ':a;N;$!ba;s/\n/ /g'`

dpkg --purge freeglut3:i386 odbcinst1debian2:i386 phonon:i386
apt-get install `dpkg -l "*:i386"|egrep "^rc"|cut -d" " -f3| cut -d: -f1|sed ':a;N;$!ba;s/\n/ /g'`

Finally install the kernel metapackage and cancel all pending actions in aptitude (should it still be installed).

apt-get install linux-generic
aptitude keep-all

10. Restore backups

10.1. PostgreSQL

Restore the PostgreSQL configuration and database cluster data.

cp -p etc/postgresql/9.3/main/pg_hba.conf /etc/postgresql/9.3/main
service postgresql reload
bzcat pg_dumpall_9_3.sql.bz2 >/tmp/pg_dumpall_9_3.sql
su - postgres -c "cd /tmp; psql <pg_dumpall_9_3.sql >psql.out 2>psql.err"
mv /tmp/psql.* .
cat psql.err
rm /tmp/pg_dumpall_9_3.sql

10.2. OpenLDAP

Restore the OpenLDAP configuration and database.

service slapd stop
rm /var/lib/ldap/*
rm -R /etc/ldap/slapd.d
cp -a etc/ldap/slapd.d /etc/ldap
slapadd -n1 <slapcat-n1
chown -R openldap:openldap /var/lib/ldap/*
service slapd start

11. Final checks

Re-enable any third party package repositories and install any packages required from these.

Grab a final checkpoint of the packages we have installed. Compare the latest list to the original package list. There should not be anything missing now except perhaps packages that are not available for 64 bit that were available for 32 bit.

dpkg --get-selections "*:i386"|grep -v deinstall >dpkg-get-selections.cp.03.i386
dpkg --get-selections "*:amd64"|grep -v deinstall >dpkg-get-selections.cp.03.amd64
dpkg --get-selections "*:all"|grep -v deinstall >dpkg-get-selections.cp.03.all

sdiff -s dpkg-get-selections.cp.00.i386 dpkg-get-selections.cp.03.amd64|grep "<"

12. Install 32 bit packages (optional)

If you still want to install those old 32 bit packages, then enable the 32 bit architecture and install them as normal.

dpkg --add-architecture i386
apt-get update
apt-get install googleearth


Alex McLintock (not verified) Tue, 16/09/2014 - 11:27

In reply to by Frankie Fisher (not verified)

On my upgraded to 14.04 desktop I get this error

The following packages have unmet dependencies.
linux-generic:amd64 : Depends: linux-image-generic:amd64 (= but it is not going to be installed
Depends: linux-headers-generic:amd64 (= but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

when I do the command apt-get install linux-generic:amd64 debootstrap

Any suggestions on how to find out more. I don't understand what particular packages it is complaining about.

This is not a fresh install of 14.04 so there may be lots of old stuff lying around.

Ewan Tue, 16/09/2014 - 13:17

In reply to by Alex McLintock (not verified)

Alex, the guide was based on a real system. This system was installed on 7.10 and was upgraded through all LTS versions 8.04, 10.04, 12.04, and finally 14.04. Did you see any errors from the earlier commands?

dpkg --add-architecture amd64
apt-get update

Have you any PPAs, backports, or other package repositories defined? Do you know the aptitude package manager well enough to select the linux-generic:amd64 package and see why it might fail to install (under the depends section)?

Kris (not verified) Wed, 08/10/2014 - 17:55

In reply to by Ewan

Hi Ewan,

I have exactly the same problem.

My system has also gone through quite a few upgrades, but just did the upgrade from 12-04 LTS to 14-04 LTS. I see no broken packages in Synaptic, yet can't get past the debootstrap step. Earlier steps did not give any problems, and I have neither LDAP or the SQL packages installed.



Ewan Wed, 08/10/2014 - 22:40

In reply to by Kris (not verified)

Hi Kris,

Is that the apt-get install debootstrap step? If so, please send me all the output from this step. It is odd because this is the first thing in the guide.


Derek Broughton (not verified) Wed, 10/02/2016 - 08:18

In reply to by Ewan

I believe many standard configurations have the linux-image packages held by default. In this case, you can just install linux-image-generic:amd64 rather than linux-generic--and I'd argue you're better off to do that. At this time, you don't need the header packages that come in with linux-generic--they're just dozens of megabytes of cruft.

Ewan Fri, 14/08/2015 - 20:05

In reply to by German (not verified)

I cannot think of an obvious reason for that. Do you have any non-standard packages installed: dpkg --get-selections "*"? Any outstanding configuration errors: dpkg --configure -a? Anything half-installed?

Martijn (not verified) Wed, 12/11/2014 - 23:33

I had a basic server-like system with no gui libraries, fresh installed from 14.04 (didn't want to lose the configuration work I had already put into it). I had no problems at all except some unavoidable minor ones related to custom packages. Thanks a ton for the writeup!

Pavel (not verified) Tue, 18/11/2014 - 01:17

hi Ewan!
First i want to thank u for this great tutorial. I think many people will find it very useful!
Im trying to upgrade my home desktop machine. I dd my working hdd into another one, and start this new image in virtual machine. Also in VM i have made a snapshot at the start point(when im on 32bit), so i can easily revert all changes. I followed tutorial and on step 7 i have got some troubles, hope u will help me. I skipped step 6, cause i dont know what packages are architecture-independent in my case. So, on step 7, when i do "apt-get autoremove", i get this:
And, if i try "apt-get autoremove -f" i get this:
I think im doing something wrong, cuz apt-get wants to intall i386 versions of packages (read "The following NEW packages will be installed" section). Also im showing to you all my dpkg-get-selections.cp* files, that were made until "apt-get autoremove":
dpkg-get-selections.cp.00.amd64 EMPTY
dpkg-get-selections.cp.01.i386 EMPTY
So, im waiting for any advices from you. Thanks in advance!

Ewan Tue, 18/11/2014 - 13:36

In reply to by Pavel (not verified)

Hi Pavel,

I think the issue is revealed here:

The following packages have unmet dependencies:
 myspell-en-au : Depends: dictionaries-common (>= 1.0) but it is not installed

By skipping step 6 you may have missed this line which was supposed to pre-empt this error:

apt-get remove myspell-en-au # due to missing dependency on dictionaries-common
Perhaps you could try running this now or reverting to your earlier snapshot and trying again? You could also try removing all those packages that have unmet dependencies. There are a lot of packages listed in your dpkg-get-selections.cp.01.all file that should not be present at this step (i.e. you should only have base packages at this point). These are possibly causing the remaining unmet dependencies for you.

Kind regards, Ewan.

Pavel (not verified) Tue, 18/11/2014 - 14:43

In reply to by Ewan

Ewan, thanks for the fast and helpful answer. I really didnt pay enough attention to step 6. So, i understood that my system really needs to be cleaned before being upgraded. I will try to purge as many of these "blocking" packages as possible. Also i will remove all packages from non-ubuntu repos (i have some, like obsolete medibuntu repo and some others). After this cleaning i will dd my hard drive and try again all steps from your tutorial. I will inform you about the results, whether they will be successful or not.

Pavel (not verified) Thu, 20/11/2014 - 10:09

In reply to by Ewan

i made some cleanup on my system, then i start over the migration process with the step1 but.....i`ve got the problem, described in the above comments here by Alex McLintock and Kris, when after apt-get install linux-generic:amd64 debootstrap in step4 i got:

The following packages have unmet dependencies.
linux-generic:amd64 : Depends: linux-image-generic:amd64 (= but it is not going to be installed
Depends: linux-headers-generic:amd64 (= but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

I didnt understand why this problem appears, cause during my cleanup i really didnt do anything special or complicated. May be its a bug(feature?) of the apt-get, who knows? :) I found workaround, just by uninstalling old kernels first, with this small script found on internet:

dpkg -l linux-image-* | grep ii | grep -v [a-z]-generic | grep -v `uname -r` | awk '{ print $2 }' | xargs apt-get -y purge

So, only one most recent kernel left in the system, then i uninstalled it and all relative packages with:

apt-get purge linux-generic* linux-headers-* linux-image-* wireless-crda

After this operation, apt-get install linux-generic:amd64 debootstrap worked.
Cleaning my system helped me, and all previous "errors" disappeared. Now im finishing step 8.
Ewan, what do u think, is it possible to perform the reverse downgrade process(from 64 to 32)? For this moment i cant imagine why i may need this, but who is life :)

Ewan Thu, 20/11/2014 - 10:53

In reply to by Pavel (not verified)

I'm looking at a 32 bit downgrades and also MIPS to ARM cross-grades because I have some old MIPS boxes with Debian which will no doubt have to be replaced with ARM when they eventually give up the ghost. It all takes time to test, test and retest!

Matthias Loidolt (not verified) Sun, 21/12/2014 - 20:14

Hey, i wanted to try out your tutorial. It worked like a charm until the command dpkg 2--set-selections <dpkg-get-selections.base", which presented me to the error of "dpkg: unexpected end of the line in packetname in line 1" (but in german, if it does make any difference?).
Now I'm stuck with a dpkg with no selected packages, so "apt-get dselect-upgrade" wants to unisntall everything.
Anyone having any ideas? There's no x-server so it's complicated for me to fix every of those packages or their names by hand.
Kind regards

Ewan Sun, 21/12/2014 - 20:40

In reply to by Matthias Loidolt (not verified)

Something has gone wrong in step 5. The following should revert any changes.

cat dpkg-get-selections.cp.00.* | dpkg --set-selections

Then the apt-get dselect-upgrade should do nothing destructive (please check), and we can review what failed earlier.

rizpan (not verified) Tue, 23/12/2014 - 20:24

Hi, I was on step 7 and executed this command: apt-get dselect-upgrade
It ran for a long time and then all the fonts became rectangles and the system froze. When I restarted, the ubuntu option was gone from the grub bootloader so I can't even boot back into the system. What went wrong here?

Ewan Tue, 23/12/2014 - 21:11

In reply to by rizpan (not verified)

Were you performing the steps in the GUI? I do not recommend that as the GUI will disappear around you as you remove the 32 bit programs. I thought I had included a note recommending the use of the console. I'll add it now. Unfortunately section 7 states "rebooting during this process is not recommended as the system will be unbootable until the process has completed and the 64 bit kernel reinstalled" – hence your issue booting now.

Alex (not verified) Sat, 24/01/2015 - 20:29

Thanks, I had been afraid to try this but your instructions made it simple. I wanted to add a warning about a mistake that I made. These commands have to be run as root, not using sudo. When packages are being removed in step 7 sudo will stop working, and you won't be able to reboot into a root shell.

Stephen Hill (not verified) Wed, 06/05/2015 - 18:35

When performing the following in Step7:

dpkg -i bootstrap-i386/var/cache/apt/archives/*.deb

I get the following error:

Errors were encountered while processing:


Am unsure how to fix this...

Ewan Thu, 07/05/2015 - 08:53

In reply to by Stephen Hill (not verified)

Do you get the error again if you re-run this? What is the full error when you run dpkg -i bootstrap-i386/var/cache/apt/archives/e2fsprogs_1.42.9-3ubuntu1_i386.deb?

Stephen Hill (not verified) Thu, 07/05/2015 - 15:53

In reply to by Ewan

Looking in my log (which I have now lost), the e2fsprogs package was dependent on a package version that had been upgraded the line before, so it should not have failed. Installing the package manually, after this error, worked fine.

Bernard B (not verified) Sat, 27/06/2015 - 00:56

Not for the faint hearted, but worked! Thank you.

My /boot is on software raid, and so the process kept aborting because anything calling update-grub (e.g. memtest86+'s post-rm script, grub-pc, etc) complained about "grub2-probe: error: disk `md0' not found.". I managed to hack around it by twiddling the post-rm scripts, but I'm pretty sure having "mdadm" in the list in step 5 would have saved me that pain. Indeed, as soon as I could get mdadm installed again, the error went away.

PJ (not verified) Sat, 03/10/2015 - 04:19

This was pretty much perfect. I upgraded a server that I had been upgrading from 8.10. It was 32-bit but many of the packages I use are now only 64-bit. Yay!
TThe only thing I ran in to was that my server is an iSCSI initiator. Rebooting in to the 64-bit kernel in step 4 doesn't quite work unless you also install open-iscsi and probably open-iscsi-utils. Otherwise, I made the jump!

Joe Andrieu (not verified) Wed, 24/02/2016 - 05:08

Sadly, this failed miserably for me. I was logged in over ssh (with the GUI active, but not needed by me) and used "sudo" for the commands. The sudo is the one that killed the process. The loop RC=1; while [ $RC -ne 0 ]; do sudo dpkg --abort-after=1000 -i bootstrap-amd64/var/cache/apt/archives/*.deb; RC=$?; done had a bunch of dependency errors, then failed with -bash: /usr/bin/sudo: cannot execute binary file: Exec format error
Rebooting fails. The machine "Gave up waiting for the boot device". And something like "Request for unknown module key Magrathea."
Same thing in recovery mode. =(

Much sadness. Hopefully this comment will help others avoid my fate.

I see that others commented on the sudo, but I didn't read all the comments before trying that. Now I'm going to have to do a full 64 bit install. Hopefully my backups are sufficient to restore any work lost.

Joe Andrieu (not verified) Thu, 25/02/2016 - 02:57

In reply to by Ewan

Understood. I knew going into it that I was doing a lot of stuff I didn't quite have the expertise to understand fully, so I gave it a 50/50 chance of working. ;) Adding the warning about sudo as you have should avoid a repeat by someone else.

Also, I think you identified the Magrathea bug correctly. What I can't know is if I would have had that problem no matter what or if it was because my use of sudo interrupted the dkpg loop--and I got stuck with a partial upgrade. For those who might be searching for the error from that:

Request for unknown module key Magrathea: Glacier signing key

I suppose if anyone does run into this (without the sudo mistake), it would be good to post here in case it's a more general issue.

The good news is that I had enough space on my disk to do a side-by-side install into a new partition. So, no files lost, just some work reconfiguring the system. Could have been worse.

Ewan Thu, 25/02/2016 - 21:54

In reply to by Joe Andrieu (not verified)

If you have successfully booted using a new kernel and root filesystem then you might also mount the old filesystems and re-attempt the conversion using chroot and avoiding sudo.

Yuri (not verified) Fri, 04/03/2016 - 13:03

Everything seemed to go okay until step 7 in which, after command "apt-get dselect-upgrade" I saw that all of my files began to be erased. I didn't want to stop the process but all my programs were being removed until I had nothing visible on the unity taskbar and even the text in my terminal turned into rectangles. Now I cannot read anything and afraid to reboot or turn off the machine. But more importantly was wondering if there is a way to undo what I just did or reinstall at least the main core of 14.04 LTS. I think what happened is when running commands in step 2, I didn't see any output ie no packages were included and so "apt-get dselect-upgrade" started erasing everything. This might be due to the same issue as Matthias Loidolt mentioned was a problem for him in step 2. And now I find myself in a similar situation that rizpan describes but with a running terminal and even though letters are just rectangles it seems to still execute commands, so I still think there is a chance. I'm really scared I might have erased my whole OS and backup kernels (since I "painfully" watched them being removed from my system). Can you advise me on what to do now to proceed with the update or at least to undo everything that I did when I ran "apt-get dselect-upgrade" is that possible?

Ewan Fri, 04/03/2016 - 13:23

In reply to by Yuri (not verified)

Did you run the steps on a console as advised in step 2, or in the GUI under X? You should be able to switch into a text console and continue where you left off.

Yuri (not verified) Sun, 06/03/2016 - 04:02

In reply to by Ewan

Yes I did but I don't recall seeing any ouput so my system went ahead to erase many files. But thank you for getting back to me so early and helping me save the data. I gotta say you sure provide first class troubleshooting service. BTW great site and great info on how to update I was to blame for not understanding what step 2 really supposed to do and running the commands. But all's well that ends well. Thanks for all your help.

Ewan Sun, 06/03/2016 - 09:50

In reply to by Yuri (not verified)

I have updated steps 2 (preparation) and 3 (backups) based upon our offline discussion and your feedback. If something goes wrong in step 7 (strip to base system) then you could conceivably lose access to sudo and the ability to reboot. In such a case you would not be able to open a root terminal and recover.

Kari Salmela (not verified) Wed, 06/04/2016 - 11:56

when installing the bootstrap packages, be sure to include "vlan" package if your system uses VLAN tagged interfaces, otherwise you will find yourself without working network and thus no easy way of continuing with the upgrade (other than transferring the package to box via USB stick or something).

pludov (not verified) Fri, 15/04/2016 - 00:14

Thank you very much, it worked almost perfectly with kubuntu.
Only one thing caused trouble : QT library creates a file with .so path that make kde crash at startup after the switch to amd64. So for kde user, you have to remove ~/.config/Trolltech.conf (or adapt it).

Adrian (not verified) Thu, 02/02/2017 - 14:03

Thanks for this! This pretty much worked as described on Ubuntu 16.04 with a change to step 5 from trusty to xenial.

Also, you need to make sure to heed the warnings when install candidates can't be found (step 9) and resolve these before moving to the next step.

The only thing I'm not sure about is in step 11 when comparing the original and final configuration a number of packages are marked for deinstall (but are installed) and therefore I got a mismatch. If I include these (used apt list --installed) then everything that was originally installed is now installed. So I'm just wondering why some packages are marked deinstall.

goproguy (not verified) Tue, 25/04/2023 - 18:10

Sorry to resurrect a very dead thread. Hello. I'm on step 7, executed: dpkg --clear-selections
RC=1; while [ $RC -ne 0 ]; do
dpkg --abort-after=1000 -i bootstrap-amd64/var/cache/apt/archives/*.deb
This seems to start an infinite loop of error: subprocess rm cleanup returned error exit status 2. As far as I'm aware, all the packages are fully installed and installed properly. Is there any help I could get for this?

goproguy (not verified) Wed, 26/04/2023 - 15:09

In reply to by Ewan

At the beginning of step 7, output is:
# dpkg --configure -a
before previously mentioned step, it is:
#dpkg --configure -a
dpkg: dependency problems prevent the configuration of ___
___ depends on ___, however, it is not configured yet.

This output for I believe most of my packages, including my linux image, bash, grub, and others. I can't use the | more command to extend the output to see all of them, unfortunately.

Ewan Thu, 27/04/2023 - 19:49

In reply to by goproguy (not verified)

I think the key to resolve this is to find the top-level DEB that is the root cause. If this is not obvious, maybe try installing one at a time, e.g. if x depends on y, and y is not configured yet, try installing y with dpkg -i y, and so on.