Reviving a netbook (Part II – Virtual Tests)

Part I - Part III/I

Silly me for having made all my Linux partitions too small for VM tests, so there was no way around going back to my old setup on Windows 10. Right off the bat, I was greeted with a BSOD, ironically foreshadowing how most virtual tests eventually turned out and forced me to improvise.

Recap

As stated in Part I, this netbook is getting a second chance as as a boring digital typewriter. As Windows 7 Starter is too heavy and limited, it's set to receive a similar treatment that I granted to my other machines struggling noticeably under Windows, yet with the twist that it's a pure 32-bit machine with very low specs even for the period it was sold. Since some of its physical parts are broken or are about to break (and did indeed break when I tried to open the case, losing one out of its three USB ports in the process), the OS of my choice has to be sufficient enough to merely allow me to type some text outdoors until this machine's ready to be fully disassembled and its HDD ending up in my old 32-bit tower, which currently is being used as a recovery machine for an ancient and never-patched Windows XP install from another, even older machine.

Virtual tests inside VirtualBox are set to pose as the first look on some operating systems that may breathe some new life into this eMachines. The list includes some Linux distributions I already am familiar with and some I haven't touched prior to this. While my version of VirtualBox isn't exactly recent and its updater is being blocked by some new requirement I already tried to install but repeatedly failed, I decided to use my old test regime as is and did nothing but set every machine to 32 bit whilst fulling my first ISO's.

Unlike previous tests, however, those are quick tests, meaning that I'll only focus on how well each OS runs under some of the emulated specs and how easily they can be customized to offer and run a very small set of software. Internet connectivity will be limited to the initial setup and customization, alongside major updates that still will be compatible with the netbook in the foreseeable future.

Parabola GNU/Linux-libre

Politics aside, Parabola theoretically gets the closest to my main machine's setup by being based on Arch Linux. Unlike Arch, however, not only does Parabola still offer support for some 32-bit processors but also provides an OS running on OpenRC.

Except the last part hasn't been true for quite some time. When I wanted to download the respective ISO file, it turned out that Parabola no longer offers any OpenRC-ISO's, plus the mentioned “Live ISO” for 32-bit machines no longer exists, either. What's left is a Live-ISO and an install media for 64-bit machines running on systemd... and a 32-bit netinstall ISO running on systemd. Parabola's wiki states that the install media doesn't matter in terms of init choice, so I downloaded the only ISO available for my netbook.

Shortly after booting the VM, Parabola demanded an internet connectivity test by entering lynx network.html. Sloppy instruction aside, this local HTML describes various methods to connect the machine to the internet, most of which actually are irrelevant. Connection via Ethernet is stated to happen automatically via dchpd, while connection via Wifi is handled by WPA Supplicant and Network Manager – since users already familiar with Arch will have the Arch Wiki open on another machine to install their OS, I can't tell why the Arch-based Parabola decided to put all network configuration possibilities into a local HTML file, rather than its own Wiki.

Whilst updating the database and pulling my first set of packages, Pacman performed unusually slow and froze for a few minutes when downloading keyrings. That's when I noticed that Parabola is dependent on Arch Linux's 64-bit repositories, yet there's no documentation on how Parabola handles this dependency in regards to its i686 variant. Given the unusually slow performance of Pacman, I wasn't entirely confident that Parabola's Pacman configuration would respect its own repository order.

Moving on, it became obvious that Parabola indeed no longer supports OpenRC and simply never updated their documentation to reflect that. Following the installation guide's OpenRC instructions prompts Parabola to bring the process to a halt due to its repos missing both elogin and libelogind. To continue the installation, I was forced to install systemd and follow the systemd sections of the installation guide.

Because of the system often stalling, I attempted to switch to another TTY and, to my own surprise, I was asked to enter an undocumented password for root, ultimately limiting me to the non-progressing TTY1. The first installation attempt ended even before I reached the OpenRC discovery and starting from scratch again caused Parabola to be unresponsive for more than a minute after booting. Pacman continued to freeze during the base install for approximately ten seconds but eventually progressed to mkinitcpio, which seemingly hasn't been updated to support the new microcode hook introduced by Arch a few weeks ago. Closely following Parabola's guide will install two libre-kernels. After over an hour, the installation finally finished.

