My long-lived personal Linux installs

September 7, 2021

At work, we reinstall our servers to "upgrade" OS versions, rather than try to upgrade them in place, so our OS installs all have a finite lifetime. Sometimes this is a pretty long lifetime (we still have CentOS 7 machines running and will probably run them until close to when CentOS 7 goes out of support), but more often this is around four years since we mostly use Ubuntu LTS. However, this is not what I do on my own machines, as I mentioned recently in my entry on what my first Linux was.

For my own machines, I basically keep upgrading a single Linux install in place for as long as I can (and as a consequence, I keep using the same Linux distribution). At this point, my work desktop has not been reinstalled since 2006, when it was originally installed (and the only reason it was installed then is that I changed jobs within the university). My home machine has been reinstalled once, but that was because I kept not upgrading Fedora for entirely too long, to the point where it was easier to buy a new set of hardware, install Fedora on it, and migrate my data. Since that 2011 reinstall, I've been upgrading it in place.

This doesn't mean that I've kept the same hardware that long; all of my own Linux machines have had various different hardware incarnations. Since 2006, when I can easily keep track, I've had three generations of desktop hardware both at home and at work. This just counts the main hardware for my desktops (the motherboard, case, and so on); the disk drives have turned over more than that. But when I've gotten entirely new hardware I've transplanted the disks, and when I've gotten new disks I've moved the data.

(The laptop situation is more complicated. When I got a new laptop, I installed Fedora on it from scratch as the most convenient way and then copied my user data over. However, since then I have been upgrading Fedora in place.)

I keep doing in-place upgrades rather than reinstalls not out of any principle but because it's the much easier way, at least at any given moment in time. If I upgrade in place I don't have to redo my customizations, remember all of the extra packages I've installed that I care about, slog through the Fedora install process, or worry about making sure my own data is untouched through the entire reinstall. People who were more organized would keep careful track of all of their customizations (perhaps in an automated system) and their important additional packages, and keep all of their own data on separate disks that can be entirely disconnected during a reinstall. These people would avoid my problems with layers and layers of what can politely be called historical artifacts on my systems (including historical packages), and would never have gotten into my Fedora 8 situation in the first place.

(Unsurprisingly, this is how our Ubuntu install process works. It's an especially good idea to have a reliable record of your customizations to the system, both to keep track of them and to spot ones that aren't needed or desirable any more.)

Comments on this page:

By David D. at 2021-09-08 10:42:54:

My desktop machine is a Debian install from 1999. It's just so easy to move a hard drive over to a new motherboard, verify that it boots, and button up the case.

For me it's a bit more complicated since I run custom-compiled kernels with hardware I use compiled in non-modular, hardware I don't use not compiled at all, and only use kernel modules for bits of the kernel I'm hacking on, but it's still not difficult. Usually, the old kernel at least boots single-user, after which I build a new kernel with the correct network driver and processor-specific optimizations.

E.g. when I finally got 64-bit hardware, I booted the 32-bit kernel on the new 64-bit hardware, then compiled a 64-bit kernel and rebooted into that. (To my amazement, it worked first time.)

Since it started life as a 32-bit install, it's a mix of i386 (most things) and amd64 (things that benefit from a larger address space, esp. git) binaries. I keep meaning to try adding some x32 to the mix.

(One nagging bug is that the Debian git package Depends: on perl rather than perl:any even though 64-bit git can use 32-bit perl just fine.)

If I'm upgrading storage, it's similar: copy the file system over, run lilo (who needs this newfangled grub thing?) with the appropriate "install as if this were BIOS drive 0x80" options, configure the motherboard to boot off the new hard drive, and voila.

Written on 07 September 2021.
« Why Nutch-based web spiders are now blocked here
The "web" TLS world is different from the non-public one in practice »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Sep 7 23:33:00 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.