Salix 14.2 Xfce — 3

Satisfied with my preliminary testing in a virtual machine (VM), I moved forward with installing Salix 14.2 Xfce on my Thinkpad T400 laptop. I have Slackware 14.1 32-bit, Ubuntu MATE 16.04 64-bit, and CentOS 7 installed on the laptop. I manually created a 20 GB partition for Salix.

My first toe stubbing came when the installer asked whether I wanted to install to sda or sdb. I have only one hard disk in the laptop. I had copied the ISO to a USB flash drive. This was loosely similar to a recent CentOS 7 experience. I exited the installer, ran fdisk -l and verified the hard drive is indeed sda.

Untested in my VM sessions was partition mapping. With virtual machines I only create a system and swap partition. On my production systems I use a common /home and /usr/local for all installed distros. The stock Slackware installer handles this mapping just fine. I soon discovered the Salix installer did too.

I have a 10 GB Windows XP partition on the laptop hard drive. I keep the partition as a demonstration of using raw disk access (disk pass-through) in VirtualBox. Like Slackware, the Salix installer asked whether I wanted to make the partition visible in my Salix fstab.

For the VM testing I paid no attention to the supported installation types. Salix supports a full, basic, and core install. As I was still in testing mode, I chose the full install.

Like the VM, installing the packages was fast, taking about five minutes. I created a user account. Rather than use an existing account I decided for this first run to use a new account.

As the laptop is multi-boot, I did not install the LILO boot loader. I rebooted and manually added a selection for Salix. There I ran into a problem. Apparently the Salix installer changed the UUID of the swap partition. This behavior is inherited from Slackware.

I could have updated the fstabs on all existing systems or restore the old UUID and then edit the Salix fstab. I chose the latter option.

mkswap /dev/sdX -U xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

A more appropriate approach is to grab the UUID before formatting an existing swap partition and restoring the UUID.

After updating the Salix fstab I realized the Salix installer never asked for a host name during the installation. Salix provides a tool to change the host name. That this is not configured during the installation is a bit goofy. This behavior is inherited from Slackware. Hence the (in)famous darkstar host name.

I changed the hostname. I rebooted into Salix using run level 1 (init 1). This causes the hostname to default to darkstar, as seen in the login prompt. The cause of this quirk is the hostname snippet found in /etc/rc.d/rc.M is not included in /etc/rc.d/rc.K. This quirk is inherited from the stock Slackware. Years ago I copied that rc.M snippet to the rc.K script on all of my Slackware systems.

When rebooting Salix to run level 3 (init 3), I noticed an odd message at the beginning of the boot:

Ext4-fs (sda9): couldn't mount as ext3 due to feature incompatibility

I had noticed the same message in my VM but paid no attention. Often oddball messages appear when running inside a VM because of the virtual hardware emulations. This particular message is related to ext3 support being dropped in the 4.4 kernels. Searching the web revealed the problem could be stopped by adding the boot parameter rootfstype=ext4. I rebooted and this parameter did indeed stop the irritating but harmless message.

I had a suspicion about another remedy. I installed the generic kernel and created an initrd. I rebooted, updated GRUB, and rebooted into Salix without the rootfstype=ext4 boot parameter. The error message was gone. Something then in the huge kernel triggers this message. This is not the first time I have seen anomalies with the huge kernel. I prefer the generic kernel anyway.

I found the console fonts too tiny. I am not surprised by usability oversights like this. Developers tend to focus on graphical environments and ignore consoles. Tiny fonts seem endemic throughout the software industry. I decided to fix this.

I logged in and enabled the root account. I tested my typing by logging in as root. I was greeted with the standard Slackware greeting that I had mail. I ran the mail command only to discover the default Salix does not install the mailx package.

As I use static IP addresses, I configured Network Manager and restarted the service. With an IP address now assigned I updated the system. While updating I noticed No key for verification messages. That problem is cured by running:

