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

Void Linux Tips

Copyright © 2015 by Steve Litt

Contents:

• Introduction
• Summary

Introduction

Here are some tips for installing and using Void Linux:

• Install with void-installer, as root.
• Install from DVD unless you really know what you're doing.
• Consult Distrowatch Package Management.
• xlocate: The Ninja Package Finder
• Consult #xbps on Freenode for intelligent help
• Shut off void-pkgs and xbps-builder
• On install problems, xbps-install -Su
• Set root's shell to bash
• Create a normal user
• Set the default pager
• Get familiar with the ip commands.
• Gotcha: Networking Void at McDonald's
• Set up wifi networking with wpa_supplicant.
• Install elinks and wgetpaste
• Install text irc clients
• Understand runit and how Void uses it.
• Change the screen BPI
• Add a normal user directory to the path
• Install a dmenu interface
• Back up studiously.
• Enable video, sound, Youtube
• Fix audio card monopolization
• Get Xombrero Working Right
• Set Your Default Browser
• Fix Gstreamer Problem in Clementine
• Fix Keyboard Doesn't Work in X
• Compile Bluefish for zencoding.
• Enable Dovecot
• Install Udftools
• Installing Perl DateTime.pm on Void
• Adding a (Sub) Repository to the Package Manager
• Contribute to Void

Install with void-installer, as root.

Void is a wonderful distro with lousy documentation. Some docs don't tell you what program to run, on the live CD, to install. Other docs make it seem like your only choice is doing a chroot install. This is usually not true.

Typically, the easiest way to install Void Linux once you have your hardware set up is to boot the Void Linux live DVD, become root, and then run the program void-installer, and for the most part follow its prompts. void-installer has an easy to follow menu interface.

Here's how you become root on a tty or GUI terminal on the live Void CD:

sudo su -

No password is needed.

On the installation difficulty scale between Lubuntu and Gentoo/Funtoo, void-installer is significantly closer to Lubuntu. The main challenges, on lowest common denominator installs using MBR boot without LVM or LUKS, is that you'll be given cfdisk to partition your disk. As always, I recommend you first do a rehearsal install, with no fancy stuff, on a Qemu VM guest.

By the way, toward the end of the install, in the "Filesystems" part of the install, the dialog box gives you no way to signify "Done", so when you're done you need to select "Back" to go back to the menu. When you get to this point, and perhaps do an extra iteration, it will be obvious what to do.

Install from DVD unless you really know what you're doing.

I'm an elder in the Church of the Known State, and as such, I like installing off a DVD rather than straight off a Git repository. Yes, I know that Void is a rolling release, and the first time I upgrade my known state will be history, but I still prefer to go off a Void live DVD.

Once the live DVD boots up, I just run void-installer, and I'm on my way.

Consult Distrowatch Package Management.

Consult http://distrowatch.com/dwres.php?resource=package-management.

Most distros (notoriously excluding Arch and Gentoo) have lousy documentation. Void takes it the extra mile, with little official documentation, much of which is out of date and/or contradictory. This creates real difficulty for the person not knowing a specific package manager.

No problem. DistroWatch.Com has a wonderful "Rosetta Stone" for package managers, at http://distrowatch.com/dwres.php?resource=package-management.. This document has the right mix of commands: Enough to do what you usually need to do, without obfuscating those necessary commands in a sea of geeky, seldom used commands. And better yet, because this page shows the specific package manager command, in each of more than 10 package managers, for each of these often used tasks, if you know any package manager, you can figure out how to do it in Void's package manager, xbps. For that matter, you can figure out how to do it in any listed package manager.

When you use xbps-install, all you need to do for the package name is type enough to uniquely identify it, starting from the front. So to install the bitchx package, all that's needed is:

xbps-install bitchx

However, the following fails to install sshfs:

xbps-install sshfs

The problem is, the actual package containing sshfs is actually called fuse-sshfs-2.5_4, so the following command would have been sufficient:

xbps-install fuse-sshfs

But of course, there's no way of knowing this in advance, with out a lot of research. This is why the xbps-query command is included. There are a few especially valuable search commands that aren't immediately obvious. For instance, to search the repositories for the exact package name of something, perform the following command:

xbps-query -Rs package_name_fragment

In the preceding, package_name_fragment is part of a string you suspect will be in the package name. For instance, fuse-sshfs can be found using sshfs as the fragment.

Sometimes you need to know the name of the package providing a certain file. This is not obvious, and it can often take significant time to search the repositories if the file's not already on your computer. If the file's on any Void Linux computer you can reach, your best bet is to find the package name there, with the following command:

xbps-query --regex -o filename

In the preceding, "filename" doesn't include the path to the filename. So it would be something like "sshfs" or "sfdisk". What enables the use of only the filename is the --regex option.

In situations where the file is not installed locally, and there's no available computer with it installed locally, and you need to install a file, but the package name bears little resemblance to the name of the file, you need to search the repositories for a package with that file: A very slow process. I can't say how slow, because I've never let such a search run to completion, but if fortune smiles, the right package name could be delivered to you in four or five minutes:

xbps-query --regex -Ro libphonon

As each result comes in, you can test it with xbps-query -Rf.

These repository searches for included filenames are so slow that almost any alternative is superior. If you know of a command that returns a packagename faster, when fed an uninstalled filename, please email me.

One more thing. In this document I say some pretty unkind things about Void's documentation. Well, I'd rather have bad documentation of great software, rather than the other way around. There will always be guys like me around to write better documentation, if the software's good enough to care about. And Void Linux is great software.

xlocate: The Ninja Package Finder

The commands in the preceding section are good, but sometimes insufficient to find a needed package. That's why Void Linux comes with xlocate. xlocate is a caching package searcher, so its database must be built and updated from time to time. It's not in Void's base system, so you'll need to install it. It's in the xtools package, so here's how you install it:

xbps-install xtools

Now that it's installed, you must build the database with the following command:

xlocate -S

The preceding command is used not only to initially build your database, but to keep it fresh. I rerun the preceding command every two or three days.

I perform the preceding command as the normal username I normally use. This command takes only a minute or two to complete (except possibly the very first time you run it).

Once the database is built, you can locate any package in the repository by issuing the following command as root:

xlocate searchstring

searchstring can be a part of the package name, or a file that gets installed, or a key, or almost anything, and the command produces lots and lots of results. Maybe a confusing amount of results. Often you can simplify the command's result list using the following command:

xlocate mkisofs | cut -f1 | sort -u

Xlocate gotchas and landmines

There's no xlocate man page. xlocate -h gives you information for the plain old locate command, which isn't what you need. The information at https://github.com/voidlinux/documentation/wiki/FAQ doesn't discuss the issue of needing to xbps-install -Su before rebuilding the xlocate database, nor does it tell you the command syntax and arguments. One could be forgiven for throwing up one's hands in frustration and not using xlocate. Hence this document section.

Just make sure you always do xbps-install -Su immediately before doing xlocate -S. This should prevent corruption of the xlocate database. Always perform these two commands as root.

What xlocate really is is a shellscript capable of two tasks. With the -S argument, it performs a sometimes git' command and puts it in a local git repository searchable with the ordinary locate command. If the argument is anything else, it performs a locate command on the repository, which iswithin $HOME/.cache/xlocate.git..

Consult #xbps on Freenode for intelligent help

The IRC channel for Void Linux is called #xbps. Fire up an IRC client, log into Freenode, and join #xbps. But before asking anything, be sure you've searched the fantastic web for the answer and any relevant material. Void isn't Ubuntu, and #xbps isn't there for hand-holding.

Interesting story: A few days ago I asked on #xbps how to install Bluefish with Python compiled in, so that Bluefish would have its flagship Zencoding feature. One person apparently tightly connected to the Void project gave me a package-manager method I didn't quite understand, and then asked another person why Bluefish wasn't compiled with Python by default. An update a couple days later made my Bluefish Python-enabled, with Zencoding.

This isn't to say that #xbps is there to change the Void project to meet your needs, but it does indicate that the people on #xbps are listening when you ask a question.

Shut off void-pkgs and xbps-builder

On the #xbps IRC channel on Freenode, a whole lot of messages from bots void-pkgs and xbps-builder scroll by. If you're like me, these obscure real human questions and answers. If you're like me, you'll shut off these bot messages with the following commands:

