Arch Linux Review [20190701 Bootstrap Image]

Introduction

I had previously used Arch for about a year and a half starting early in 2015 on a Lenovo V570, which has since been replaced twice as my primary machine, first with an Acer V15 Nitro Black Edition, then with a Dell G5, relegating the Acer to backup status. After those eighteen months of stable use, if memory serves, a change in core Arch software caused the unofficial GUI package management programs, which can also manage AUR packages, to break. I didn't want to deal with this then when I had seven other distributions installed in the Lenovo. Now that I have the Dell G5 with a SATA SSD upgraded to a 500 GB NVMe SSD, a significant increase in speed and capacity from what I had on the Acer, and since I only have three distributions installed on this Dell so far, I want an Arch installation on the Dell which is my primary computer for serious use. I am also now willing to deal with the type of change that caused me to abandon Arch in 2016. I should clarify: during those eighteen months, almost none of the manual interventions mentioned on the Arch home page did affected me because I didn't have the affected packages installed. Those that did affect me were trivial to implement and the instructions for the interventions were clearly presented.

But really, the primary reason motivating me to use Arch this time, in addition to my passive appreciation of Arch's design, is the recent release of Plasma 5.16. Only Arch made it available very shortly after it was released. The first distribution I installed after I upgraded the SSD on the Dell G5 -- the Arch based Manjaro, which uses its own repositories, unlike the other Arch based distros -- delayed this update by almost a month.

So, I decided I needed Arch just in case I wanted to try the latest software. I should note that, in fairness to one of my favorite distributions, openSUSE Tumbleweed made Plasma 5.16 available in its official repositories only a few days after Arch, although it may have been available in optional repositories earlier, as is usually the case for important software with a large developer and user base.

The installation method was the same as that I used previously, an installation from an existing Linux installation by chroot into the Arch baseimage. This method avoids having to configure networking hardware on a console from within the non-graphical live ISO environment, which the default Arch installation method uses. I had considered using Manjaro as the host Linux as I did last time, but opted for openSUSE in order to experience using the arch-chroot tool from a dissimilar distribution.

Review

Arch is exactly what it promises to be. It is a simple design with well commented configuration files that allows users to assemble and configure the OS in exactly the manner they see fit. This entails advantages for a certain type of user, but inconvenience for another.

As an example of the simplicity in design and the transparency of the design to the user, consider Arch's initramfs generation system that is centered on one bash script mkinitcpio, and its configuration file /etc/mkinitcpio. This simple configuration file allows users to specify kernel modules, binaries, files, and hooks to be included in the initial ramdisk, as well as compression methods and options used to generate the initial ramdisk. This simple mechanisim allows users to easily optimize the initial ramdisk and the related boot process, unlike other distributions that rely on the more advanced -- in my opinion -- but more complex Dracut, which is not as transparent to users.

As another example of Arch's simplicity in design and the resulting complete and straightforward control afforded to the user, consider the pacman package manager and its configuration.

All aspects of the package management configuration including repositories and specific mirrors is controlled through one file, /etc/pacman.conf. The priority of the defined repositories is specified simply by the order they appear in this file. Paths to the underlying tools and data, such as the database file, the package cache, and the log file are defined here. The download command (through which the downloader program to be used is specified) is defined in this file, as well as various other options, such as packages to be held back during updates. Although this file is sufficient for configuring pacman, other files can be incorporated into this file through include directives. One such configuration item that is included by default in this file is the list of enabled mirrors: /etc/pacman.d/mirrorlist.

Contrast this to openSUSE -- which has a more advanced, but more complex package manager -- where there are two configuration files, one for zypper only -- /etc/zypp/zypper.conf and one for any package management program on the system -- /etc/zypp/zypp.conf. Repositories are defined in another set of files.

Because of the KISS philosophy that guided the Arch design, a user can become knowledgeable with a large part of the Arch system -- its package management -- simply by examining just this one file. And because of the simplicity of the configuration method a user can easily configure the system.

Along with the simplicity in design of Arch and the well commented configuration files, the user is aided in configuring the system as he or she desires by the Arch Wiki, an excellent information resource clearly describing system concepts and tools and providing the necessary knowledge to use these tools effectively.

Of course, depending on the perspective of the potential Arch user, these advantages of complete control of system may in fact be disadvantages instead of advantages. User's will need prior knowledge of general computer concepts, such as file systems, partitioning, bootloaders and GNU/Linux concepts and shell tools to not only maintain an Arch system, but to get the most out of it. For example, in using pacman, it is sometimes helpful to be aware of some bash concepts, such as using the output of a command in another command and piping the output of one command as the input of another. In these cases, users essentially extend the capabilities of pacman in a terminal by using UNIX concepts and tools.

