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...).
Created .
Edited .
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.
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?)
Yeah, I would guess the
apt-get installfailed 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 -istep is a mess. Really, this should be properly handled by apt's dependency system and anything we try to do only withdpkgwill 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...
… 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…