BALUG Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
<file>
Linux - upgrade 32-bit to 64-bit? (i[3456]86 to amd64/x86_64)

It's a commonly asked question:
"Can I upgrade my 32-bit installed Linux distribution to 64-bit?"
The answer is: Yes*
The more accurate and complete answer is a (much more) qualified yes:
*Yes, ... if your distribution has both 32-bit and 64-bit versions,
typically significantly to much easier to backup the 32-bit version,
saving all data (and meta-data) that might be needed, do a fresh 64-bit
installation, then carefully migrate data as wanted onto the 64-bit
version.  And of course one has to have the appropriate 64-bit capable
machine.  Similar procedure can also be used migrating to new(er)
64-bit capable hardware.

But what if you really want to do an upgrade-in-place operation, from
32-bit to 64-bit?  The "worst case" would be highly difficult ... if you
really want to go that route.  It's Linux, one can dig as necessary to
determine precisely what's different and make those changes - but one
may need the host to be down when doing that.

But if you have a Linux distribution with multiarch support, e.g.
current Debian, and at least certain derivatives:
http://www.debian.org/News/2013/20130504
http://www.debian.org/News/2011/20110726b
https://wiki.debian.org/Multiarch#Current_Status
Then doing such an upgrade (or cross-grade) is quite a bit easier, but
still quite non-trivial.
"in the future will even allow live migrations from 32-bit to 64-bit systems"
Yes, in future that may be a comparatively easy procedure, but it is
quite doable presently, ... it's just not all that easy to do.

So ... thought I'd run the experiment, as I do have some hosts I might
want to do such an upgrade (or cross-grade) on.  There is also a lot of
documentation and the like on how to go about doing it ... but doesn't yet
seem to be any simple sure-fire recipe that one can run to do it all.
Though there are lots of useful bits and "tools" and procedures
information, on how to go about doing it both general, and in a fair bit
of specificity.

Anyway, I set up a virtual machine (under qemu-kvm), installed
Debian GNU/Linux 7.4.0 "Wheezy" i386 on it and upgraded to 7.5.0
(as I'm writing this, the 7.5.0 ISO images aren't out on the mirrors
quite yet, but should be very soon - 7.5.0 was released 2014-04-26, and
the packages are available).

So, the procedure - for Debian (or derivative?) with multiarch support.
This is just an outline - I don't cover all the steps in detail:

Add 64-bit architecture support:
# dpkg --add-architecture amd64

Update apt so it also knows about the 64-bit stuff:
I set the Debian CD ISO images:
Debian GNU/Linux 7.4.0 "Wheezy" - Official amd64 CD Binary-1 20140208-13:47
Debian GNU/Linux 7.4.0 "Wheezy" - Official i386 CD Binary-1 20140208-12:25
respectively on /dev/sda and /dev/sdb
and mounted respectively on /media/cdrom9 and /media/cdrom8
(I did that to avoid all the insert/remove CD stuff, and if I needed
packages from either, to generally go much lighter on the mirrors).
I then updated my /etc/apt/sources.list so its active lines contained:
deb [arch=amd64] file:/media/cdrom9 wheezy main
deb [arch=i386] file:/media/cdrom8 wheezy main
deb http://http.debian.net/debian/ wheezy main
deb-src http://http.debian.net/debian/ wheezy main
deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main
deb http://http.debian.net/debian/ wheezy-updates main
deb-src http://http.debian.net/debian/ wheezy-updates main
and then did:
# apt-get update

One should be sure one's packages are in a clean state before proceeding, e.g. see:
http://www.debian.org/releases/wheezy/i386/release-notes/ch-upgrading.en.html#system-status
and especially:
http://www.debian.org/releases/wheezy/i386/release-notes/ch-upgrading.en.html#package-status