Installation

As I mentioned above, I installed Arch using the Arch bootstrap image for an installation performed from an existing Linux instead of using the minimal Arch Live ISO, an alternative method described in the Arch Wiki. Because the host system is fully configured and provides a graphical environment, this method eases installation by not requiring users to configure networking inside the ISO environment -- which only provides a console terminal -- using very basic command line tools.

Those interested in this method can read the complete process in Installing Arch from an Existing Linux Installation.

Installing Arch the Arch way provides users with a customized system where the user selects and configures everything from the very basics of what graphics drivers and associated packages are installed, the bootloader to be used, the filesystems formats, the desktop environment(s), the display manager, and the software available in the installed system.

However, in my limited experience, in at least one area, the installation does not configure the installed system as completely as a manual text based installation should. I would have liked to have included in the /etc/fstab file my data partitions -- one ext4, and one NTFS -- and a partition which holds a virtual disk mounted to a directory in my user's home folder during the fstab generation phase of the installation. Unfortunately it isn't possible to specify a mount point in a user's home folder in /etc/fstab if the non-root user is created after rebooting. Maybe because of some corner case detail, such as using the same username on the new installation as on the host system or some other detail, trying to create the user before the initial reboot caused some problems the first time I performed this installation, specifically an error message to the effect "the user brook already exists." On further reflection, I may have done a few things differently to make my desired configuration possible, such as creating the directories to be used as mount points for these atypical partitions during the same earlier step as when I created the mount points for the root and home partitions and created my user without the useradd -m to prevent the user's home folder creation. This issue seems to be a further indication that Arch is very flexible but requires some knowledge of how Linux works to get the most out of this flexibility. Since the system is up and running, I am not going to experiment with this now.

Incidentally, this particular issue is something that the most advanced GUI installer, openSUSE's YaST can easily handle. The mount points and the partitions can be specified in the fstab during the same step as choosing partitions for the installation and YaST takes care of ensuring the mount point directories are created for the installed system.

Package Management

A centerpiece of an Arch system is the package manager pacman, which is much admired by Arch enthusiasts.

The pacman package manager is one of the major distinguishing features of Arch Linux. It combines a simple binary package format with an easy-to-use build system. The goal of pacman is to make it possible to easily manage packages, whether they are from the official repositories or the user's own builds.

In use, it is characterized by commands given in the form of short options as in

pacman -S aria2

to install aria2. Notice there isn't an install in this command as there would be in any other distribution's command line package manager -- not even an alternative short form based on install as in openSUSE's

zypper in aria2

or Sabayon's

equo i aria2

Commands for other common package management functions are equally unintuitive, but they are succinct and easily memorized after a short amount of use. Uncommon commands will however require using pacman's help or man page.

Also, there are cases where pacman's built in commands may not be able to provide the information or perform the task users want. For these situations it is beneficial for a user to have some experience with GNU/Linux or Unix, and tools these provide especially grep and the shell control operator |. For example, to remove orphan packages,

pacman -Rns $(pacman -Qtdqt)

Here, a command is used as the input of another command. Or to find available Nvidia drivers for the available Linux kernels

pacman -Ss linux | grep -A2 nvidia

where the output of a pacman command is used as an input to grep. And lastly, from the pacman Tips and Tricks page of the Arch wiki,

comm -23 <(pacman -Qqt | sort) <(pacman -Sqg base base-devel | sort)

lists all installed packages not required by other packages, and which are not in the base or base-devel groups. I think most users who accept the Arch way can use the distribution effectively even without being able to produce, from their own existing Linux knowledge, this last example, but it certainly shows that it would be helpful to have this type of knowledge.

In addition to the necessity of sometimes needing to use some of these GNU/Linux and UNIX tools together with pacman, sometimes some useful functionality is provided by tools outside of pacman itself for managing packages in the default repositories, let alone AUR packages. Some of these tools that were once part of the pacman package are in a separate optional package called pacman-contrib and include, among others, pactree to view a dependency tree of a package and paccache to clean the package cache.

One significant feature of Arch package management is managing packages from the AUR. Although this repository is not supported officially by the distribution, it is useful for users as many third party programs are available here but not in the official repositories. For example the Google Chrome, Firefox Beta, and Vivaldi browsers, Microsoft's Visual Studio Code, Eclipse IDE plugins, Spotify music player, and many themes are only available here. There are also many more obscure packages in the AUR that unfortunately may lead to breakages. I've experienced this with some random lua library I used to make an awesome conky. With the exception of these types of poorly maintained packages, the AUR extremely useful and a great asset for Arch users.

