Originally posted at https://tech.labs.oliverwyman.com/blog/2016/12/13/cross-grading-for-fun-and-profit/
First thing you’re probably wondering: What’s cross-grading? Well, it’s a bit like upgrading, except more sidewise than definitely upwards. It involves the changing of the architecture of a system, most typically from 32-bit to 64-bit, and most typically from x86 to x86-64 (although similar options are apparently doable for other architecture families, including ARM, MIPS and PowerPC). This is particularly doable on Debian given the current existence of Multiarch (which long-time readers will have seen me talk about 4 years ago).
Couple of warnings up front: basically, don’t do this, it’s a bad idea. The only situation where you should do this is when your server is not config managed, when you’ve got some specific issue with 32-bit (like the Handbrake problem my home server had), and when on the pets vs. cattle scale it’s a much beloved cat that everyone thinks is awesome. The server (at least the OS install) in question is on it’s 3rd set of core hardware (over a period of about 12 years), hence why it was running a 32-bit OS to begin with. Oh also, you should have a working knowledge of apt and dpkg, because you will break stuff along the way, because we’re doing pretty haphazard stuff to a running server. For this reason, it is seriously non-advised if you don’t have physical access to the box. I managed it without having to use the attached keyboard, but you may not be so lucky. I broke PAM at one point, so keeping a spare logged in root user in another terminal is advised just in case you do a similar thing.
To begin with, just follow the guide at the Debian Wiki, specifically the “Add the new architecture”, “Install a kernel capable to run the new architecture with the old architecture in userspace” and “Crossgrade dpkg, tar and apt” steps. It now advises doing fun things with dpkg –get-selections which I figured would result in a bunch of problems. Particularly when you’re running a hardcore-mode Apt-Pinning setup (stable, testing, unstable, and experimental). So instead I used python-apt to write myself a little helper script. The script does the following: go through all your installed packages, skipping “Architecture:all” ones, and install the amd64 versions if you’ve got an i386 one installed already. If there isn’t a candidate version the same as the i386 version (because it’s an out-of-date package), do the minimum upgrade to the i386 package, then install the same version for amd64 (as things get very unhappy if you try and install a different version for the two architectures). If as a result the i386 one gets marked as “Deinstall”, remove it.
For when you do break stuff, “apt-get install” will probably not work as the dependencies are so horribly broken half way through you get errors like “E: Unable to correct dependencies”. However, there is always “apt-get download” which will get you a specific package which can then be installed with “dpkg -i”, which will often fail as you’ll need to manually download a few others. This is a slow and laborious process (hence writing the helper script), but very useful when you break screen, PAM, or other such vital items. The script is idempotent, so re-run it as necessary until it gets as far as it can.
As the ordering of the package installs is generally wrong, running “dpkg –configure -a –abort-after=500” a few times afterwards (the last argument so it actually tries everything that works rather than giving up after the first 50 errors) seems to sort out most of the install issues.
After all that, you’ll probably still have to hand resolve a few package issues (my count was about ~70, but this is an old install), but it’s down to a manageable level, and apt-get or aptitude’s resolvers can cope at those sorts of counts. You may still run into known Multiarch bugs, but these days it’s been around a while and they’re relatively rare, and generally can be worked around (that one by fiddling with /var/lib/dpkg/info/{python-pil:i386.prerm,python-pil:amd64.postinst}). Total elapsed time is probably less than a day or two. I would also advise you don’t do as I did, and backup the system before you start this, as the odds of doing something catastrophic are non-trivial.