(Is your head aching, too? I'm used to installing Arch “the Arch way” but this was shockingly tedious.)

The installed system was even more painful. Apparently, my normal user was able to login but lacked a name (I have no name!@Parabola) but attempting to change this via root caused the root user to instantly crash upon login, producing a long list of failed applications in its respective coredump. It took five minutes of waiting for the crashing to stop on its own and that's where I began to notice that automatic Ethernet configuration via dchp is not done on the installed system, the keymap reverted back to US, the root user casing a hard-to-catch “invalid” error, and the output of Parabola-specific outputs in systemd's journal is printed in an unreadable blue color.

At this point, I simply gave up.

Devuan GNU/Linux 5.0.0 “Deadalus”

The first OS I'm quite familiar with. I already tested Devuan a few years ago, though gave it a more mixed rating due to being nothing but Debian with a different init. It did perform without any significant issues, so it ended up high on my list of potential OS'.

Sadly, the Live-ISO refused to boot within an virtual environment, as the kernel complained about being incompatible with the virtualized system. I grabbed the netinstall and encountered no such issue, letting me install Devuan with Xfce and OpenRC.

The installed system requires half of the resources Windows 7 Starter demands; RAM resides around 378 MB of RAM and only exceeds 10% CPU usage when running a graphical web browser. The only downside I managed to discover for my use-case is Devuan not allowing some sort of granular installation of packages during the initial setup. No matter which option is chosen, I always end up with the complete suite of LibreOffice and CUPS. While CUPS can be removed, LibreOffice ends up in a circular dependency between its graphical and its CLI core; removing one of those will automatically install the other and vice versa.

antiX 23.1

Next up was another distribution I already am quite familiar with. This one's fairly special as it is among the most lightweight distributions I've got to mess around with and has been extremely gentle towards virtual machines and bare metal. The biggest issue of antiX, on the other hand, is its Desktop experience. Anything from the plain ugliness that is this configuration of SLIM to each session's config clashing with each other and the German translation being a mixture of “Denglish”, typos and just plain bizarre translations was present back then, which effectively pushed me away from installing it on my old tower.

As it seems, this newer version suffers from the same issues I encountered years ago. While it remains extremely resourceful, “ricing” this mess to get some sanity into the graphical experience will be a hassle because antiX ships with not only one but two pre-configured Fluxbox sessions.

Another downside I missed during my last test is antiX's package management. Directly calling apt to install new packages quits with an error. anxtiX ships with its own package manager based on apt called “clu-aptiX. While perfectly suited for users with little familiarity with commands, this method of managing packages stretches a simple sudo apt install htop to consume a solid two minutes because users first have to invoke a search query, then mark the package for installation and select the appropriate option to actually install the package. Yes, it's Synaptic's CLI variant and I'm not against its existence at all, however this being the only way to manage packages on antiX is weird and unintuitive to me, to say the least.

Out of curiosity, I downloaded antiX-core to test this project's X-powered minimal install. Unfortunately, it freezes right after booting with an SELinux error, an inittab.d error and ultimately getting stuck at populating /dev.

Slackware and Porteus Linux

Both ended up with the same issues as Devuan's Live-ISO. I tried the other kernel provided by Slackware, yet this one caused a kernel panic.

(Things begin to look rather grim at this point because I did not expect the rock-solid Slackware to fail this spectacularly.)

Void Linux

Both the Xfce-ISO and the base image encountered the same issue with pae. Sadly enough, I still loathe cfdisk and the live desktop performed slightly worse on bare metal than Devuan, disqualifying Void entirely.

Salix

Reading more into the current states of Tiny Core and ALT, I decided to drop both in favor of Salix.

Salix is interesting insofar, as it's one of the few Slckware-based distributions to offer dependency management and its own package manager. I was even more surprised to discover that it offers a bunch of non-pae boot options on its live media. Its installer, while vastly different from what I got to test during the years, still seemed fairly decent.

The installed system shipped with four boot options, two of which made the VM crash instantly. The other two attempted to access my host's microphone and Salix no longer seemed to remember the user password I set roughly 13 minutes prior. Replication of this weird behavior only partially succeeded, with the two “smp” options still crashing the VM but no option attempting to access my microphone. My user also worked, however attempting to test the package manager was unsuccessful, as all pre-configured Slackware repositories were inaccessible.

The “second chance” live test on bare metal

The failure of Slackware prompted me to consider an additional way to test at least those distributions offering a live environment, namely Devuan, Porteus and Void.

During this parallel test, Devuan's Live-ISO proved to be fully compatible with my hardware and worked fairly well. Porteus, despite generating a few errors during boot, also worked well, yet ultimately was being scrapped like Tiny Core due to only supporting a frugal install (and the mouse pointer being WAY too fast). Void, almost shockingly because it's the only distribution relying on runit, was as heavy as Devuan and took much longer to boot for some reason I cannot explain.

I also gave Salix a second chance and it proved to be lighter on my hardware than both Devuan and Void, plus the “special repos” also were working.

Gentoo

I already tried its 64-bit variant a while ago, only to fail at downloading a pre-built kernel due to confusing documentation regarding Gentoo's binary repository. Jut like last time, I'd fail at this very step, yet this time it failed because the pre-compiled kernel was masked by Gentoo due to critical bugs.

Alpine

The last OS on my list. Because Devuan and Salix passed their “live tests” and thus already claimed both spots for this round, Alpine ended up being scrapped.

TL;DR

The two distributions that made it into the final round and will be installed on this netbook:

This had to be the most chaotic series of tests I've ever done after more than a year since my last test. Each distribution that didn't pass the initial two rounds suffered from different issues:

Since this post is already long enough, Part III will deal with both Devuan and Salix and how each performs as an installed OS. Part III will also include a summary of this netbook's specs.