But since Arch doesn't support it officially in pacman, some manual steps -- which use Arch's well integrated and simple package building tools -- are necessary to install packages from the AUR. The process is to

1. Obtain the PKGBUILD -- the Arch package building script, similar to RPM's spec from the AUR website or by cloning the AUR package's git repository which is indicated on the package's page on the AUR

   git clone https://aur.archlinux.org/google-chrome.git

2. If using the git repository, clone the repository. If the PKGBUILD is obtained some other way, create a directory for the PKGBUILD and other files needed for the particular package, not automatically retrived when the PKGBUILD file is used by makepkg. Examine all files to ensure there is no malicious content.
3. From the new directory created for the PKGBUILD or the directory created when cloning the git repo, run

   makepkg -sic

Various AUR helpers that automate this process are available in the AUR itself.

While the AUR is great in that it allows users to find nearly any piece of software that they could want, there are inconveniences. The most annoying to me personally is that many packages have to be built locally on the user's own machine from the PKGBUILDs retreived from the AUR, whether manually or by the AUR helpers. Some software, while not being built on user's machines, is extracted from .deb packages and re-compressed and repackaged in Arch's default pkg.tar.xz format which still takes some time. Frequent updates of software from the AUR especially if many such packages are installed can become annoying over time. Fortunately for many popular software titles there are prebuilt binaries that take only the same time to install as packages from the official Arch repositories.

The other concern when using the AUR is the quality and integrity of the available packages. Low-quality and poorly maintained packages from the AUR will probably break. If the packages are libraries used by other software or replacements for packages in the default repos, the chance of causing a breakage that causes breakage of other software and even the system increases.

Not that my past Arch use was problematic, but on my current installation, I am keeping software from the AUR to a minimum, a practice that I employ even on my current installation of Manjaro. On this Arch installation, since I'll only be installing a few packages from the AUR, I'll even avoid using the GUI pacman frontends, streamlining the system and reducing the likelyhood of required intervention as described in this Arch news item.

For more on package management in Arch, including examples of some package management tasks, see Arch Linux Review [20190701 Bootstrap Image] Supplement: Installation

Fixes and Enhancements

After the installation described in Installing Arch from an Existing Linux Installation, I had a custom and completely functional system. There were no problems with graphics, networking, or suspend and hibernation. But I did have to issue a few fixes.

The most important was to enable sudo for my user.

Although I had added my user to the wheel group, this was not enough to enable it. I had to uncomment a line in /etc/sudoers using vizsudo to allow members of the wheel group to issue sudo commands.

Although all the necessary Bluetooth related software was installed as a dependency of installing PLasma, in order to use Bluetooth I had to enable the bluetooth service with

sudo systemctl enable bluetooth.service

and start it the first time with

sudo systemctl start bluetooth.service

. Prior to enabling the service the system tray applet didn't even appear. After this minor fix I was able to pair and use my Logitech M720 mouse and my Soundcore Life NC headphones with the Dell G5. The mouse continues to work reliably on Bluetooth, while after initial use streaming audio to the headphones seems to have encountered an issue, which I have yet to solve.

Although not strictly necessary, I will also have to go through the output of the individual installation commands to see what optional packages I should install for optimum performance, especially in the graphics related packages. Also, I can optimize the initramfs.

Documentation and Support

The Arch Wiki is and excellent resource for knowledge, not only for Arch but for other distributions also. It doesn't provide the general and more formalized knowledge of the openSUSE/SUSE books, but it is excellent for resolving specific issues and finding the relevant information on a particular topic.

However, as a podcast host recently mentioned, and I agree somewhat, Wiki pages related to installation, unlike the other single topic pages and the system itself, is complex, requiring users to carefully read and follow not only the spider web of links to pages relevant to the installation method used, but all other pages regarding installation. Sometimes relevant pages are not even branches off the main article. For example, when reading the Wiki page for installing from an existing Linux installation and the branching pages, the need for verifying the downloaded image is mentioned with a link to instructions for verifying using GPG. However, the command in the link only works if the Arch Linux signing public keys have already been imported. If they have not, the command that is needed to import the keys and verify the key is actually on a different page regarding pre-installation linked to from the default installation instructions.

Recommendation

Arch Linux executes its well defined guiding principles, as described on its Wiki extremely well. It provides users a minimal system that is simple in design, making its inner workings transparent to users. This affords users a flexible system that they can configure completely to their liking. In fact, users must configure the system, as Arch is intended for users that want a basic platform on which they can assemble and configure an OS that meets their exact needs. For those without prior Linux knowledge but have the motivation can use it as an excellent learning tool. Users who install a distribution like EndeavourOS, formerly Antergos, without ever having installed and assembled an Arch system to meet their exact needs are doing themselves a disservice.