• /ignore void-pkgs
• /ignore xbps-builder

On install problems, xbps-install -Su

Sometimes you'll have installs crash in the middle, and you might think "oh, this thing is buggy." The error messages are sometimes unhelpful.

When Void installations crash on you, before trying to figure out anything else, update your software by performing the following two commands, in the following order:

xbps-install -Su

3/4 of the time, after performing those two commands, your install problem vanishes.

Set root's shell to bash

void-installer wisely sets the shell for the root user to sh. This is better for security. So if your situation requires prioritizing security, it's best to leave well enough alone and skip the rest of this section.

For desktop users and experimenters, the big gain in bash usability is often worth its smaller security cost. If that's your situation, it's best to switch root's shell to bash and do it early on. Simply log in as root, edit /etc/passwd, and on the line starting with "root", change /bin/sh to /bin/bash.

Create a normal user

The void-installer program doesn't walk you through creating a normal user. So soon after installation, perform the following steps to create a normal user (in this example, called "myuid"):

[root@acervoid ~]# useradd myuid
[root@acervoid ~]# passwd myuid
[root@acervoid ~]# usermod -aG audio,video myuid

Set the default pager

The default pager is what allows you to scroll down (and in some cases up) while you look at man pages and perform certain other tasks. Most Linux distros use less as the default pager, but Void uses the more program, which was invented some time before World War I and can page forward but not backward.

The less program uses Vim keystrokes, and can page both forward and backward. Which is why most people prefer it. If you want to change your default pager, append the following line to your .bashrc program:

export PAGER=less

In order to test your new pager setting, run bash from the command prompt in order to start a new Bash session, and then read a man page and make sure it pages with less. In the man page, verify that j scrolls one line forward and k scrolls one line backward. If those scrolls work, you're paging with less.

In order to make your new pager available everywhere, log out of X, log out of the Virtual Terminal (tty1 or whatever) from which you ran X, then log in and run X again. If you boot directly to X, log out of X and back in.

Get familiar with the ip commands.

This advice is valid in any distro. Doesn't it seem like networking is different in every distro, and that over time distros change how you signify networks? It's almost impossible to keep up with if you use multiple distros. Sometimes you'll need distro-independent methods of network troubleshooting, and that's where the ip command comes in.

Getting information

To see a list of all network devices, perform the following command:

ip link

The preceding gives you the names of all the devices, and at least a little information as to their current state. This info is all the more valuable now that we have the devices with names like enp6s1 or wlp6s2.

To see a list of the network devices with their IP4 addresses (or not, if they're down), perform the following command:

ip addr

The following short shellscript initializes wired network device enp6s1 to 192.168.100.188 with a default route of 192.168.100.96, brings up the localhost interface, and sets the hostname to whatever is in /etc/host:

#!/bin/sh
hostname=`grep -v "^\s*#"  /etc/hostname | head -n1`
ip link set dev lo up
ip link set dev enp6s1 down
ip addr add 192.168.100.188/24 dev enp6s1
ip link set dev enp6s1 up
ip route add default via 192.168.100.96

The preceding shellscript's syntax is difficult to memorize, but it's important you do so, because these are the kind of commands you use to troubleshoot a "no network" situation. Three are ip link commands that bring the linked device either up or down. So you "set dev enp6s1 up", etc. If you memorize the ip link part, that makes sense.

One command is an ip addr command, used to add an address to a device. It's kinda-sorta self-explanatory. Be sure to specify the netmask number (24 in this example) on the ip addr command, because if the netmask number is missing, it defaults the netmask number to 32, which means a subnet of one: the address of the device itself. And since it can't contact anything outside its subnet, the networking remains mute.

Last but not least is the ip route command used to add a default route. The syntax at first seems a little weird, but if you think of "default" in terms of an actual IP address, it starts to make sense.

On pretty much any distro, it's good to have these commands memorized, so that even if the distro's wonderful distro-specific networking config doesn't work, you can investigate and probably bring up the network with just ip commands.

Getting syntax help from ip itself

If you type only ip on the command prompt, the first line of information it gives you is:

Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }

