Sometimes it is better to have a fresh start than to work on what has been around for ages

I finally got to upgrade my ancient desktop at home. The box was originally built around 7-8 years ago, with some minor upgrades along the road, and now it had Athlon XP 2500+ with 1.5 GB RAM. Seriously, it still could run light-weight Linux desktop pretty fine, with even two user sessions. The merit goes much to the U160 SCSI server grade disk system that only got outdated in the rather recent years by the SATA architecture. The origins of that box go still further into the history, as it is basically the direct offspring of my first Linux box from the days of RH 4.2 (and I mean RH before the days of RHEL or even Centos, literally in the last century).

I'd rather build new systems alongside of the current ones, so that there's time to slowly work on the new box to get everything going fine and dandy, but this was to be a "old junk out, new junk in" style of operation. Regarding the HW part of it it was pretty simple, only the main board with CPU and memory needed to be replaced and the SSD installed, since PSU was fairly recent and had enough wattage for the new setup, mostly since I'm doing fine with the integrated GPU in the new i7, and even the CPU was low-power model. Just plug back in the SCSI adapter and the 2nd NIC and power back on. It was a no-brainer to get the system to boot back to Debian 7.5, and everything was running so fast and smoothly already - but it was running all 32-bit.

Since I have experience of both doing fresh installs and major upgrades, I've noticed that I like more the upgrade path since there's no need to rebuild configuration piece-by-piece afterwards, but rather get everything in place in a big but process-wise simple effort. First, I intended to upgrade to 64-bit kernel with SMP support to get all CPUs and full RAM into use. I've not done cross-compiling earlier and after some futile efforts to get the Debian kernel build tools to produce a working 64-bit kernel (I might have succeeded without using .deb build but I've learnt to like the concept too much to diverge) I went with a stock kernel from the repository. Great, it supported all the important hardware out-of-the-box (and yay, it was the first time I'm running stock kernel in many years). But what about the rest of the software? A 64-bit kernel can run it just fine with IA32 emulation, but isn't it a bit dumb to only be able to get some of the performance of the shiny HW... That's what I thought, and went googling about converting the system from 32-bit to 64-bit.

That's where the crux of the story comes in.

There are plenty of pages giving some instructions and also some warnings (e.g. this askubuntu.com Q&A which says 'it is very complicated' and is absolutely correct about it). Debian wiki has a great article on architecture migration which I decided to follow. I got pretty far with it (that's why I called it a great article), but eventually I couldn't get all packages to reinstall, and aptitude was acting pretty confused (initially it didn't list any packages under Installed packages even though it did admit that I had packages in installed state, and even after I told it to rethink it (with forget new packages + update) it still was in denial about the overall state of affairs. What was more worrying, there were quite a lot of errors about libs being of wrong architecture. I got some individual packages fixed using the same manual procedure as for resolving conflicts during the mass-upgrade/migration, but eventually I felt that this is not going to end up with a wholly working system. Looking at it now, I did some mistakes in the process which at least made things harder, so I think it still should be possible to follow the article successfully, but definitely it is not an easy path and requires knowledge on resolving package conflicts (doing a couple of dist-upgrades when the Debian team releases new stable release is a good prerequisite). After all apt is a terrific package management system, IMO, and can do all kinds of stunts in the hands of an expert.

So, after wasting many hours down the upgrade path I gave up, downloaded an install ISO and started over. After approximately the same amount of work I spent on the upgrade attempt I now have pretty much all major things in place and working and after all, now I know that if something is off, I just need to compare things with the old state of affairs that can be found on the old disks and migrate the changes. It is also a good chance to re-learn some things like setting up DAV on Apache for use with Subversion.

What is to be learnt from all this? At least for the kinds of me who prefer building on the old, it is good to learn to consider the benefits of a fresh start, and the downsides of carrying the load of the past over the new platform. What might help with this is having some sort of a configuration management system that could be used to restore at least part of the customisation that has to be re-done. Having that at home might still be an over-kill, though...