Upgrading Debian from 32-bit to 64-bit - AKA "crossgrading from i386 to amd64"

I went crazy again and upgraded my laptop from 32 to 64 bits. This was a rather complex problem, and in retrospect it may have been easier to simply reinstall. But it was a good exercise and a good test of the new multi-arch support, which, I gotta say, works surprisingly well.

A few other people wrote their own procedures already, but I made my own in my wiki (which, incidentally, I am thinking of using to replace this blog which I can't seem to upgrade to even Drupal 7...).


Portrait de mirabilos

#1 mirabilos : Still waiting…

… for x32 support to finally show up in the archive. (To add insult to injury, the Debian Linux kernel maintainers are currently blocking support for it so I can’t even run it in a chroot!)

Then I will “cross-grade” this system (initially a Kubuntu hardy 8.04 i386, then upgraded to Debian lenny, then to sid using squeeze and wheezy as intermediate stepping points) from i386 to x32!

(No stinky amd64 for me. Except a chroot for libvirt.)

PS: Your CAPTCHA does not show up in Konqueror (or Lynx). Had to boot Firef*x for commenting here. And try to parse French…

Portrait de Stuart

#2 Stuart : fun :)

Good to see you had a lot of fun cross-grading. Well done on doing this entirely with debian tools and not needing some busybox magic in the middle.

BTW the "xargs apt-get -y install" step to install the Multi-arch: same packages doesn't fail in my method because I've got "xargs apt-get -y install" so that the few failures that are there because of packages that don't exist won't screw up the entire procedure. Yes, that means running apt a lot of times but it still doesn't take that long. (I have followed that exact procedure on a desktop machine with ~1800 packages installed).

More alarmingly though, I did find on a non-trivial system, that installing the Multi-arch: same library actually caused apt to remove great swathes of other packages on me. This situation happened when the M-A library depends on some other library that has yet to be properly multiarched. I suspect adding --no-remove to apt-get is really necessary here.

I'm surprised that the "dpkg -i lib*_amd64.deb" step actually gets to a stage where there are no errors as you suggest. There are plenty of libfoo:amd64 packages that will depend on the foo-bin (or foo-utils etc) package and unless the bin package is marked "Multi-Arch: foreign" the dependency isn't satisfied yet. That should get sorted out in the next looping dpkg invocation though. I do wonder whether that looping dpkg invocation could be achieved more easily by grouping the packages together (using xargs, for instance) with a --force-depends just as apt would do to get it to complete the operation.

The more people who keep experimenting with this, the better the procedure will become :) Thanks for sharing your experience here. (Perhaps you could link these back to the debian wiki if they are not already there?)

Portrait de anarcat

#3 anarcat : thanks for the feedback

Yeah, I would guess the apt-get install failed exactly because this was a workstation with 2500+ packages installed... I didn't feel confident it would do the right thing, and I didn't want to start tracking packages the way that other procedure was doing.

The dpkg -i step is a mess. Really, this should be properly handled by apt's dependency system and anything we try to do only with dpkg will be only a poor and failed approximation.

However, since we think we have the right packages, we may be able to get away with --force-depends, which I would recommend using for people using the procedure next time.

It would be great if someone could merge that into the wiki - we should probably have a simpler way of doing this, but my guess is this procedure is the best we have so far, while the procedure in the wiki is awfully messy...

Portrait de LeLutin

#4 LeLutin : go for it!

I definitely recommend moving to ikiwiki, it's a great platform for single-person blogging.

The hard problem with migrating though is to import everything while making sure content stays correct.