Good idea to capture package status before we proceed further, e.g. save
the output of:
# dpkg --get-selections
to a file.  Also, many of the "recipes" given make use of such data or
portions thereof (e.g. to pick out i386 that's installed, and configure
to install amd64).  It may also be advisable to capture information
regarding the installed packages, if they were specifically requested,
or automatically installed to satisfy dependency(/ies).  One may later
want to similarly mark amd64 packages as they were for their earlier
i386 counterparts.  One might also want that information for packages
who's architecture is "all", as some of those might get
upgraded/replaced/reinstalled along the way.

Now we're ready to install packages.  First, add a 64-bit kernel:
# apt-get install linux-image-amd64:amd64
Then reboot using the 64-bit kernel.
Presuming that went fine, one can remove the 32-bit kernel

So much for the easy portions.  I'll just outline the rest.

It's mostly a matter of getting things added/replaced/removed in the
"right" order - or sufficiently correct order that it all works.

Some of the many key bits:

dpkg & apt - until these are repladed with the 64-bit versions, the
existing versions think the native architecture is 32-bit, and 64-bit is
"foreign".  There are lots of dependencies - most notably libraries.
When dealing with dpkg and apt-get, one can append specific
architecture, e.g. appending on package architecture:
:i386 for i386 (32-bit), and
:amd64 for amd64 (64-bit)
- that can be done to be sure one installs/removes/purges the desired
package(s), particularly while dpkg and apt still are at 32-bit and
treat the native architecture as i386 and treat amd64 as foreign.
Beware that the apt package has a lot of dependencies, so it's not one
of the easier ones to get from 32-bit to 64-bit, but it is both
important and essential.

One can also use - and _ suffixes for remove and purge with apt-get, so,
e.g. one can add and remove/packages with a single apt-get command.

The -s option to apt-get and --simulate option to dpkg will come in very
handy.  Many/most of the operations you'll want to see first if the
dependencies have already been met, or not or if any conflicts or other
problems show up.  If/when you encounter any predepends, those need to
be installed first, not at the same time with dpkg.

You'll want to be able to use dpkg fairly well, it's lower-level than
apt-get, but you'll need it for some operations, e.g. for making the
transition of the apt package from 32-bit to 64-bit, and even dpkg
itself.

Be very careful with "essential" packages.  If you make an error there
it may be difficult to recover.

The binutils package may come in quite handy on
current Debian, notably as it contains ar - and Debian packages (.deb
files) are in ar format.  If needed, one can use ar(1) to extract
contents from a Debian package.  E.g. if one breaks findutils, which
dpkg -i depends upon (depends upon the find binary).

In general you shouldn't have to --force anything.  If apt-get is giving
you warnings with notification such as:
To continue type in the phrase 'Yes, do as I say!'
That is probably not the path you want to go down.

Package versions need to match.  If you're going from 32-bit to 64-bit
version of package, in many cases apt-get won't handle that for you (or
at least not without forcing it, which will typically break things) and
you'll need to use dpkg.  E.g. where the version numbers match, one can
use dpkg -i to install the 64 bit version, and where it's, e.g.
something like a general utility and not a library, it will generally
replace the 32-bit version with the 64-bit version - if all the
dependencies for the 64-bit version are in place or covered on the dpkg
command, and all reverse-dependencies for removing the 32-bit version
have been covered.

Use of apt-get download can be very handy.
One may want to use /var/cache/apt/archives for download location, as
that's where apt-get install defaults to caching files it downloads.

You'll want to be sure you notice, catch and correct, certain errors
that may be critical.  E.g. if a package update/installation causes new
initramfs to be built for kernel(s) and that throws error(s), be sure to
correct those.  E.g. one can fix a missing/broken dependency, then
reconfigure the dependent package that caused the error to be thrown,
e.g.:
...
Setting up lvm2 (2.02.95-8) ...
Setting up LVM Volume Groups...done.
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64
mount: error while loading shared libraries: libmount.so.1: cannot open shared object file: No such file or directory
# dpkg -i /media/cdrom9/pool/main/u/util-linux/mount_2.20.1-5.3_amd64.deb
...
# dpkg-reconfigure lvm2
...
In the above case, mount was installed, but it was i386 and wasn't happy
with its library situation, whereas the libraries for amd64 mount were
already installed - so just needed the amd64 mount installed and
reconfigure lvm2 to correct the error it encountered in updating the
initramfs.

