Troubleshooters.Com®, Linux Library, and T.C Void Linux Subsite Present:

Debian to Void Conversion


In the Beginning

I used Mandrake/Mandriva 2000-2009, and Ubuntu/Xubuntu/Lubuntu 2009-early 2014.

In February 2014 I switched to Debian, because Ubuntu's constant hand holding impeded me from configuring the machine the way I wanted. I had used OpenBSD, and wanted something like that, but in Linux. Debian was great: Once again a lot of my configuration was via editor, not GUI. Once again, my shellscripts weren't defeated by handholding. But in an ironic twist, I moved to Debian almost at the moment when they decided to switch to systemd.

I continued using Debian Wheezy, the last Debian that didn't use systemd as PID1. The next version, Debian Jesse, was released April 26, 2014, but even though by this time my Wheezy setup was suffering some serious bit rot, I stayed with it while I decided my next move. Any of the following would have worked, although some were harder than others, and none of them really made me happy:

I wasn't happy with the package manager in PC-BSD. I worried that Manjaro-OpenRC might go unmaintained sooner or later. Funtoo's installation by compilation was just too time consuming. Alt-initting a systemd distro is a challenge because systemd tightly ties the init system with several other OS functionalities, so you need to replace all those functionalities, not just the init. Devuan's ever closer to stable release, but not there yet.

In September 2015 someone steered me to Void Linux.


I put Void Linux on a Qemu VM. At first it was very difficult because Void's documentation is sparse, scattered, and often contradictory. But once it ran, it was everything I've sought in an OS. It had the sane configuration and package management of OpenBSD, but unlike OpenBSD, it had a very functional hardware assisted Qemu. It was more DIY friendly than pre-systemd Debian. It was down there in the metal along with Arch (before Arch went systemd), but it bestowed the choice of either Arch-type chroot installation, or installation by script (like Debian). It looked like my dream Linux. But one experiment does not a decision make.

I put it on more and more VMs, hammering it hard and experimenting freely. Void behaved sanely under all conditions. I put it on a 9 year old laptop: The laptop got a new lease on life.

I put Void Linux on my main laptop, an 8GB RAM quad core AMD with hardware VM. It worked beautifully. I installed a Ubuntu 15.04 hardware assisted VM guest on the laptop, it performed perfectly. Switching my business to Void Linux became a plan, not just an idea. The plan can still be backed out of, but it's a plan that's being worked.

The LyX Dilemma

Good news:

The LyX dilemma was solved for good about nine months after my Void conversion, and that solution is discussed at the bottom of this section. Nonetheless, I recommend reading this entire section to understand the power of Qemu for running that one app that just won't work on your current distro.

Of course, I tested all the software critical to my business. LyX, Sigil, PdfTk, Bluefish, Firefox, Claws-Mail, Dovecot, Fetchmail, Procmail. Everything worked perfectly. Except LyX.

LyX was packaged with Void, and it worked, but not on my books that I sell. A day of troubleshooting brought me only slightly closer to getting my books to compile. So I fired up a Ubuntu 14.04LTS Qemu VM with LyX in it, performed an sshfs mount to the data partition containing my books, and bang, I had a working LyX that could compile my books.

This is the reason I rejected OpenBSD a year ago. No matter what distribution of what is used, there will be that piece of mission-critical, irreplaceable software it just won't run. This fact makes it absolutely vital to be able to run a VM system like Qemu, a container system like Docker, or both. VMs and containers are your escape hatch when your distro doesn't provide.

Having problems with the packaged version of LyX, I tried hand-compiling LyX, but was stopped by the same old boogie-man: Qt4. Void has only Qt5, and, in a reasonable time, I couldn't find a way to overcome that problem.

Nor was I particularly eager to get LyX to work. For the past decade, LyX has been drifting one way, and I've been drifting another. My long term solution will be to either finish my Stylz authoring environment, or move to MultiMarkdown, or a combination of the two.

But for now, Qemu gave me a way to very quickly get past this showstopper.

The LyX Has Been Solved

About nine months after the Void conversion, I noticed my buddy's books compiled on the same Void LyX that failed to compile mine. Exploiting the differences, it became clear that I was using the Century Schoolbook New fonts, whereas he was using the almost identical Tex Gyre Schola, TeX Gyre Heros, and Tex Gyre Cursor fonts. I changed to those fonts in my books, and my books compiled. So I'm happily using LyX natively on my Void OS.

I'm eternally grateful for Qemu's bestowed ability to run LyX on a Ubuntu 14.04LTS VM guest. My business couldn't have endured nine months of not producing and personalizing books, so without Qemu and Ubuntu I could never have switched to Void.

My Stylz styles-based authoring project has been put on hold. It's too challenging for my time constraints, and as originally specified it would have been too slow to author. Also, I discovered that LyX authored PDFs can be sized 5"x3" for mobile devices, and still read on regular computer screens.

