Jared asked the right question yesterday, when I proclaimed I had Arch Linux running on a Pentium MMX machine. How does a distro cut to fit the i686 generation downscale to an i586? After all, the two architectures are different, and software compiled for the newer, as a general rule, can’t run on the older.
Well, never let anyone tell you that Arch Linux won’t run on an i586 machine. It’s not true. It’s not intended to run on an i586 machine, but that doesn’t mean it won’t. It just means it’s a bit more work.
Arch has always won points — and will always win points — for being easy to customize to the machine you use. That is why many people use it: You can achieve almost any result with Arch, and get there via the path of least resistance.
At the same time, Arch saves you an immense amount of time by allowing you to avoid building software from scratch. I will be the first person to acknowledge that yes, while I enjoy working with Crux, the wait for system updates is directly proportional to the age of the machine. And sometimes, it gets scary.
But there have been many attempts to share Arch’s ease of use with other, outside architectures, but sadly they always seem to sputter. There was the Lowarch project from a few years ago, which I still seed the torrent for. And about a year and a half ago I mentioned the archi586 repos, which you could use to hopscotch up to then-current.
Around the same time an archlinux-i586 effort popped up on Google Code … and seems to have slipped away as well. Most recently (perhaps) is the archlinux-i586.org site, but its repos are now offline too. (Although there are some updates at github, where the project seems to have been hosted.)
I don’t hold out any hope for a sudden upsurge in the demand for an i586 version of Arch Linux; I have seen enough of them come and go to know that they’re unlikely to take hold. On the other hand though, any one of those should at least get you started, and give you the chance to put a version of Arch into place and work your way up.
But what about updates? How do you move from, for example, the last available Arch Linux ISO tailored to an i586 machine to current?
Well, unfortunately, you’re probably going to have to get your hands dirty. The aforementioned ease of installation that comes with Arch on an i686 machine is sometimes, occasionally also available for i586s, but even without it, you can get the job done. If you compile by yourself.
Now I don’t like to build software on machines as old as this, and generally speaking if I have to make updates to it in Crux, I yank the drive and chroot via another computer. I can borrow the processor on this machine, for example, and update in a fraction of the time it would otherwise take.
Arch, on the other hand, has some nifty tools for building your own versions of software, and transporting them across international boundaries.
The most obvious, and among Arch’s Greatest Hits, is the abs tool, which will mirror the current Arch build scripts onto your local system. From there, almost anything is possible, so long as you’re willing to take the time to build things yourself.
Personally I suggest doing this on a faster machine, if you have one you can spare. Sync with the abs tree, then rsync that into your home directory, in something like /home/kmandla/i586/abs. From there you’ll need to make a custom makepkg.conf and abs.conf file; I suggest
cp /etc/makepkg.conf ~/.makepkg.conf
cp /etc/abs.conf ~/.abs.conf
Edit one or both of those to match your architecture (here’s the Gentoo wiki page on safe CFLAGS, which you’ll want to check), and from there you can build packages as a non-root user, for an architecture other than the host.
If you like, you can tell
makeworld to dump the results into a destination folder (i586/pkg in my case), and then build a portable repo to move between machines. Once all your packages are in place, use the
repo-add command to create a database file for all those packages. And you can shuttle that entire business between machines to install. Of course, you’ll need to tell your target machine where to find the database file; try adding a
file:///-style entry to /etc/pacman.conf, or inside /etc/pacman.d/.
I can offer a few tips though: For one thing, if you build a custom repository for updates, make sure the name of the database you create matches the name of the database the original packages came from. For example, if you’re building an updated version of udev (just as an example), make sure you put it in a repository called “core,” because it was installed from the category “core.” If you don’t then your system won’t update properly, and you’ll have to upgrade packages one-by-one.
Additionally you have logs about package build results, but for my case, the log was filled with “failed” builds (which were actually fine). The only way I could see if there was a truly failed package was to compare the build log with the contents of my pkg folder; if a package was missing, it didn’t get built.
The only things that have failed spectacularly with this heart-transplant system are the kernel structure. That makes sense though, since you should probably build and package a kernel in another fashion, rather than by trying to rebuild the stock PKGBUILD with just a different architecture.
makeworld for the core repository only on this machine took over 400 minutes to complete. So be aware.
I should finish by saying that I didn’t bother installing X or anything even remotely graphical on the Mebius, mostly because I have no interest in laboring a machine of that era with a graphical desktop. Or do I … ?
P.S.: Sorry this post was so long. And whether or not the same stunt is possible with Ubuntu after Meerkat remains to be seen. But probably not by me. The idea is so unattractive as to be laughable.