slapt-get --add-keys

These kinds of warning messages should not be part of a final release.

I then installed mailx.

Finally, back to the tiny fonts. I found that the terminus font package is part of the default install. I copied my /etc/rc.d/rc.font script from my Slackware 14.1 partition and ran the script. I now had larger fonts.

Another boot quirk is several seconds after the login prompt appeared, text rudely appears referencing various mount points I have in my /etc/fstab. For example:

swap : ignored

The culprit of the interruption is a snippet at the end of the /etc/rc.d/rc.M script. The idea is to connect to network shares.

mount -a -v 2> /dev/null | grep -v "already mounted"

A similar snippet is found earlier in the rc.M script. The annoying interruption is resolved by eliminating the verbose option. Or commenting out the entire snippet — I do not know the reason behind this code or why for the similar duplication, which is not in the stock Slackware script.

These side trips in usability create fatigue.

I searched the Salix repos for a VirtualBox package. None. I knew then I needed to test compiling VirtualBox. Like my VM, I needed to install the kernel sources. Salix was running the 4.4.19 kernel but no sources for 4.4.19 were found. In my VM I found the package. On my laptop I only found sources for 4.4.14 and 4.4.38. I changed the repo to no avail. I installed the 4.4.19 sources, hoping that would trigger something. No luck.

I used a sledge hammer:

slapt-get --prompt --upgrade --ignore-excludes

This forced the system to update to the 4.4.38 kernel. I rebuilt the initrd, rebooted, updated GRUB, and rebooted to Salix.

The Salix default slapt-get configuration excludes kernel packages. I might not be the only person who has confronted this bug.

I repeated this sledge hammer exercise in my Salix VM. Because I seldom use LILO I made a common mistake. I forgot to run the lilo command before rebooting. Rebooting the VM resulted in a broken boot. I then discovered the Salix ISO does not support recovery as does the parent Slackware ISO. A wiki article refers to the same method used in the Slackware ISO, but this method does not work with the Salix 14.2 Xfce ISO. In the end I booted with the Slackware ISO and used chroot to run the lilo command.

Perhaps the Salix developers expect users to create a USB bootstick for recovery. Unfortunately, the Salix installer never prompts the user to create a bootstick like the parent Slackware installer. The /sbin/makebootstick is installed in the default Salix, but I found no reference anywhere in the menus. Searching the Salix wiki found no articles about making a bootdisk. Moreso, the script fails to run in Salix, complaining about missing syslinux files. There is a syslinux package in the Salix repos. Installing that package resolves the script complaints.

Salix does not create a group of the same name as the user when creating user accounts. I discovered this when I noticed the group ownership of the user's home directory was users. When I tried to chgrp the ownership the command failed, which led to my discovery. While I have seen distro maintainers differ about whether user home directories should be chmod 700, 750, 770, or 775, I do not recall ever seeing a user's home directory not part of the same group.

I do not know whether the missing group is an oversight or intentional. In my Salix VM I attempted to create another user account. There is no option in the Users and Groups dialog to make the user's default group name the same as the user's name. While the Salix dialog supports creating new groups, ensuring a new user is assigned to a group of the same name is a clunky two step process.

On my office desktop I tested the MATE Users and Groups dialog and the dialog created the corresponding group in one fell swoop.

This is a peculiar design decision that will not bode well in the enterprise or multi-user environment where privacy is a criterion.

I tried mounting my server NFS shares. This did not work. The rpcbind package was not installed. That Salix has the gigolo package installed implies some design focus toward easier networking. I found no wiki article addressing the shortfall. This is a 40KB package — insignificant with respect to the ISO size. I can somewhat imagine a default of chmod -x for the /etc/rc.d/rc.rpc script, but not having rpcbind installed puzzles me. Perhaps the installer could be updated to ask users whether they will be connecting to NFS network shares.