Nonetheless, sooner or later I'll need to move to styles-based authoring. The LyX project has a very strong sense of priorities, and creating simple, correct xhtml capable of creating eBooks that pass vendor tests is not their priority. I've recently discovered that Markdown creates very nice HTML that can easily be augmented with character and paragraph styles sufficient for most writing tasks, thus making a true write-once, read-everywhere authoring tool that doesn't depend crazy stuff like XSLT. I'm continuing to investigate rapid-authoring, styles-based authoring tools.

Planning the Work

When running a business off a computer, it's a bad idea to significantly upgrade that computer, without temporarily transferring operations to an intermediate computer. I learned this, the hard way, while adding a motherboard to my daily-driver computer in the 20th century. Taking your main computer down for a substantial upgrade just puts too much pressure on you to get it up fast.

On my Debian Wheezy Desktop, I ran created and ran a shellscript called, in order to have guidance in setting up my new computer the same way the old one had been set up. It's too wide to show in this document, but you can see it here. I put the files created by on an ext4 formatted thumb drive, together with some other files that might be needed.


It's October 6, 2015 as this is being written. A better hard disk has been ordered for my daily driver. My 8GB RAM Void laptop is functioning beautifully, with much of the software used on my daily driver, and much of my data. Some time in the next few days I'll take one last backup of my daily driver desktop, and transfer operations to the laptop. If all goes well with the laptop, the desktop will have its new disk installed, and Void installed, and all my data and programs installed.

Part of the plan is to find an xbps command to list every package installed on the laptop. That list will be turned into a few shellscripts to install all necessary software on the soon to be daily driver desktop.

Working the Plan

This is being written on October 18, on my Void-equipped Daily Driver Desktop, which runs my business completely. The laptop is now a "just in case" backup.

The xbps command I was seeking was the following:

xbps-query -m

Or, spiced up a little bit to get rid of the version numbers and put the content in a shellscript called, it looks like this:

xbps-query -m | \
  sed -e "s/-[[:digit:]].*//" \

After running the preceding command on my laptop, I put on my thumb drive, for later use installing over 100 packages on the desktop, substantially replicating the laptop on the desktop.

With the laptop running my business, it was time to deal with the desktop. I connected the brand new drive, booted Debian Wheezy, and formatted the new drive according to the information from the old drive, but with bigger partitions (it was a bigger drive).

An lsblk command produced a list of all partitions in the newly formatted new disk, with each partition having a label and UUID. A little shellscript-fu and I had a shellscript to mount all the new partitions, by UUID, under /mnt/newdisk/. Then I tree copied the old mounted partitions to the new ones, and also used rsync to get the new disks right up to date using the latest files on the laptop.

Before shutting down Wheezy for the last time, I used lsblk (as root) to make a list of the partitions on the new disk, both labels and UUIDs. As usual, the list went on the thumb drive.

Next I booted the Void Live CD. Using Parted, I partitioned and formatted the other two disks: The ones with the OS on them. The new labels and UUIDs went on the thumb drive, as usual. Then I ran sudo void-installer, telling it which partitions to use. Only partitions actually needed for installation (/, /, /, /, /boot, /tmp, /var, /run, /home, were declared during installation. The rest could be done later. /home was the only one not being formatted and written by the installation procedure, so I had to be careful with it. I kept the entire /usr tree on the root partition, which is the only partition on a 256GB SSD.

After installing and rebooting, using the list of partitions made earlier, I added new disk's partitions to /etc/fstab, using the UUID= syntax. My mama didn't raise no fool, I mounted them read-only to make sure everything was what I thought it was. Only after everything appeared good did I remove the readonly options from /etc/fstab.

My New Box

I've switched distros four times in fourteen years, and used alternate distros in a few of my laptops. When switching distros, little gotchas always pop up. The past few days I've been finding and fixing those gotchas.

My box is faster and crisper than it was under Debian. That might be because I replaced a WD Green data drive with an HGST, or it might be because Void is considerably less bloated. The other thing I've noticed is I now have a much more determinate box. How it works today is how it worked an hour ago and how it will work tomorrow. There's very little intermittence.

In order not to use systemd, I had continued using Debian Wheezy long past its "best used by" date. My Wheezy had serious bit rot. About a year ago the cursor began disappearing when not moving, doubling effort and time making graphics in Dia and Inkscape. It wasn't a matter of the unclutter program: I removed that, no change. Finally, with Void, that problem's gone. Hallelujah. Other obvious bit-rotisms are gone too. Oh, and no more of those nag screens telling me I have an old version of flash. Videos, including Youtube videos, just work(tm).

[ Training | Troubleshooters.Com | Email Steve Litt ]