And if one does go through with getting rid of all i386 (e.g. if it's
not wanted or needed), one can remove the i386 architecture, e.g.:
# dpkg --remove-architecture i386
One would also then typically want to remove any i386 specific
architecture bits from /etc/apt/sources.list
and again update apt:
# apt-get update
One may want to reboot when all is done, to ensure all is working as
expected, and to also ensure no i386 binaries are still in use (e.g.
unlinked open files still being executed).  Alternatively, one may look
for open unlinked files that belong to any removed/purged i386 packages.
lsof may be handy for that (or use of find and the proc filesystem),
one can see some examples of that for a bit different task on:
http://linuxmafia.com/pipermail/sf-lug/2014q2/010408.html
</file>

<file>
And a much cleaner run at it.
The files linked below are bzip2(1) -9 compressed from
script(1) with -t option.
One may want to shorten up some of the longer
(idle/waiting/inactive) times in the time file, e.g.:
(where here, our leading $ is PS1, and leading > is PS2)
$ bzip2 -d < 32to64.time.bz2 |
> > 32to64.shorter_wait_times \
> sed -e 's/^[0-9]\{2,\}\.[0-9]\{1,\} /3.000000 /'
And uncompress the script file:
$ bzip2 -d 32to64.script.bz2
And one can then review it with scriptreplay(1),
e.g. to see that at triple speed:
$ scriptreplay 32to64.shorter_wait_times 32to64.script 3
That was captured connecting via serial console (virtually),
as for terminal type, one would probably want to do that in an 80x24
vt100, or xterm, screen, or ANSI terminal or emulation, for best
reproduction/viewing results.
</file>
{{system:32to64.script.bz2}}
{{32to64.time.bz2}}
<file>
Also, what was captured mostly just shows actual changes done.
For the most part I used a separate session for doing things like
simulation runs, e.g.:
# apt-get -s ...
# dpkg --simulate ...
downloads:
# apt-get download ...
and working out various dependencies (typically from the simulations
above), and statuses (typically via use of
$ COLUMNS=200 dpkg -l
and sometimes also:
# apt-get -s install
and picking over the resultant data).
For the most part, when
# dpkg --simulate -i ...
came back looking clean, the corresponding
# dpkg -i ...
worked fine, but not always - sometime the latter would expose
additional dependencies or other (relatively minor) issues.  Most
commonly, if not always, such issues were resolved just by bringing in
another package to a few packages or so, and then a:
# dpkg --configure --pending
and all was then fine.
Seems the whole process could (almost?) be automated by some
higher-level script/program (e.g. perl) to work all that stuff out and
implement it.  The only part that might be a bit more tricky, is in some
cases, there wasn't a precise correspondence between i386 and amd64
packages.  E.g., in almost all cases, it was simply matter of same
package and version number in i386 architecture being replaced with
same from amd64 architecture.  But not always - there were some
exceptions.  But at least where I encountered such, it was easy enough
to figure out from the dependencies and/or lack thereof, or from the
names and descriptions, etc.
</file>
And one issue that was found a little bit later (2014-06-13) and corrected, from our [[http://www.archive.balug.org/log.txt|system log]] file:
<file>
Noticed bug/issue with spell, e.g.:
$ echo foo | spell
/usr/bin/ispell: Illegal format hash table
Tried:
# (cd / && umask 022 && dpkg-reconfigure spell)
# (cd / && umask 022 && dpkg-reconfigure dictionaries-common)
# (cd / && umask 022 && dpkg-reconfigure ispell)
Those didn't correct it, but this did:
# (cd / && umask 022 && dpkg-reconfigure iamerican)
That updated:
/var/lib/ispell/american.hash
Guessing this may have been issue left over from i386 to amd64 conversion
</file>
See also: [[https://wiki.debian.org/CrossGrading|CrossGrading]] (a Debian system - on the Debian wiki)
BALUG Wiki

User Tools

Site Tools

Page Tools