It then goes on to define all the preceding. But just as a rule of thumb, options are things that begin with dashes, and I personally haven't found them all that necessary. The things they call objects are what I'd personally call subcommands: link, addr, and route. What they call "commands" start with simple verbs: set, add, del and the like. And then the next item on the command is what the verb applies to (dev followed by a device name, or an IP address or alias like default, and last but not least what's done to it.)

With the preceding as an overall understanding of ip commands, any needed specific syntax can be found with command like the following:

• ip link help
• ip addr help
• ip route help

This section barely scratched the surface of the capabilities of the ip command set, but it's enough for basic troubleshooting and enough to get a network connection if hardware and driver eixist. The technologist mastering the ip command set can quickly troubleshoot almost any problem.

Gotcha: Networking Void at McDonald's

If you do networking the way I do networking, after boot your laptop's Ethernet port is up and configured with a static IP address. This isn't a problem in most situations, but when you go to one of those places with no-security wifi hotspots that validate you through a website, it can be a problem, and a hard diagnosis if you don't know what you're looking for.

When you bring up the McDonald's free wifi, you're not connected, not really, until you go to a browser and say yes to McDonald's terms of service. Normally, their terms of service url pops up on any page you try to go to, but if you have an extra IP address, like the one from your configured and static IP address, the terms of service website won't pop up.

Before you use wpa_gui to access their wifi hotspot (this is discussed in a later article), be sure to disable your Ethernet IP address. It's as simple as performing the following command as root:

ip link set dev eno1 down

If you don't feel like logging in as root every time you issue an ip command, you could set it in sudoers as a nopasswd command.

Any time you're having trouble with wifi on the road, bring down your Ethernet. It might not fix the problem, but it will sure eliminate a lot of variables.

Set up wifi networking with wpa_supplicant.

Wifi is has always been problematic. It's problematic now. It's a problem on Windows, it's a problem on Linux. It's less of a problem on "just-works" distros like Ubuntu because of their superior hardware detection, but it's still a problem. It's actually a problem with two different components:

1. Managing the hardware's drivers and firmware.
2. Managing, choosing, and passwording the list of wifi networks.

This section is about component #2. Software solutions wpa_supplicant, Wicd, and NetworkManager all perform the duties of component #2. And there are plenty more. This section is only about managing wifi networks with wpa_supplicant.

A 5000 word essay could be written about the politics of Linux and competitors wpa_supplicant, Wicd, and NetworkManager. Suffice it to say that with the advent of systemd and increased scrutiny of dbus, wpa_supplicant, which requires neither, has been gaining mindshare.

Traditionally, wpa_supplicant has been complicated and difficult to use, an impossibility for all but the most POSIXLY endowed power user. Void Linux has made wpa_supplicant usage almost trivial.

Void's wpa_supplicant package creates files /etc/sv/wpa_supplicant/run and /etc/sv/wpa_supplicant/conf, so that wpa_supplicant can be run as a daemon that restarts after crashing. Traditionally crashing under certain well known circumstances was a problem with wpa_supplicant, but because Void Linux uses runit to supervise wpa_supplicant, it just restarts: No problem, either technically or as perceived by the user.

Prerequisite: Install dhcpcd

Wifi without DHCP is like houses without roofs. A DHCP client must be installed, Void Linux uses the excellent dhcpcd client, so perform the following command:

xbps-install dhcpcd

Then set up dhcpd to run, on boot, continuously, by enabling it in runit with the following command:

ln -s /etc/sv/dhcpcd \
  /run/runit/runsvdir/current/dhcpcd

That's it. The dhcpcd client runs, in the background, continously, now, and after every reboot.

Prerequisite: Set Up wpa_supplicant

Before you enable the daemon, be sure to change the run and conf files to reflect the true name of the Wifi device. This is found with the following simple command:

ip link

The entry with the name beginning with "wl" is the right one. In the run and conf files, change the value of WPA_INTERFACE to match that name. Then symlink:

ln -s /etc/sv/wpa_supplicant \
  /run/runit/runsvdir/current/wpa_supplicant

The daemon should now be running, which can be verified by running the sv status command on wpa_supplicant, logged in as root:

[root@littlap ~]# sv status wpa_supplicant
run: wpa_supplicant: (pid 617) 9843s; run: log: (pid 614) 9843s
[root@littlap ~]#

The preceding says it's been running, and it's been running for 9843 seconds. It's working.

wpa_supplicant and wpa_gui

The next step is to interface with wpa_supplicant using the wpa_cli command line interface client, or the much easier wpa_gui interface. Only wpa_gui is suitable for the average user, so it's the only one discussed in this section.

The wpa_supplicant server and its associated CLI and GUI clients were released in 2003 to help navigate and work with wifi networks. It worked well when used right, but using it right took some knowledge. NetworkManager, which came out in 2004, was more user friendly, but failed in some edge cases where wpa_supplicant succeeded. The cool thing about NetworkManager is it was available as an easy to use tray icon on many window managers. 2006 brought Wicd, another user friendly way to keep track of wifi networks. In my opinion it's a little more reliable than NetworkManager, but as far as I know lacks the handly little tray icon. Which of course can be an advantage if your window manager has no panel.

wpa_supplicant is tricky, crashes under certain well defined circumstances, and generally requires more attention. Its advantage over the others, however, is you can use it 100% from the command line, edit its config file to insert new networks, and connect to pretty much any wifi network in any situation. When Wicd and NetworkManager fail, wpa_supplicant is the go-to tool.

But wpa_supplicant is too high maintenance for normal users. As Wicd and NetworkManager improved, wpa_supplicant was all but abandoned, existing as only a memory of those in the business a decade ago. Then NetworkManager started requiring systemd, and a lot of people stopped using it. The dbus system, which always had its detractors and had become more associated in peoples' minds with systemd, is necessary for Wicd. Some turned their attention back to wpa_supplicant for handling lists of Wifi networks. So did Void.

The Void Linux wpa_supplicant Implementation

Void's wpa_supplicant package installs the /etc/sv/wpa_supplicant directory and its run and conf files, so that wpa_supplicant runs as a daemon, correctly, and if it crashes, it restarts instantly. This cures about 90% of the problems people had using wpa_supplicant.

Most of the remaining problems are cured by using wpa_gui to interact with wpa_supplicant. wpa_gui looks like the following:

The preceding is the "Current Status" tab. From there all you do is connect or disconnect. You can change which wifi network to connect to with the "Network" dropdown. This dropdown is not a list of networks currently in the area, it's a list of networks you've configured. Thus, if you go to a new place, before connecting to a nearby network, you need to configure that nearby network. To do that, you use the "Manage Networks" tab, as shown in the following screenshot:

So to add a nearby network, on the "Manage Networks" tab you'd click the Scan button, click the Scan button on the resulting screen, and from the list doubleclick the one you want to add to your list of configured networks. See the screenshot for the scan, as follows:

From the scan results list, you can double click the network of your choice, which brings you into the configuration window for that network. You can fill in the passphrase (PSK) and any other necessary information, then click the "Add" button, and this new network becomes a configured network available from your dropdown list. Always remember these two gotchas:

1. When you reach the "Scan results" window, to get the proper scan results, you must click on the "Scan" button on the "Scan results window.
2. The dropdown list and the Scan results window show two different sets. The dropdown list shows every network you've ever configured, whether you're currently near it or not. The Scan results window shows every nearby network, whether you've ever configured it or not.

Install elinks and wgetpaste

Internet browsing and downloading are often required before X is successfully installed. Thus the need to install elinks and wgetpaste:

xbps-install elinks wgetpaste

Be sure to read the output of wgetpaste --help.

Install text irc clients

You might also need to IRC chat online before installing X, so be sure to install one or more text irc clients:

xbps-install weechat irssi bitchx ii

The ii client is interesting because it's more about Unix principles and less about hotkeys or special commands.

Understand runit and how Void uses it.

The init system used by Void Linux is runit. So, with maximum oversimplification, it could be said to be the equivalent of Sysvinit, systemd, Upstart, OpenRC, Epoch, s6, nosh, perp, etc. Adding just a little differentiation, the preceding group could be divided into those simple enough to install from source, and those only installable via the package manager, at least by a mere mortal. With this distinction, runit is easily and simply installable from source, along with Epoch, s6, nosh and perp. Sysvinit, systemd, Upstart and OpenRC are best installed with package management. Of those, Sysvinit and Upstart have such big and convoluted "init scripts" that a mere mortal might have trouble making or modifying such an init script.

As a further distinction, systemd and Upstart do a lot more than the traditional role of init programs. Systemd does an order of magnitude more. If you're interested in Void Linux, you probably don't think that's a good thing.

Another distinction is that runit, s6, nosh and perp are influenced by Daniel J. Bernstein's daemontools process supervisor software. These programs supervise daemons by putting the daemon in the background themselves. The daemon itself should not put itself in the background when using these programs. This system gives these programs a lot more control over the daemons they supervise, and moves a lot of the LSB style init script complexity into the init system itself, making life simpler for the admin. Another benefit of this system is that writing a daemon becomes as simple as writing a foreground program: If it's run on a terminal, it does its thing and its stdout and stderr show up on the terminal. If it's run by the init system, it does its thing and its stdout and stderr show up in log files.

Anatomy of an init system

This subsection describes a theoretically simple init system. Neither runit nor any of the others listed in this section are this simple. To see how to make a working init system with this simple architecture, click here (long read). For the short version, see the following diagram:

In the preceding diagram, PID1 serves as Linux' process #1, the ultimate ancestor of all other processes. Its duties are to run the Process Supervisor, and then keep running, handling any signals that come its way. The Process Supervisor runs all processes meant to be run during boot. Some examples might be sshd, ntpd, wpa_supplicant, chrond, udevd, and of course the virtual terminals tty1 through tty6. If booting directly to GUI, it would also run the window manager.

When the Process Supervisor from a daemontools-inspired init like runit runs a program, it supervises it, to the extent that if the program terminates, the supervisor knows that and reruns it. The Process Supervisor is also capable of starting and stopping the program, or sending it signals.

All of this must be seen in the broader context of the boot itself. The following diagram is an extremely simpified portrayal of the boot process on a Linux system:

Void/runit Specifics

In Void Linux, daemons run by the boot process are started by runit. Runit daemon configurations are defined by directories immediately under /etc/sv. The following is an ls output of my /etc/sv directory:

[slitt@littlap sv]$ ls /etc/sv
acpid           cupsd                   
agetty-console  dbus                
agetty-generic  dhcpcd              
agetty-serial   dhcpcd-eth0         
agetty-tty1     dmeventd                
agetty-tty2     docker            
agetty-tty3     dovecot             
agetty-tty4     ip6tables
agetty-tty5     iptables 
agetty-tty6     lxdm
agetty-ttyAMA0  sshd     
agetty-ttyS0    sulogin
agetty-ttyUSB0  udevd
alsa            uuidd
cgmanager       wpa_supplicant
consolekit      znc            
cups-browsed    
[slitt@littlap sv]$

Each of the entries in the preceding directory is subdirectory, and each represents a daemon that can be run. Some are run, some are not. More on that later. The following shows the contents of the cupsd subdirectory:

[slitt@littlap cupsd]$ ls
run  supervise
[slitt@littlap cupsd]$

supervise is a directory managed by runit, and you can ignore it as long as everything works properly. Only during troubleshooting do you need to pay attention to it.

run is a shellscript that runs the daemon. The following shows the code for my /etc/sv/cupsd/run:

#!/bin/sh
exec cupsd -f

That's a run script I made myself, so it's simple and might not work in corner cases. The first line defines the shell, and the second line runs cupsd, in the foreground (that's the meaning of cupsd's -f option), and runs it in the same PID as the run script. Once the daemon is enabled (described later), runit completely manages the daemon.

Now for a little more complicated run script, dbus:

#!/bin/sh
[ ! -d /run/dbus ] && install -m755 -g 22 -o 22 -d /run/dbus
exec dbus-daemon --system --nofork --nopidfile

On line 2, the preceding looks for /run/dbus/, and if that file doesn't exist, it's created with owner and group dbus, and permissions 755.

On line 3, it runs dbus-daemon in its own PID, with the standard configuration file (--system), run exclusively in the foreground (--nofork), and don't write a PID file. Interestingly, dbus isn't enabled to run at boot on my Void laptop, but instead is started if a window manager requiring it is started.

The following is my /etc/sv/udevd/run file:

#!/bin/sh
udevadm control --exit
exec udevd

Pretty self-explanatory. And finally, here is my /etc/sv/wpa_supplicant run script:

#!/bin/sh
[ -r ./conf ] && . ./conf
: ${WPA_INTERFACE:=wlo1}
exec 2>&1
exec wpa_supplicant \
 -c /etc/wpa_supplicant/wpa_supplicant.conf \
 -i ${WPA_INTERFACE} ${OPTS}

Line 2 executes the ./conf file in the /etc/sv/wpa_supplicant directory if there's it's readable. The ./conf file does nothing but set environment vars $WPA_INTERFACE and $OPTS.

Line 3 is some shell-foo to set $WPA_INTERFACE to wlo1 if running ./conf didn't already set it.

Line 4 makes sure that both stderr and stdout are written to this daemon's log file.

Line 5 runs wpa_supplicant in the current process, with the config file named by the -c option, and the network interface set as $WPA_INTERFACE. It also appends all the options in $OPTS onto the end of the command, and of course $OPTS was defined by ./conf.

That's it. That's pretty much the most complex run script on my system. Most of these scripts are provided by Void Linux when you install a daemon's package, but if they're not, it's very easy to make your own run script. So when you hear systemd enthusiasts remarking how systemd frees them from all these gruesome init scripts, remember they're talking about the first-seen-in-1983 sysvinit system, not the 2004-invented runit system. It's like a 20 year old runner bragging that he beat a 75 year old man: The systemd enthusiasts should stop doing this because it really makes them look bad.

Enabling daemons

As promised, here's how to enable a daemon. Simply make a symlink to the daemon's directory under /etc/sv from a same-named filename in /run/runit/runsvdir/current. For example, here's how to enable wpa_supplicant:

ln -s /etc/sv/wpa_supplicant \ 
  /run/runit/runsvdir/current/wpa_supplicant

If the directory and run script under wpa_supplicant are set up right, wpa_supplicant simply starts running. If not, you can troubleshoot.

Runit Supervision Tools

All runit process supervision is performed with the sv command. Its syntax follows:

sv [-v] [-w sec] command services

Temporarily ignore -v and -w. I'll get back to those in a minute. The real basis of the sv command is:

sv command services

In the preceding, services is simply one or more directory names of directory symlinks in /run/runit/runsvdir/current. If there are more than one, they're space delimited. There's no need to include the initial path, the name of the symlink is sufficent. Here's an example to check the status of sshd and wpa_supplicant:

[root@littlap ~]# sv status sshd wpa_supplicant
run: sshd: (pid 612) 3997s
run: wpa_supplicant: (pid 618) 3997s; run: log: (pid 617) 3997s
[root@littlap ~]#

The "command" can be one of the following:

A lot of those commands are just for LSB compliance, which isn't all that relevant with runit. So, without worrying about LSB, the main commands an admin will be running are up, down, status, hup, and for troubleshooting and in cases of complex process dependencies, check. The rest, if you need them, are explained on the sv man page.

As far as the -v and -w commands, these are used to insert a timeout during which to wait for the command to take effect. -v institutes a 7 second timeout, and -w institutes a timeout equal in seconds to the number following it. Once again, consult the sv man page: It's pretty clear.

Change the screen BPI

This section applies to the subset of readers with bad vision. For that subset, one of the first priorities is to make things bigger so the screen can be read at all. Here's how to do it on Void Linux.

As it comes from the manufacturer, Void has no .Xdefaults or .Xresources files for any user. So make the following .Xdefaults file in your home directory:

Xft.dpi: 120
Xft.autohint: 0
Xft.antialias: 1
Xft.hinting: true
Xft.hintstyle: hintslight
Xft.rgba: rgb
Xft.lcdfilter: lcddefault

At a value of 120, the preceding Xft.dpi gives quite a bit of magnification without "scrunching up" too many screens. However, those with really bad vision might want to jack that number higher, especially on little laptops.

After making the .Xdefaults file, the .Xresources can be a simple symlink:

ln -s .Xdefaults .Xresources

Last but not least, make sure that .Xdefaults is put into effect by the xrdb program, from within the .xinitrc program. The following is an example .xinitrc that starts the LXDE window manager system:

#!/bin/sh
xrdb -load /home/slitt/.Xdefaults
exec /usr/bin/startlxde

This section's instructions are for the use case of booting to the command prompt and then using startx to run the GUI interface. If you boot Void directly to the GUI, you,ll need to do something similar but different. It will almost certainly involve .Xdefaults, .Xresources, and the xrdb program.

Add a normal user directory to the path

If yours is a desktop computer used primarily by you, you might want to install a directory for programs you write, owned by you. You can prepend that directory onto the front of the execution path. Here's how you do it:

1. cd ~
2. mkdir bin
3. echo 'export PATH=$HOME/bin:$PATH' >> .bashrc
4. Log all the way out of the GUI.
5. If the GUI was started by startx, log out of the tty.
6. Log back in again.

Step 3 puts the following at the end of your .bashrc

export PATH=$HOME/bin:$PATH

So every time .bashrc is run, it prepends $HOME/bin to the front of the path, with $HOME being resolved at runtime to your home directory.

Install a dmenu interface

Dmenu runs only in GUI mode, although it would be easy enough to make an nCurses version. Dmenu is the fastest, most productive program-running interface ever designed. Anyway, for the 80% of the time when you know the filename of the program you're trying to run, it's lightning fast. For the other 20%, you can still use your normal menu or mouse interface. Dmenu is a vital productivity tool on any distro, and Void's no exception. Here's how you enable it, starting at a terminal in an X session, assuming your username is myuid:

1. su -
2. xbps-install dmenu
3. exit
4. mkdir ~/bin
5. cd ~/bin
6. echo '#!/bin/sh' > dmenu_mine
7. echo '/usr/bin/dmenu_run -l 24 -fn 10x20' >> dmenu_mine
8. chmod a+x dmenu_mine
9. ~/bin/dmenu_mine

If everything came out right, the preceding command gives you a menu of executable programs, and as you type the first few characters of the desired program, the list narrows. When you've typed enough to uniquely identify the desired program, the highlight falls on the desired program, so just press Enter to run it.

At this point dmenu is installed as an easy to read vertical menu instead of the default teeny-tiny hard to understand horizontal menu. All that remains to unleash its productivity is to tell your window manager or desktop environment to run /home/myuid/bin/dmenu_mine when a certain key combo is pressed. For instance, here's the code to enable Ctrl+Shift+Semicolon run it from LXDE:

<keybind key="C-S-semicolon">
   <action name="Execute">
      <command>/home/myuid/bin/dmenu_mine</command>
   </action>
</keybind>

Insert those five lines within the <keyboard/> section of ~/.config/openbox/lxde-rc.xml. Log out of X and log back in, and your Dmenu menu appears every time you press Ctrl+Shift+Semicolon. Naturally, you can change the hotkey to suit your taste. Use the xev program to discover the official names of various keys.

Back up studiously.

Void Linux is a rolling release distro. This means that there's a greater chance of an upgrade busting your computer, and your computer has no exact version number. Therefore it's crucial to back up not only data, but the OS and the MBR or GPT, on a regular basis.

Enable video, sound, Youtube

As it comes from the factory, Void Linux shows Youtube videos but doesn't play the sound. This is easily fixed. The first step is to make your normal user a member of groups audio nadvidio, by editing /etc/group and putting the normal user at the end. If the preceding sentence isn't clear enough, perform the following command:

man group

At the conclusion of all of this, exit all the way out of X, log out of the virtual terminal (tty1 or whatever), log in again, and run startx again. These steps enable your addition of the groups.

Next, install alsa-tools, alsa-utils, and sox:

xbps-install alsa-tools alsa-utils sox

Run alsamixer in a GUI terminal, and for every output device, make sure all volume controls are on 100% and not muted. Play a Youtube video, with the Youtube volume at full blast, and make sure there's sound. If not, use amixer to investigate further. If you have installed PulseAudio (and I highly recommend against this), you have several more variables to consider. In my experience, PulseAudio is responsible for the most intractable audio failures, so I just don't use it (and therefore have to forgo Skype).

If you uninstall PulseAudio, you'll need to go around to all the players and make sure their output doesn't go to PulseAudio.

For all these reasons, I'm very pleased that Void Linux doesn't install PulseAudio by default.

So let's say you've made the normal user a member of groups audio and audio, installed both alsa-tools and alsa-utils, verified that PulseAudio isn't installed (Void defaults to no PulseAudio), you've removed all mutes and turned up all playback volumes in alsamixer, you've turned up the Youtube volume all the way in Firefox, and you still get no sound. That's when diagnostic testing begins:

speaker-test -t sin -f 800

If it outputs a tone, you know most everything's already correct. You can now go on to see whether play, aplay, mplayer and the like play known good .wav files, and if they don't, what error messages are thrown. Or maybe it's something with your browser's playing of Youtube itself: Consult your browser configuration.

If the previous speaker-test did not produce sound, try adding in the number of channels with the -c 2 option:

speaker-test -t sin -f 800 -c2

If the preceding works, once again test known good .wav files and the like. But if it doesn't, deeper diagnostics are called for...

One frequent cause of no sound, in spite of all outputs at 100%, no mutes, and no PulseAudio, is a missing or wrong configuration of the proper audio card. Typically, even if there's one physical card, a modern computer gives you two cards: One for analog audio, and one for HDMI. If you're trying to hit the wrong one, you'll obviously get no sound.

Start with the aplay -l command:

[slitt@littlap ~]$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Generic [HD-Audio Generic], 
     device 0: 92HD91BXX Analog [92HD91BXX Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
[slitt@littlap ~]$

The preceding shows the cards by number, complete with each card's name (in square brackets) and device number. In the preceding, if I'm trying to enable analog sound, I need to be dealing with card 1 (and device 0). But that's not quite enough info: The PCM name is required. The aplay -L command delivers that:

[slitt@littlap ~]$ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
hdmi:CARD=HDMI,DEV=0
    HDA ATI HDMI, HDMI 0
    HDMI Audio Output
sysdefault:CARD=Generic
    HD-Audio Generic, 92HD91BXX Analog
    Default Audio Device
front:CARD=Generic,DEV=0
    HD-Audio Generic, 92HD91BXX Analog
    Front speakers
surround21:CARD=Generic,DEV=0
    HD-Audio Generic, 92HD91BXX Analog
    2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=Generic,DEV=0
    HD-Audio Generic, 92HD91BXX Analog
    4.0 Surround output to Front and Rear speakers
surround41:CARD=Generic,DEV=0
    HD-Audio Generic, 92HD91BXX Analog
    4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=Generic,DEV=0
    HD-Audio Generic, 92HD91BXX Analog
    5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=Generic,DEV=0
    HD-Audio Generic, 92HD91BXX Analog
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=Generic,DEV=0
    HD-Audio Generic, 92HD91BXX Analog
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
[slitt@littlap ~]$ 

The aplay -L and aplay -l commands have given you the card number and device number of the analog sound circuitry, as well as a list of the potential PCM streams supplied by both the analog and HDMI cards (and any other cards that may be there).

On a laptop, the most likely PCM stream is the one called "front". To try that PCM, perform the following command, which adds the -D option to specify the device:

speaker-test -t sin -f 800 -Dfront:Generic -c2

In the preceding command, the device is specfied by a PCM name from -aplay -L, followed by a colon, followed by what comes after the "CARD=" on the same line as the PCM name. In other words, "front:Generic".

If the preceding works, that's good news: The sound system is functional. If the preceding doesn't work, try the other PCM name:CARD combos for PCMs with the same card name as the analog card. If one works, it gives you a good idea. From there, it's time to create a .asoundrc file in the user's home directory, with the hope of making the default card/device be the one with your analog speakers. Mine looks like the following:

pcm.!default {
  type plug
  slave {
    pcm "hw:1,0"
  }
}
ctl.!default {
  type hw
  card 1
}

After installing the preceding .asoundrc, one of the following commands should produce a tone, assuming you have a known good .wav file called knowngood.wav:

play knowngood.wav

aplay knowngood.wav

mplayer knowngood.wav

The play program is an excellent choice for a number of reasons. First, it shows you a little text meter showing what it's playing, so you know whether you're playing something very soft. Second, it allows you to boost it beyond distortion. Doing so is bad for music listening, but can be helpful in troubleshooting if sounds are soft. To boost the volume, do something like this:

play knowngood.wav gain 6

The preceding amplifies the electrical signal by 6db. Sure, it distorts to a degree, but if you're wondering whether the signal is simply too soft to hear, this helps settle that question. And if the play program's meters mostly "peg" by displaying exclamation points, you can be pretty sure you're feeding in sufficient signal.

If you still can't play .wav files after all of this, perhaps it's a driver problem, which is beyond the scope of this document and also occurs with all distros. Use the lshw program, and compare its declared drivers with the output of lsmod, and if you notice discrepancies, use modprobe to load the proper drivers, or you might even need to install the drivers. The lshw program tells you all about your sound cards.

Fix audio card monopolization

As Void ships from the factory, using the ~/.asoundrc developed in the preceding section, on some sound cards, the first sound program to play sounds monopolizes the sound card, so that other sound programs can't make sound. This wouldn't be so bad, except that programs keep on monopolizing the sound card even if they're paused. Often you need to close the program, and then reset the other program by replaying or rewinding or whatever. Worse yet, I know of no command to even find out which program is monopolizing the sound card.

Many sound producing programs, including web browsers, are stateful, and depend on past states. This makes troubleshooting difficult, makes it hard to find root causes, and makes the whole discovery process very susceptible to superstition and raindances. Right off the bat, you need to find ways to decrease the statefulness.

It turns out that the speaker-test program is your friend. Every time you change your ~/.asoundrc file, you can kill all instances of speaker-test, rerun them again, and be guaranteed that they'll be running off the newly saved .asoundrc. So diagnose and fix the audio card monopolization problem with speaker-test, not with any music player program or web based audio.

Recognizing the problem

Your first hint of this problem is that intermittently audio doesn't work, and it seems like it doesn't work if more than one audio sources are open, whether or not they're currently playing. If this seems to be happening, it's time to investigate. The first step is to close all programs that can operate the speakers. All of them. Every single one. If there's some question, reboot. It's better to take five minutes rebooting than go on an hour long wild goose chase (in my books and courseware, this wild goose chase is called "The Big Mistake" or "letting the root cause out of the box"). Once all sound producing programs are closed, perform the following command:

speaker-test

What the speaker-test command should do is send audible white noise (actually pink noise) to your speakers. If this command delivers an error message that includes the text "Device or resource busy", not only do you have the card monopolization problem, but you also haven't closed all your sound programs. Reboot and try again.

If the speaker-test errors out with text including "Playback open error: -2,No such file or directory", you probably have the wrong card specified in .asoundrc. For instance, you might need to change pcm "hw:0,0" to pcm "hw:1,0". For details on how to discover card numbers and the like, see the Enable video, sound, Youtube section earlier in this document. Once the speaker-test command

If it delivers no error messages but also doesn't play sound, turn your volume up all the way in hardware (if possible), turn it up all the way in software (alsamixer), search for and undo any mutes, and try again.

Once speaker-test delivers pink noise to the speakers, you're ready to test for card monopolization. With the pink noise still playing, in another terminal run the following command:

speaker-test -t sine -f 2000

The preceding command should sound a high pitched tone thorough your speakers, easily distinquished from the pink noise. If the preceding command issues an error message including the text "Device or resource busy", that indicates you have the card monopolization problem. Only when you can simultaneously hear both pink noise and the high pitched tone through your speakers is your card monopolization problem fixed.

The exact tests, experiments and moves to fix this problem are discussed later in this section. But first, a word about what you're going to find when you search the net...

When you search the net

If you search the net trying to find how to play multiple sources on one card in ALSA, you'll be greeted by several doctorate thesis level treatises on Linux sound, and guys who say "Use Pulse or dmix or mpd." This is a little like asking how to hang drywall, and reading "Use drywall nails or drywall screws." Actually it's worse, because it's much easier to find info on drywall nails and screws than it is to find info on dmix and mpd.

If you're using Void Linux, chances are you don't want the complexity of PulseAudio, just to make your sound work reasonably. So let's forget that. Mpd, which stands for "Music Player Daemon", is a music player operating as a daemon. It handles playlists and files and songs, etc, and you control it with a client (mpc). Nice product, and it very well might solve the card monopolization problem (I haven't tried), but you might not want to introduce all that overhead just to make your card available to youtube videos, and probably not even both at the same time. That leaves dmix.

You research dmix. What is it? Where do you get it? Which package is it in? What's the name of the dmix executable? How do you use dmix? And most of what the Internet tells you is "asound" snippets of various complexities, with no explanation. Well, this time you came to the right place...

So here's the lowdown on dmix. Dmix is a feature of ALSA: If you've installed ALSA, you have dmix. It might be in the alsa-lib package, or it might be in the alsa-plugins package, or alsa-tools, or alsa-utils, but by the time you have alsa and aplayer and alsamixer up and running, you have dmix. There's no dmix executable: It's a part of ALSA. Once you have ALSA installed, you can enable dmix with certain entries into $HOME/.asoundrc.

Fixing the monopolization

Here's a high level description of the monopolization remediation process:

1. Make sure your sound works in the first place.
2. Back up existing ~/.asoundrc
3. Modify ~/.asoundrc to work with dmix
4. Test
5. If necessary, perform the raindance of installing then uninstalling PulseAudio

Make sure your sound works in the first place.

All this is a moot point if your audio doesn't work at all. Perform the following command

speaker-test

If the preceding command doesn't make pink noise come out of the speakers, troubleshoot. If no joy, reboot and try again. Go back and go though the steps in the preceding section. Work with it until you get pink noise.

Back up existing ~/.asoundrc

You'll need it both to regroup if you make things worse, and you'll need it as a reference for your new ~/.asoundrc.

Modify ~/.asoundrc to work with dmix

In the preceding section, you created a ~/.asoundrc like the following, which should play pink noise just fine if no other audio programs are running:

pcm.!default {
  type plug
  slave {
    pcm "hw:1,0"
  }
}
ctl.!default {
  type hw
  card 1
}

Of course, your file might be slightly different due to different device numbers and card numbers and device names, etc. If your ~/.asoundrc looks like the preceding, then change it to look like the following:

pcm.!default {
	type plug
	slave.pcm "dmixer"
}

pcm.dmixer  {
 	type dmix
 	ipc_key 1024
 	slave {
		pcm "hw:1,0"
		period_time 0
		period_size 1024
		buffer_size 4096
		rate 44100
	}
	bindings {
		0 0
		1 1
	}
}

ctl.dmixer {
	type hw
	card 1
}

A few observations about the preceding:

• The new ctl.dmixer has identical data to the old ctl.!default
• The new pcm.dmixer slave's pcm entry is exactly like the old pcm.!default slave's pcm entry.
• pcm.dmixer bindings values are verbatim and don't depend on the old ~/.asoundrc. Bindings relate audio channels to audio card channels, and the configuration in the preceding ~/.asoundrc should work for any 2 speaker stereo system. They're not necessary, so if you want to rule them out as a root cause, just remove the word bindings and everything between the curly brace set that follows it. However, my understanding is that these bindings increase the performance of your audio, so be sure to replace the bindings once everything's working properly.
• All the other info in the preceding ~/.asoundrc are reasonable values and probably wouldn't cause a malfunction. You can tweak them when everything works, and you've become an ALSA expert.

Test

Make absolutely sure no programs are running that access audio in any way. If in doubt, reboot. Then run the following two commands, in the order shown:

speaker-test

speaker-test -t sine -f 2000

The first command sends pink noise to your speakers, the second sends a 2000 hz tone. Most people can distinquish between the two and know that both are playing. If you hear both, you've fixed the problem.

If necessary, perform the raindance of installing then uninstalling PulseAudio

It's regrettable this step is even in this document, but I had personal experiences in which I had to install PulseAudio to get simultaneous playback from two sources. Later, when I uninstalled PulseAudio, I still got simultaneous playback. There are three possible reasons for this occurrance:

1. The sound system is so stateful that, even though PulseAudio was never necessary, the restarting done while installing it caused the new ~/.asoundrc to finally be recognized.
2. The PulseAudio package does something, perhaps make a directory or lay down a file, that enables ALSA to work even after PulseAudio has been uninstalled.
3. I made a mistake.

Anyway, if the previous steps haven't enabled simultaneous speaker-test playback, install the PulseAudio package and the Pavucontrol package, try again, reboot if necessary, and once you can get simultaneous playback, uninstall PulseAudio and Pavucontrol. Whatever you do, don't do a lot of PulseAudio configuration, and don't start the PulseAudio daemon. PulseAudio is a complex program that can really gum things up if you push it.

Wrapup

The content of this section of this document is almost certain to transition you from a system that plays sound, but only for one source at a time, to a system that can play several sources at once. If not, you're in for some research and troubleshooting.

Get Xombrero Working Right

The Xombrero browser isn't a must. Firefox works much better on Void Linux than it does on other distros. Chromium works pretty well too. The simplistic and lightweight Xombrero is no substitute for Firefox.

Nevertheless, the person appreciating Void's simplicity and robustness, and perhaps the quick keyboard-centrism of dmenu, is likely to love Xombrero. The Xombrero expert does most browsing without ever needing to reach for a mouse. If this sounds attractive to you, read on...

Installation

Void's xombrero package is outstanding. Install it like this:

xpbs-install xombrero

Documentation

The best sources of documentation for Xombrero are your Void installed /etc/skel/.xombrero.conf file, the Xombrero man page, and the Xombrero Wiki.

Bookmarks

Xombrero bookmarks (favorites) are ridiculous. You can't bookmark a local file. You can't make categories of bookmarks. You can't create a bookmark hierarchy.

So what you do in Xombrero is maintain an HTML file with a hierarchy of your bookmarks, and create a Xombrero quickmark to pull up that HTML file, by editing ~/.xombrero/quickmarks. My current ~/.xombrero/quickmarks follows:

o file:///s/websites/littlinks/index.html
v file:///d/websites/tjunct/linux/void/voidtips.htm
s file:///d/websites/tjunct/projects/stylz/

The key sequence to invoke a quickmark is go, so to go to my list of links, it's the fast-typed goo. Quickmarks are also good for temporary links, so gov takes me to the hard disk version of this web page, and gos takes me to my on-disk Stylz directory.

Isn't this too much work?

I just suggested that you create and maintain your own bookmark page, complete with links. Isn't that way too much work just to use a particular browser?

Yes it is. If the only benefit of doing so were to use Xombrero, I wouldn't use Xombrero. But the fact is, I was maintaining my own HTML coded bookmark list long before hearing of Xombrero. My extensive hierarchy of bookmarks is much too valuable to trust to a browser. Before maintaining my own, I often lost my bookmarks in an upgrade after I blew away my old home directory, or when my browser changed its bookmark API, or when, to save disk space in my directory, I blew off one of those silly xul files, temporarily when I ran too many instances of the browser. And there's the Big Kahuna of reasons for a personal bookmark hierarchy unaffiliated with a browser: I get the exact same bookmark hierarchy on all my browsers, and even on other browsers on the same LAN as my desktop computer.

I maintain my bookmarks with a program that parses a special tab-indented outline (maintained with VimOutliner) into a link hierarchy in which the leaf nodes are links pointing to offpage pages, and the branch nodes are on-page links. This means you can find a link either by descending the hierarchy, or by searching. Your mileage may vary: You might maintain your link hierarchy manually. It would be pretty easy using Bluefish.

Configuring Xombrero

As it ships from the factory, the Void Linux Xombrero package gives you the ~/.xombrero tree, and does not give you the ~/.xombrero.conf file. The first thing you should do is guarantee the existence of ~/.xombrero.conf with the following command:

touch ~/.xombrero.conf

The existence of ~/.xombrero/ and gives you the means to configure Xombrero as you want.

Of course, some people will shout at you never to change these files directly, only to use Xombrero's user interface to change its configuration. OK fine, for sure for sure. Try not to laugh as you remember you came to Void so you could use Vim or Emacs or nano or whatever as your configuration tool. Try not to laugh as you contemplate there are already too many NetworkManagers, KDEs and systemds in this world, with no user-servicable parts inside, you must use their interface.

Because there's a possibility (although I've never run across an actual occurrence) that Xombrero could overwrite your modification of a file, make sure to do the modifications when no Xombrero instances are running. Or you can do what I do: Modify the files when Xombrero is running, and half the time the already-running Xombrero recognizes my changes instantly.