I noticed another curiosity after installing rpcbind. While the Salix rc.d scripts use color to pleasantly improve the boot scrolling, the /etc/rc.d/rc.rpc script does not use color. I wondered whether other rc.d scripts suffered likewise. A cursory check showed several more scripts without color, such as rc.nfsd, rc.ntpd. and rc.numlock. Paying closer attention to the boot output reveals more. Color in all of the rc.d scripts adds a friendlier interface and easier to read information.

I find both Xfce and MATE to lack certain features. For example, I prefer a persistent tab bar in my terminal to avoid epileptic window resizing. Xfce has this and MATE does not. I use expandable folders in the file pane of the file manager. Caja provides this and Thunar does not. Xfce supports a configurable menu button icon. MATE does not. MATE suffers from a delay when opening the panel menu. Xfce does not.

Both the Xfce and MATE desktops have been updated from the versions used in Slackware 14.1. I will have to test both desktops to notice improvements. I will wait for the release of the Salix 14.2 MATE Edition to compare some of the anomalies. Fortunately I need not wait for that release to use MATE in Salix Xfce. The full MATE desktop suite is supported in Salix and can be installed with gslapt or the slapt-get --install-set mate command.

I installed the MATE packages. While I have been using MATE for a long time, I want to again explore Xfce. Excepting a few quirks, I had a fair experience with Xfce when I was using Xubuntu. For the transition I have a familiar desktop with MATE as well as the Caja file manager rather than Thunar.

The MATE packages do not include MATE Tweak or Caja-Actions.

So much for preliminaries. Overall I find Salix 14.2 Xfce nicely responsive on the T400 laptop.

The Salix developers get a lot of things right. That they are motivated to make Slackware more friendly is much welcomed. Conversely, because of their focus to create a stand alone desktop ISO, they are a too aggressive with removing packages. Because the ISO image no longer fits on a CD — now requiring a DVD or USB flash stick, restoring a few packages to the image would help with many of the bumps I ran into. The final ISO size will still be much smaller than most distros.

I have yet to use Salix regularly, but I am comfortable thinking Salix could work for me as a common desktop for all of my computers. Unless something horribly explodes or irritates me in Salix I likely will not be testing additional distros for that purpose.

Important to me is whether using Salix will reduce my administrative load. The biggest difference is converting from slackpkg to slapt-get. I have not decided whether I want to make that transition. Despite that, using Salix means not dealing with systemd during my daily usage. Yet I can avoid systemd just as easily with the stock Slackware.

I have not yet committed to Salix. Through the past two and half years, each of the distros I tried to settle with presented too many paper cuts. A notable difference this time is Salix is based on Slackware, of which I familiar and able to customize. I could revert to the stock Slackware with little turmoil. My efforts to update from Slackware 14.1 32-bit to 14.1 64-bit provides a foundation for updating to Slackware 14.2. Possibly after fully updating to Slackware 14.2 I might not be as easily tempted by Salix. The slapt-getpackage management tool works fine and offers certain improvements over slackpkg, but I am unconvinced of moving. Dependency checking is useful, but I am long accustomed to building packages from scratch. Perhaps this is little more than staying with the devil I know rather than the devil I don't know.

For the moment I am returning to completing my updates from Slackware 14.1 to 14.2. Until then further testing of Salix will hold. Thereafter I hope to continue testing. For a serious test run, that means several weeks of continual usage. While I easily installed the MATE packages in the Salix Xfce release, I might wait until an official MATE version is released. Unknown at this point is how many additional usability side trips I make to iron the wrinkles in Salix. I already have found more than a few such wrinkles. Some of those wrinkles are inherited from the stock Slackware.

In all I think the Salix devs have done Slackware much good. I wish many of the changes were part of the parent Slackware.

Posted: March 02, 2017 Category: Usability Tagged: Salix, Slackware, Xfce

Next: Slackware As My Desktop

Previous: Salix 14.2 Xfce — 2