This section has discussed Xombrero config in the abstract. Now for some specifics.

Change your home page

Straight from the factory, Xombrero's home page is Void's home page. If you want it to be something else (your bookmark list, for instance, you change it by adding the following line to ~/.xombrero.conf:

home file:///s/websites/littlinks/index.html

Of course, in your specific case you'd change the file URL to point to your bookmark hierarchy. Save the file, and every time you open a new Xombrero instance, it starts at your bookmark hierarchy.

A few handy default hotkeys

Key	Functionality
F5	Reload web page
F6	Focus on URL input field
F7	Focus on the web search input field
Backspace	Previous page
Shift+ Backspace	Forward to next page
f	Number all links visible on window. Then enter a number to go to that link. Press the enter key to complete the process.
/	search
?	search backward
n	search again, forward
N	search again, backward
gox	Load URI for Quickmark x
gg	Go to top
gG	Go to bottom
Space	Go down one page
Ctrl+d	Down half page
PgUp	Up one page
Ctrl+u	Up half page
j	Down one line
k	Up one line
l	Scroll right
h	Scroll left

Summary

Xombrero is a simple browser that can be driven almost entirely via keyboard, by a person who knows Xombrero's hotkeys. Xombrero is configurable, via editor, in the ~/.xombraro.conf file and the ~/.xombrero/ directory tree. The best sources of documentation for Xombrero are your Void installed /etc/skel/.xombrero.conf file, the Xombrero man page, and the Xombrero Wiki.

Set Your Default Browser

We all have our own ideas about what browser should come up when we click a link in a non-browser application. The following two commands set your default browser to xombrero.

xdg-mime default xombrero.desktop x-scheme-handler/http
xdg-mime default xombrero.desktop x-scheme-handler/https

In the preceding, if the commands gripe about not being able to write a file because of non-existent directories, just create the directories.

In the preceding, if you wanted to change your default browser to firefox, all that would change is you'd use firefox.desktop instead of xombrero.desktop.

Fix Gstreamer Problem in Clementine

After installing Clementine, if playing an Internet radio station errors out with a Gstreamer complaint about the proper sound plugins not being installed. The way I solved it was to install the following group of packages:

• cmus
• cmus-faad
• cmus-ffmpeg
• cmus-flac
• cmus-libao
• cmus-modplug
• cmus-mpc
• cmus-opus
• cmus-wavpack

xbps-install cmus cmus-faad cmus-ffmpeg \
 cmus-flac cmus-libao cmus-modplug \
cmus-mpc cmus-opus cmus-wavpack

Fix Keyboard Doesn't Work in X

It happened to me, who knows, it might happen to you.

Intermittently (but often) I'd boot to CLI, run startx, and once in X, the keyboard would not be recognized. Keystrokes would not be acknowledged. The Caps Lock light wouldn't light on pressing Caps Lock. The keyboard was dead in X.

It's intermittent, so I can't say for sure it's been fixed, but here's what I think happened. X wasn't acting right with PS/2 keyboards. I couldn't get it to happen with a USB keyboard unless a PS/2 keyboard was already plugged in. If my suspicions are correct, if all the PS/2 jacks on the computer are unpopulated and USB keyboards and mice are used, this symptom will never happen. If there is a PS/2 keyboard plugged in and the USB keyboard exhibits the symptom, unplugging and replugging the USB keyboard makes the USB keyboard operational. Unplugging and replugging the PS/2 keyboard doesn't make the PS/2 keyboard operational. If the PS/2 keyboard doesn't work in X, and there's a need for a keyboard long enough to exit X and perhaps reboot, any old USB keyboard can be plugged in temporarily to achieve the exit and perhaps reboot.

In most cases, my best solution advice for this symptom would be to unplug all PS/2 devices and replace them with USB devices. However, in my case, all my keyboards with decent action are Compaq PS/2 keyboards. These are keyboards that would require at least $50 each to replace, and with so few retail stores in Orlando, they'd need to be bought mail order. How would I test the touch on a mail order keyboard before buying? I wouldn't be able to. There was a real need for me to keep using PS/2 keyboards. So I plugged the keyboard into the keyboard PS/2 jack of those USB to PS/2 Y connectors, and plugged the Y's USB into my computer. Now the PS/2 keyboard rarely displays the symptom, and when it does, I can unplug and replug the USB part of the Y, thereby restoring keyboard functionality in X.

Not all adapters work. I have a single (not Y) USB to PS/2 adapter that always fails in X. Without an excellent reason to keep using PS/2 keyboards.

Here are some tips I've found tend to reduce the frequency of the "Keyboard loses function in X" symptoms:

• Never reboot or halt from X. Always exit X and close out all programs before rebooting or halting.
• Immediately after running startx, make your very first keyboard activity Ctrl+Alt+F2. Then Ctrl+Alt+F7 to go back to X, and use your keyboard as normal.

The symptom described in this section is intermittent. I don't yet have enough data to even begin to assign a root cause to it, or a method of preventing it. This section simply gives some workarounds and raindances that appear to lessen its frequency.

Compile Bluefish for zencoding.

For those of us regularly authoring HTML documents, zencoding is essential to productivity. The Bluefish editor is famous for its great implementation of zencoding. In mid-September, 2015, the Bluefish installed by the xbps package manager didn't have Zencoding, because it wasn't compiled with Python enabled. A week later, Bluefish installed by xbps had Zencoding and Python enabled. This section is included just in case the default Bluefish ever reverts to no Zencoding.

There are ways to work with xbps so that your Bluefish compiles with zencoding built in, but nobody has been able to explain these, to me, in a manner that someone unfamiliar with xbps can follow. Therefore, I just compile my own, outside the package manager. But even that's a challenge.

Installing Python is no guarantee that Bluefish will compile with python enabled. Nor is using the --enable-python option for Bluefish' ./configure command.

After compiling, from the Bluefish menu choose Help->Build Info, bringing up a dialog box with how the executable was built. If it says "Python: No", you haven't achieved Zencoding and must try something different. I can't identify that something.

To make things easier, the following is the dialog box created by Help->Build Info dialog box for Bluefish created by xbps-install in late September, 2015. Theoretically, if you can get your compiled version to look like this, you'll have Zencoding.

Enable Dovecot

Void makes Dovecot easier because it installs all the right stuff, latest version, and it creates your Runit directory and run script for you. Nevertheless, Dovecot is a heavy duty program that requires some thought to set up. The instructions in this section are for a simple Dovecot without plugins. Plugins can come later, and are beyond the scope of this document.

Before you install Dovecot, it's easier if your machine already has a fixed IP address. Once it does, install it with xbps as usual:

xbps-install dovecot

The preceding command installs the executables, the numerous config files, and the Runit directory with run script. It might run (insecurely) as installed: Try hitting it with an IMAP aware email client.

Once you have a permanent static IP address for the computer, you need to recreate Dovecot self-signed certificates. Here are the three commands you run in order to do so:

1. rm -f /etc/ssl/{certs,private}/dovecot.pem
2. edit /etc/ssl/dovecot-openssl.cnf
3. /usr/bin/dovecot-mkcert.sh

Editing /etc/ssl/dovecot-openssl.cnf consists of Filling in your country, state, city, organization (I used Troubleshooters.Com), organizational unit name (I used IT), and last but not least, make sure that you put the computer's permanent static IP address, or a URL resolving to that IP, right after the CN=.

A complete treatise on how to configure Dovecot is well beyond the scope of this doc, but pay particular attention to the output of dovecot -n. This command lists all config items that are different from the compiled in default. If you have another Dovecot server that does what you want it to, compare its dovecot -n to the one on your Void machine, and edit /etc/dovecot/dovecot.conf and the files under /etc/dovecot/conf.d/ in order to get them identical.

I suggest that you enable only imap, and only SSL enabled IMAP. Unless you have a big reason to do otherwise, I suggest that your passdb driver be pam and your userdb driver be passwd. That way you can log in with the same password you use to log into the machine.

The following are some pertinent output from my dovecot -n:

passdb {
  driver = pam
}
protocols = imap
service imap-login {
  inet_listener imap {
    port = 0
  }
  inet_listener imaps {
    port = 993
    ssl = yes
  }
}
ssl = required
userdb {
  driver = passwd
}

When testing your new Dovecot, hit it from an IMAP aware email client. Do not put the password in the client: Safer to type it in at each session. Make sure to tell your client to access incoming mail with SSL exclusively, and test to make sure that there's no way you can access your incoming mail without typing your password.

Install Udftools

Void Linux has no udftools package, meaning you have no mkudffs command, making it extremely difficult to burn Blu-ray backups. It even disallows one simple way to burn DVDs with files bigger than 2GB. Luckily, you can hand compile udftools.

But it's not easy. As is typical of so much software, udftools is erroneously documented throughout the Internet, and almost a decade behind in the project's maintenance, requiring a patch. These instructions hopefully give you one-stop-shopping for instructions to install udftools on Void. The following instructions were tech edited and worked perfectly on an up-to-date 64 bit Void box on 12/15/2015:

1. Make sure that readline-devel ncurses-devel are installed.
2. Pick a directory to host the build. I chose $HOME/junk, which serves as the example for this set of instructions.
3. cd $HOME/junk
4. mkdir udftools
5. cd udftools
6. Download the tarball at http://sourceforge.net/projects/linux-udf/?source=directory. The tarball, as downloaded, should be called udftools-1.0.0b3.tar.gz.
7. Copy the tarball to $HOME/junk/udftools
8. tar xzvf udftools-1.0.0b3.tar.gz
9. less udftools-1.0.0b3/AUTHORS
10. If the AUTHORS file looks a lot different from the following, you got the wrong tarball:

    libudffs
     Ben Fennema <bfennema@falcon.csc.calpoly.edu>
    
    mkudffs
     Ben Fennema <bfennema@falcon.csc.calpoly.edu>
    
    cdrwtool
     Jens Axboe <axboe@suse.de>
     Ben Fennema <bfennema@falcon.csc.calpoly.edu>
    
    pktsetup
     Jens Axboe <axboe@suse.de>
    
    doc
     Paul Thompson <set@pobox.com>
     Ben Fennema <bfennema@falcon.csc.calpoly.edu>
    
    

11. wget http://www.linuxfromscratch.org/
    patches/downloads/udftools/
    udftools-1.0.0b3-fixes-1.patch
    • The preceding command should be one line. I had to wrap it for the website.
    • If the wget command ceases to work, search for it.
    • If all else fails, download this unofficial version.
12. patch -p0 < udftools-1.0.0b3-fixes-1.patch
13. cd udftools-1.0.0b3
14. ./configure
15. make
16. su -c "make install"

On my up-to-date 64 bit Void machine on 12/15/2015, the preceding procedure successfully installed the udftools package. If, for some reason you don't like the results, my research shows me that the following files were installed by the su -c "make install" command:

• /usr/local/bin/cdrwtool
• /usr/local/bin/mkudffs
• /usr/local/bin/pktsetup
• /usr/local/bin/udffsck
• /usr/local/bin/wrudf
• /usr/local/lib/libudffs.a
• /usr/local/lib/libudffs.la
• /usr/local/man/man1/cdrwtool.1
• /usr/local/man/man8/mkudffs.8
• /usr/local/man/man8/pktsetup.8

After I learn more about Void Linux packaging, I hope to create and maintain a Void package for udftools. But until then, at least you have this procedure to work with.

Installing Perl DateTime.pm on Void

So you move a program over to Void, run it, and your program fails, telling you it can't find DateTime.pm on Perl's module path. No problem, you use xlocate and xpbs-query to find Void's Perl DateTime package, and are surprised that it doesn't exist. OK, so you'll use CPAN. But the cpan program fails to install DateTime, and besides, CPAN's dangerous: I once broke Vim trying to use CPAN to install something.

The right way to fix this problem is to create your own Perl DateTime package, and presumably give it to the Void project, using this document. If you're anything like me, your todo list allotted 10 minutes to transfer this program, not the week it would take to become a proficient Void packager using this document. If you're anything like me, you made a mental note to learn Void Packaging over the next few months, and searched for another solution, hoping it wouldn't require a VM or a container.

Here's what I did...

The preceding said, I feel just fine about the way I did it. What I did was to run Lubuntu 14.04 LTS running in a VM, with a mount so I could run my program from the Lubuntu VM, and installed the necessary perl modules, which mainly turned out to be libdatetime-perl. Then I started copying. From Lubuntu's /usr/lib/perl5 I copied DateTime.pm, DateTimePP.pm, and DateTimePPExtra.pm into Void's /usr/lib/perl5/site_perl directory. Then, on Void, I created directory /usr/lib/perl5/site_perl/DateTime, and selectively copied files from Lubuntu's /usr/lib/perl5/DateTime directory into Void's /usr/lib/perl5/site_perl/DateTime until my app worked.

If I had it to do over again, I'd have tarballed everything in Lubutu's /usr/lib/perl5/DateTime and extracted it into Void's /usr/lib/perl5/site_perl/DateTime directory. After all, there was no /usr/lib/perl5/site_perl/DateTime to begin with, so I wouldn't have overwritten anything.

So that's it. If you have the time to learn Void packaging, do it the right way. But if you haven't the time, I found a way that works for me.

Adding an Official (Sub) Repository to the Package Manager

There are currently four official subrepositories within your official Void repository:

• void-repo-debug
• void-repo-multilib
• void-repo-multilib-nonfree
• void-repo-nonfree

If you need to add one of these official Void subrepositories to your Void package manager (XBPS), you'll find lots of contradictory and typically ambiguous methods all over the web. Which means that until now, you've needed to ask someone who knows the raindance and magic incantation. This section was written to give you the best and easiest way to add a repo. In this section we'll use an example in which you need to add the multilib and multilib-nonfree repositories. These are the two repositories you need to add in order to install Skype.

As of 4/20/2016, the correct way to perform this task is contained in the following page and section:

https://wiki.voidlinux.eu/XBPS#Subrepositories

The process defined there, and be sure you follow it exactly, is the following:

1. xbps-query -Rs void-repo in order to find out the exact repository name(s).
2. xbps-install <repository_name>, where <repository_name> is one of those revealed in the preceding step. Install all necessary, which in our example are void-repo-multilib-nonfree and
void-repo-multilib.
3. xbps-install -S to sync those two new repositories. Personally, i do xbps-install -Su so as to also update all my software from all my repositories at once.
4. xbps-query -L in order to verify that the repository(s) was/were really added.
5. xbps-install skype-32bit (for example) to install software from those repositories, which are now a part of your package manager.

Contribute to Void

One reason Void Linux is so clean and common-sense is that it's not corporate. Their one and only priority is making a clean, user accessible OS. With a very small team, Void continues to maintain over 6000 packages. The people running Void aren't trust fund babies: They're real people who need money to live. If you believe Void is the best OS, and Void helps you in your life and your business, ensure Void's continuing existence by paying them. It doesn't have to be much, but if you use Void Linux every day, pay them something. You're helping ensure that Void will neither go out of business nor be bought out by a corporation more interested in capturing market than making a clean OS.

To contribute to Void Linux, go to http://www.voidlinux.eu/donations/.

Summary

Void Linux is small, simple, modular, and easily understood. By default it installs very little, is lightweight, and works very well on anemic computers, as well as well endowed computers. But Void is scantly and contradictorally documented throughout the Internet.

No problem. This document gives you the tools to get an MBR loaded, one partition, ext4 Void system fully functional. Other configurations aren't all that much more difficult. Other people should write their own, completely tech-edited documentation, and keep it up to date. This way Void Linux can assume its true role as the leading KISS, modular Linux.

---

[ Training | Troubleshooters.Com | Email Steve Litt ]