Author Archives: Lorenzo Bettini

About Lorenzo Bettini

Lorenzo Bettini is an Associate Professor in Computer Science at the Dipartimento di Statistica, Informatica, Applicazioni "Giuseppe Parenti", Università di Firenze, Italy. Previously, he was a researcher in Computer Science at Dipartimento di Informatica, Università di Torino, Italy. He has a Masters Degree summa cum laude in Computer Science (Università di Firenze) and a PhD in "Logics and Theoretical Computer Science" (Università di Siena). His research interests cover design, theory, and the implementation of statically typed programming languages and Domain Specific Languages. He is also the author of about 90 research papers published in international conferences and international journals.

Hyprland and the Variety wallpaper manager

Leave a reply

I’ve just started experimenting with the Wayland compositor Hyprland and wanted to use my favorite wallpaper manager, Variety. Unfortunately, Variety does not support Hyprland out of the box. However, it’s easy to make it work also on Wayland.

I’m going to use Arch Linux in this blog post.

First of all, you must install “swaybg”, a wallpaper tool for Wayland compositors, and “variety”:

Now, start variety and do the first-time configuration. Currently, trying to change the wallpaper will not work.

Variety creates the directory “~/.config/variety/scripts”. Edit the file “set_wallpaper” inside that directory and search for the block starting like this:

Change it like that (you could also remove the part about SWAYSOCK if you want or if you don’t plan to use “sway” at all):

This relies on the XDG_CURRENT_DESKTOP environment variable to be set accordingly, which should be like that automatically; you might want to check that:

Restart Variety, and now you can change the wallpaper!

Stay tuned for more posts on Hyprland 🙂

 

Installing Arch Linux with BTRFS on a PineBook Pro (external storage)

Leave a reply

This is a follow-up to the article Installing Arch Linux on a PineBook Pro (external storage); differently from the previous post, this one is based on more automatic mechanisms, so it will be easier to copy and paste commands once a few variables have been correctly and carefully set. Moreover, in this post, I’ll install KDE instead of GNOME. Finally, we’ll use BTRFS for the main partition, instead of EXT4.

This post will describe my experience installing Arch Linux on a PineBook Pro on external storage (a micro SD card in this example). Thus, the Manjaro default installation on the eMMC will not be touched. You should use a fast card, or the overall experience will be extremely slow.

The post is based on the instructions found at https://wiki.pine64.org/wiki/Pinebook_Pro_Software_Release#Arch_Linux_ARM.

The installation process consists of two steps:

  • First, install the official Arch Linux ARM distribution; this will not be enough to have many hardware parts working (e.g., WiFi, battery management, and sound).
  • Then, add the repositories with kernels and drivers for the PineBook Pro.

The first part must be performed from an existing Linux installation on the PineBook Pro. I will use the Manjaro installation that comes with the PineBook Pro. The second part will be performed on the installed Arch Linux system on an external drive (a USB stick in this example). Since after the Arch Linux installation, the WiFi is not working, for this part, you need to connect to the wired network, e.g., with an ethernet USB adapter.

Finally, I’ll also show how to install KDE.

First part

This is based on https://wiki.pine64.org/wiki/Installing_Arch_Linux_ARM_On_The_Pinebook_Pro.

I insert my SD card, which is /dev/sda. (Use “lsblk” to detect that.) By the way, typically, an SD card should be detected with a device name of the shape “/dev/mmcblkX”, but in this example, the SD card is inserted in a USB adapter, so its device name has the typical shape “/dev/sdX”.

From now on, I’m using this device. In your case, the device name might be different.

From now on, all the instructions are executed as “root” from a terminal window; thus, I first run:

I will do the following steps in a directory of the root’s home:

We need to download and extract the latest release of Tow-Boot for the Pinebook Pro from https://github.com/Tow-Boot/Tow-Boot/releases. At the time of writing, the latest one is “2021.10-005”:

Now we flash Tow-Boot to /dev/sda (replace this with the device you are using).

Remember: this will wipe all the contents of the specified device. Moreover, make sure you specify the correct device, or you might overwrite the eMMC of the computer.

To make things easily reproducible and minimize the chances of specifying the wrong device name (which is extremely dangerous), I will use environment variables:

The process creates the partition table for the device, with the first partition for Tow-Boot. This first partition must not be modified further. As you see in a minute, we skip the first partition when we further partition the disk.

The output should be something like this:

Now, we must create the partitions on the USB stick. The process is documented step-by-step here https://wiki.pine64.org/wiki/Installing_Arch_Linux_ARM_On_The_Pinebook_Pro#Creating_the_partitions, and must be followed strictly:

The instructions must be followed strictly concerning, at least, the very first partition (the boot partition) that will be created, which must NOT touch the one created in the previous step. Then, after creating the boot partition, I’ll do things slightly differently: I will create a SWAP partition (not contemplated in the above instructions; The PineBook Pro has only 4 Gb of RAM, and it is likely to exhaust it, so it’s better to have a SWAP partition to avoid system hangs. Then, I’ll create the root partition.

These are the essential contents of my terminal where I follow the above-mentioned instructions (since I had already used this USB stick for some experiments before writing this blog post, fdisk detects an existing ext4 signature). Remember, though, that I created a SWAP partition that was not described in the above-mentioned instructions:

Now I format the boot, the swap, and the root partitions. I will use EXT4 for the boot partition and BTRFS for the root partition.

Again, to increase reproducibility and avoid possible mistakes, I’m going to define additional environment variables, based on the one I have already created above, to refer to the 3  partitions:

It’s worthwhile to double-check that all the environment variables refer to the right partitions:

Remember that I’m using the environment variables set above:

Now we mount the root partition to create the BTRFS subvolumes, following a standard scheme, and we unmount it:

Now we have to mount all the subvolumes to the corresponding directories (the “-m” flag creates the mounting subdirectory if it does not exist); I’m enabling BTRFS compression (by default, the compression level for zstd will be 3):

Then, we mount the boot partition on “/mnt/boot” (again, by creating that):

Let’s verify that the layout of the destination filesystem is as expected:

Now, we download the tarball for the rootfs of our USB stick installation. The instructions are once again taken from the link mentioned above, and they also include the verification of the contents of the downloaded archive:

And we extract the root filesystem onto the mounted root partition of our USB stick:

This is another operation that takes time.

Now, we must create the “/etc/fstab” on the mounted partition. To do that, we need to know the UUID of the two partitions by using “blkid”. You need to take note of the UUID from the output (which will be completely different according to the used external device):

Let’s take note of the UUIDs (remember, they will be different in your case) and create the corresponding environment variables:

We create the file “/etc/fstab” in “/mnt” according to the BTRFS subvolumes and to the other two partitions. This can be done by running the following command, which relies on the values of the 3 environment variables that we have just created:

Finally, we need to create the file “/mnt/boot/extlinux/extlinux.conf” (the directory must be created first, with:

Once again, the contents are generated by the following command that relies on the environment variable for the UUID of the root partition:

Note that we must specify “rootflags=subvol=@” because the “/” of is on the subvolume “@”. Otherwise, the system can boot, but then nothing else will work.

We can now unmount the filesystems

And we can reboot into the (hopefully) installed Arch Linux on the USB stick to finish a few operations. Remember that we need a wired connection for the next steps.

Upon rebooting, you should see the two entries (if you let the timeout expire, it will automatically boot the first entry):

After we get to the prompt, we can log in with “root” and password “root” (needless to say: change the password immediately).

Let’s connect a network cable (you need a USB adapter for that), and after a few seconds, we should be online. We verify that with “ifconfig”, which should show the assigned IP address for “eth0”.

Since there’s no DE yet, I suggest you keep following the official web pages (and this blog post) by connecting to the PineBook Pro via SSH so that it will be easy to copy and paste commands into the terminal window of another computer. Moreover, when logged into the PineBook Pro directly, you will see lots of logging information directly on the console (I guess this could be prevented by passing specific options to the kernel, but we’ll install a DE later, so I don’t care about that much). The SSH server is already up and running in the PineBook Pro installed system, so once we know the IP address from the output of “ifconfig”, we can connect via SSH. However, root access via SSH is disabled, so we must connect with the other predefined account “alarm” and password “alarm” (again, you might want to change this password right away):

Once we’re logged in since “sudo” is not yet configured, we switch to root:

We have to initialize the pacman keyring:

The guide https://wiki.pine64.org/wiki/Installing_Arch_Linux_ARM_On_The_Pinebook_Pro ends at this point.

What follows are my own instructions I usually run when installing Arch.

In particular, I configure time, network time synchronization, and timezone (Italy, in my case):

The next step is required for doing gnome-terminal work (and it’s also part of the Arch standard installation instructions):

Edit “/etc/locale.gen” and uncomment “en_US.UTF-8 UTF-8” and other needed locales.

Generate the locales by running:

Edit the “/etc/locale.conf” file, and set the LANG variable accordingly, for example, for the UTF-8 local above:

We could run a first system upgrade

I don’t know if that’s strictly required because we’ll add the additional repository for the PineBook Pro in a minute. However, just in case, it might be better to update the system.

Let’s reboot and verify that everything still works.

The kernel at the time of writing is

NOTE: By the way, I noted that if I want to boot from the USB stick, it’s better to use the right-hand side USB port (which is USB 2) instead of the left-hand side port (USB 3). Otherwise, the system seems to ignore the system on the USB stick and boots directly to the installed Manjaro system.

Second part

As mentioned above, I suggest connecting to the PineBook Pro via SSH. In any case, what follows must be executed as “root” (“su -“).

Let’s now add the repositories with kernels and drivers specific to PineBook Pro.

The project is documented here: https://github.com/SvenKiljan/archlinuxarm-pbp, and these are the contents of the additional repository that we’ll add in a minute https://pacman.kiljan.org/archlinuxarm-pbp/os/aarch64/.

Note that this project also provides a way to install Arch Linux directly with these repositories, with a procedure similar to the one in the first part. I prefer to install official Arch Linux first and then add the additional repositories, though.

The addition of the PineBook Pro repository to an existing Arch Linux installation and the installation of specific kernel and drivers is documented as a FAQ: https://github.com/SvenKiljan/archlinuxarm-pbp/blob/main/FAQ.md#how-do-i-migrate-from-other-arch-linux-arm-releases-for-the-pinebook-pro.

The addition of the PGP key and the repositories to “/etc/pacman.conf” is done by pasting the following commands (remember, as the user “root”):

Let’s now synchronize the repositories

And let’s install the packages specific to the PineBook Pro (note that we’re going to install the Linux kernel patched by Manjaro for the PineBook Pro):

Of course, we’ll have to answer “y” to the following question:

Let’s reboot and verify that everything still works (again, by connecting via SSH).

Now, we should be using the new kernel:

Before installing a DE, I prefer creating a user for myself (“bettini”) and configuring it as a “sudoer”. (We must install “sudo” first).

Then (by simply running “visudo”), we enable the users of the group “wheel” in “/etc/sudoers”; that is, we uncomment this line:

Then, I try to re-connect with my user and verify that I can run commands with “sudo” (e.g., “sudo pacman -Syu”).

Install KDE

As usual, I’m still doing these steps via SSH.

I’m going to install KDE with some fonts, pipewire media session, firefox, and the NetworkManager:

It’s about 680 Mb of packages to install, so please be patient.

Now, I enable the primary services (the login manager, the NetworkManager to select a network from KDE, and the profile daemon for switching between power profiles, e.g., “Balanced” and “Powersave”):

OK, time to reboot.

The graphical SDDM login manager should greet us this time, allowing us to get into KDE and select a WiFi connection.

NOTE: I always hear a strange noise when the login manager or the KDE DE starts. It also happens with the pre-installed Manjaro. It must be the sound card that gets activated…

IMPORTANT NOTE: Upon rebooting, the WiFi does not always work (it looks like the WiFi card is not seen at all); that also happens with Manjaro. The only solution is to shut down the computer (i.e., NOT simply rebooting it) and boot it again.

Here’s the KDE About dialog:

And of course, once installed, let’s run “neofetch”:

That’s all for now!

In a future blog post, I’ll describe my customizations to KDE (installed programs and configurations).

Stay tuned! 🙂

My script for automated Arch Linux installation

2 Replies

In a previous post, I reported the procedure for installing Arch Linux. The procedure is basically the one shown in the official Arch Wiki.

After a few manual steps, this post will show my installation script for automatically installing Arch Linux. I took inspiration from https://github.com/ChrisTitusTech/ArchTitus, but, differently from that project, my script is NOT meant to be reusable. The script is heavily tailored to my needs. I describe it in this post in case it might inspire others to follow a similar approach 🙂

The script (which actually consists of several scripts called from the main script) is available here: https://github.com/LorenzoBettini/my-archlinux-install-script.

I’ll describe the script by demonstrating its use for installing Arch Linux on a virtual machine (VirtualBox). However, I use the script for my computers. Also, for real computers, I perform the installation via SSH from another computer for the same reasons I have already explained.

The virtual machine preparation is the same as in my previous post, so I’ll start from the already configured machine.

I start the virtual machine with the Arch ISO mounted:

Inside the live environment, the SSH server is already up and running. However, since we’ll connect with the root account (the only one present), we must give the root account a password. By default, it’s empty, and SSH will not allow you to log in with a blank password. Choose a password. This password is temporary; if you’re in a trusted local network, you can choose an easy one.

Then, I connect to the virtual machine via SSH.

From now on, I’ll insert all the commands from a local terminal connected to the virtual machine.

Initial manual steps

First, I ensure the system clock is accurate by enabling network synchronization NTP:

Then, I partition the disk according to my needs. My script heavily relies on this partitioning scheme consisting of four partitions:

  • the one for booting in UEFI mode, formatted as FAT32, 300Mb (it should be enough for UEFI, but if unsure, go on with 512Mb)
  • a swap partition, 20Gb (I have 16Gb, and if I want to enable hibernation, i.e., suspend to disk, that should be enough)
  • a partition meant to host common data that I want to share among several Linux installations on the same machine (maybe I’ll blog about that in the future), formatted as EXT4, 30Gb
  • the root partition, formatted as BTRFS, the rest of the disk

To do that, I’m using cfdisk, a textual partition manager, which I find easy to use. In the virtual machine, the disk is “/dev/sda”:

The partitions must be manually formatted:

Sometimes, I have problems with the keyring, so I first run the following commands that ensure the keyring is up-to-date:

I’m going to clone the installation script from GitHub, so I need to install “git”:

And now, I’m ready to use the installation script.

Running the installation script

First, I clone the installation script from GitHub:

The script has no parameter but relies on a few crucial environment variables to set appropriately. The first four variables refer to the partitions I created above. The last one is the name for the machine (in this example, it will be “arch-gnome”):

The script will check that all these variables are set. However, it does not check whether the specified partitions are correct, so I always double-check the environment variables.

And now, let’s run it:

The script will do all the Arch Linux installation steps. These automatic steps correspond to the ones I showed in my previous post, where I ran them manually.

When the script finishes (it takes a few minutes), I have to perform a few additional manual operations before rebooting. I’ll detail these latter manual operations at the end of the post. In the next section, I’ll describe the script’s parts.

The installation script(s)

As I anticipated, the script actually consists of several scripts.

The main one, install.sh, is as follows:

Note that the installation logs are saved in the “bettini” user’s home directory (the last run script will create the user). These can be inspected later.

The main script calls the other scripts.

We have the script for checking that all the needed environment variables are set (00_check.sh):

The script 01_mount-partitions.sh mounts the partitions and, for the main BTRFS partition, also creates the BTRFS subvolumes:

The script 02_pacstrap.sh performs the “pacstrap” (it also sets the mirrors) and generates the /etc/fstab:

Then, 03_prepare-for-arch-chroot.sh prepares the script for arch-chroot: it copies all the shell scripts into the /mnt/root:

In fact, by looking at the main script, you see that further shell scripts are executed using arch-chroot.

The script 04_configuration.sh takes care of all the configuration steps:

Note the use of the environment variable INST_HOSTNAME for creating the file /etc/hosts. I’m using en_US.UTF-8 for the language, but other local configurations are for Italy.

The script 05_bootloader.sh configures and installs GRUB. It also configures GRUB for the “mem_sleep_default” parameter (for suspend) and for hibernation; in that respect, it also configures mkinitcpio accordingly (note the “resume” hook):

Note that it uses the generated /etc/fstab to retrieve the UUID of the swap partition.

Finally, the script 06_user.sh creates my user and configures it so that I can use “sudo”:

It also sets the right permissions for my user in the mount point where I want the shared partition.

That’s all. The script also prints a message to remind me to set the password for my user.

Final manual steps

I execute a few manual steps to finalize the installation when the script finishes.

First of all, I once again use arch-chroot:

And I set the password for my user:

Then, I install KDE or GNOME (not both).

For KDE, I would run the following:

For GNOME, I would run the following:

And that ends the installation.

I exit chroot and unmount /mnt:

As you see, most of the steps are performed by the script! 🙂

I can restart the system (in this example, the virtual machine) and enjoy the installed Arch!

That’s another reason why I love Arch Linux so much: the installation can be easily scripted!

It took me some time to finalize all the scripts, but using a virtual machine, especially with snapshots, wasn’t that hard. I encourage you to bake your installation script. It’ll be fun 🙂

By the way, before existing chroot and rebooting, I usually run my Ansible playbook for installing other programs (either KDE or GNOME) and configure the system and user according to my needs. I’ll blog about such a playbook in the future.

KVM Virtual Machine Manager and Virtual Machines on external drives

2 Replies

Last year, I blogged about my first experiences with KVM and Virtual Machine Manager.

Then, I stopped using KVM because I’ve always found VirtualBox easier for my experiments. In particular, with VirtualBox, it is trivial to store virtual machines on an external drive (I mean, a fast external SD, of course): you specify to use a directory on the external drive, and all information about the virtual machine will be stored there. Then, you attach the drive to another computer with VirtualBox and open the virtual machine from the external drive. Easy!

Things are more complicated with KVM, QEMU, and Virtual Machine Manager. Even making QEMU access an external drive requires additional configuration steps.

In this blog post, I’ll summarize the steps to achieve that.

I’ll first show the manual export/import procedure for the machines’ metadata information. Then, I’ll show a different approach based on symlinks.

It was time to try KVM again because it’s faster than VirtualBox.

I’ll describe the installation steps for EndeavourOS and pure Arch Linux. I guess the steps for other distributions are similar.

Installation and configuration

Let’s install a few packages for KVM, QEMU, and the Virtual Machine Manager:

If you get this message, accept to remove “iptables”:

To use your user without entering the root password, we need to edit the file “/etc/libvirt/libvirtd.conf” and uncomment the following lines:

Or, append them at the end of the file:

Add your user account to the “libvirt” group.

Now comes the crucial part for letting QEMU handle machines on external drives: we need to add our user to “/etc/libvirt/qemu.conf”. This can be done by setting the appropriate entries in the file or by simply appending the entries at the end of the file:

If you want to start the virtualization service and the default virtual network automatically at boot, you run:

Since I’m not using virtual machines daily, I prefer to start them when needed, so I don’t run the above commands. Of course, I must remember to run these commands (note, for the network is “start” instead of “autostart”) before starting the “Virtual Machine Manager”:

Remember you can always use:

to see the service status and possible errors shown when running this command.

OK, time to reboot now.

Let’s create a virtual machine on an external drive

I created a directory “kvm/images” on my external USB SD to store the virtual machine images.

Let’s start the “Virtual Machine Manager” program. We should see “QEMU/KVM”:

Let’s create a new virtual machine with the leftmost toolbar button.

I specify a local ISO.

I don’t create a pool for ISOs and use “Browse Local” to select an ISO in my external drive.

In this example, I will install EndeavourOS on the virtual machine. I have to select the operating system manually (start typing, and you get completions):

Time to allocate resources for the virtual machine. I’m giving the VM half my RAM and half my cores:

Now here’s the essential part of disk selection. Remember, I want to use my external drive, so I select custom storage and press “Manage”:

In the following dialog, I use the “+” button in the bottom left corner to create a new pool:

I give the pool the name “images” and specify the directory I mentioned above on my external drive:

After pressing “Finish”, I select the created pool and add a “Volume” (with the other “+” button)

I give the disk image a proper name and enough size (recall that the image will NOT allocate all the size immediately, but only on-demand):

Select the volume and press “Choose Volume”:

On the final dialog, make sure the default network is selected and that you check “Customize configuration before install” (note that I also changed the name for the virtual machine):

Let’s press “Finish,” and get to the configuration dialog. I changed the Firmware from “BIOS” to “UEFI”, pressed “Apply,” and finally, we can start the installation with “Begin Installation”.

We should not get any error from QEMU because it cannot access the external drive, thanks to the configuration shown above in the qemu.conf file!

After the GRUB menu, we should see the installer log:

And then, the EndeavourOS installer dialog:

Since I’ve already blogged about EndeavourOS installation, I’ll skip the detailed steps. I’ll install the GNOME desktop environment and let the installer use the whole disk space with the BTRFS filesystem and SWAP with hibernate (later, I might want to check whether hibernate works in the VM).

In a few minutes, the installation finishes! We get to the GRUB menu of the installed system:

And to the installed GNOME desktop:

The disk image is correctly created in the external drive:

And the information about the virtual machine is in the:

Export the virtual machine

First, let’s shut down the machine.

Let’s export the virtual machine to use it from another computer. I understand that having the same software on the other host is crucial. Since I’m using EndeavourOS or Arch on my main computers, that is not a problem.

But isn’t the virtual machine already in an external drive? Why do I have to export it?

That’s the main difference with VirtualBox I mentioned at the beginning. The disk image is on an external drive, but the virtual machine information (configuration and metadata) is on a local XML file (see the listing of “/etc/libvirt/qemu” above; the XML file of the virtual machine is “eos-kvm-gnome.xml”, after the name I gave to the virtual machine when I created it).

Remember that the XML has an absolute path pointing to the disk image on the external drive:

So, again, in the other computers, the mount point of the external drive must be the same; otherwise, the absolute path must be manually adapted.

We could copy the XML file directly on the external drive (somewhere near the disk image to be easily found), e.g.:

Alternatively, if we don’t remember the location of the XML file, we can use the “dump” command.

For example, we can first list the current machines (in the example, I have only one):

And then, we dump its XML configuration:

We’re ready to import and use the VM on another computer

Import the virtual machine

I have already installed and configured KVM on another computer, following the same procedure at the beginning of the post.

Since I haven’t enabled the services at boot time, I run the following:

I connect the external drive and ensure it’s mounted (remember, on the same mount point as in the other computer).

Then, I create the virtual machine information locally by using the XML file on the drive I created above:

We can verify that the XML is now in the directory of QEMU:

Let’s start “Virtual Machine Manager,” and we can see the virtual machine:

We can start it, and it should work as on the other computer.

Cloning and Snapshots

Let’s create a clone of this virtual machine, e.g., with the context menu of the machine in the main user interface.

The destination path is based on the path of the current machine, the external drive, which is good.

Let’s wait for the clone to finish, and then we have two virtual machines:

If I want this clone to be usable on other computers, I repeat the export procedure for this new virtual machine:

I’ll leave this clone virtual machine as it is for now, and I’ll create a snapshot in the other virtual machine, the original one.

Snapshot information is stored somewhere else, NOT in the XML of the virtual machine:

So we need them as well if we want to use them on another computer.

To add the snapshot to the other computer, I have to run:

However, keep in mind that if you try to start a snapshot, you get this warning:

So if you don’t want to lose the current state, create another snapshot for the current state before restoring a previous one. Moreover, if the snapshot’s state is “Shutoff”, “starting” the snapshot only restores it. Then, you must start the virtual machine.

A different approach: symlinks

In the previous sections, I showed how machine information (including snapshots) and images could be put on external drives. Besides the machine images residing on external drives from the beginning, the machine metadata is still on your hard disk. In fact, you must first export them (e.g., on the external drive) and then import them on another computer.

A more radical approach consists of keeping the metadata on the external drive only and creating symlinks in each computer’s libvirt/qemu directories.

On the first computer, the XML files of machine information and snapshots have to be copied onto the external drive. IMPORTANT: don’t dump information as we did above; you need to copy the original XML files themselves. Dumping does not generate the exact XML files stored on the libvirt/qemu directories. In fact, as shown above, the dumped XML files must be imported with dedicated commands.

In my case, on the first computer, I run:

So, on the external drive, I end up with these contents:

On the same computer, I run the following commands (make sure the “libvirtd.service” is not running):

Now, I can start the “libvirtd.service” and the default network, and I make sure I can still access all my machines stored on the external drive, including all the machine information.

Of course, if you have never created virtual machines and want to start creating them on the external drive, it is enough to run the above commands. Then, start creating machines. Remember to select the external drive for the image location.

Then, on the other computers where I have already installed the same software for KVM, QEMU, etc., I first ensure the “libvirtd.service” is not running (in case stop it). Then, I connect my external drive and run the above commands (these will remove possible existing machines’ information, so be careful).

Of course, the above commands must be run only the first time.

Now, I can start the “libvirtd.service” and the default network, and I can access all my machines stored on the external drive, including all the machine information. Every modification (an image content or a machine configuration) will be stored on the external drive.

This approach works if you want to store ALL your machines on the external drive. You won’t have to keep the information in sync because they are stored in a single place.

If you need to keep some machines on your computers and others on different external drives, you must use the above-shown manual procedure for exporting and importing. It is then up to you to remember to re-export/re-import if you change a machine’s configuration or a snapshot.

Happy virtualization! 🙂

Customizing Gnome in Arch Linux on a PineBook Pro

Leave a reply

In a previous blog post, I showed how to install Arch Linux on a PineBook Pro.

In this blog post, I’m showing how I customize Gnome on that installation.

First, Gnome 43 has “Gnome Console” as the default terminal application. I wouldn’t say I like it since it’s too basic. So I install the traditional “Gnome Terminal”:

Then, I set “Ctrl+Alt+T” as a shortcut for opening the terminal:

Then, I install an AUR helper. I like “yay,” so I first installed the needed dependencies:

And then

I install, by using “yay”, the helper the “Gnome Browser Connector” to install Gnome extensions from Firefox (Some extensions are already installed by default as system extensions. You can use the “Extensions” application to enable/disable extensions):

Now I can navigate to https://extensions.gnome.org and install and enable a few extensions (you also need to install the Firefox extension add-on when asked). For example, “AppIndicator and KStatusNotifierItem Support” and “X11 Gestures”.

The last extension helps enable Touchpad gestures in the X11 session (Gnome Wayland already provides touchpad gestures, but I prefer to use the X11 session). This extension relies on “touchegg” that must be installed. For ARM, we need to install the AUR package:

You will get this warning, but proceed anyway: it compiles and works fine:

Let’s start “touchegg” and verify that gestures work

And then let’s enable it so that it automatically starts on the subsequent boots:

Let’s move on to ZSH, which I prefer as a shell:

Since I’m going to install “Oh My Zsh” and other Zsh plugins, I install these fonts (remember from the previous post that I had already installed “noto-fonts” and “noto-fonts-emoji”) and finder tool (“curl” is required for the installation of “Oh My Zsh”):

Let’s install “Oh My Zsh” by running the following command as documented on its website:

When asked, I agreed to change my default shell to Zsh. In the end, we should see the prompt changed to the default one of “Oh My Zsh”:

I then install some external plugins:

And I enable them by editing the ~/.zshrc, in particular, the “plugins” line (I also enable other plugins that are part of the OMZ distribution):

Once saved, you have to start a new terminal with zsh to see the plugins in action (remember that, until you log out and log in, the default shell is still BASH, so you might have to run “zsh” manually to switch to ZSH in the currently logged session).

Besides the syntax highlighting for commands, you have completion after “cd” (press TAB), excellent command history (with Ctrl+R), suggestions, etc.

Let’s switch to the “Starship” prompt. Let’s run the documented installation program:

Now, let’s edit the ~/.zshrc file again; we comment out the line starting with “ZSH_THEME,” and we add to the end of the file:

Opening another ZSH shell, we should see the fantastic Starship prompt in action, e.g.,

To quickly search for file names from the command line, I install “locate”, enable its periodic indexing and run the indexing once the first time (if you’re on a BTRFS file system, you might want to have a look at this older post of mine):

Then, you should be able to look for files with the command “locate” quickly.

Gnome uses “Tracker” (in the current version, the command is “tracker3”) for file indexing and searching, e.g., from the “Activities” view. I like it, and it quickly keeps the index up to date. However, the “tracker extract” service also indexes the file contents, and that uses too many resources, so I disable that service:

I also use the “guake” drop-down terminal a lot:

I run it once (it’s enabled by default by pressing “F12”), and I configure it to start automatically when Gnome starts (by running “Guake Preferences” -> “Start Guake at login”).

I hope you enjoyed this post! 🙂

Installing EndeavourOS Linux on an Acer Aspire Vero

Leave a reply

I have already blogged about my new computer Acer Aspire Vero and how to install Ubuntu on that.

In this blog post, I’ll briefly discuss installing EndeavourOS on the same computer. I wrote it some months ago, so it’s not based on the new EndeavourOS Cassini version. It’s based on Endeavour OS Nova. However, the procedure and the results should be the same also with the current version of the EndeavourOS installer.

First of all, the installer detected my Ethernet card and nicely proposed using a working driver:

I choose the default.

Then, after the WiFi connection has been established, it’s time to start the installation:

I still haven’t tried “Customizing the install process”, https://discovery.endeavouros.com/installation/customizing-the-endeavouros-install-process/2022/03/. I’ll have a look at it in the future, maybe.

First, I updated the mirrors, choosing my country (actually, it had already been detected by the installer):

I started the installer and chose the “Online” method to install KDE, not Xfce (the default DE).

I choose America English (though I’m Italian, I always prefer to have my OS in English). The location has been automatically detected again, and I’ll stick with the proposed settings:

I choose “Manual partitioning” because I want to keep Windows and my current two other Linux installations.

I mount the EFI partition to “/boot/efi” (the “boot” flag is automatically selected):

I create a new partition for the root partition on the free space, choosing BTRFS:

I also mount the existing EXT4 partition to share some common work data (including Docker images, containers, and Java-related stuff). The final layout is as follows:

When I continue, I get a warning because of the EFI partition, which is expected to be at least 300Mb; mine is smaller, but I’m sure there’s enough space, so I continue:

For the desktop, I select “Plasma KDE”.

Now we get to the package selection. Some packages are already selected by default:

I deselect from “Desktop Base” => “GPU drivers” the “xf86-video-intel” since it’s known to give a few problems (including the screenshot tool Spectacle capturing old screen contents), and I’ll rely on the default mesa. I also select the LTS kernel in additions since I prefer an LTS besides the latest kernel (in case of problems, the LTS kernel usually works best).

Moreover, I also select everything concerning printing:

After the user details, it’s time to review the partitioning, which looks reasonable.

Let’s start the installation! Remember to “Toggle log” to see what the installer is doing under the hood.

In a matter of minutes, the installation finished successfully.

Before rebooting, you might want to save the “endeavour-install.log” file generated by the installer in the home folder of the “liveuser”.

And here’s the installed system:

I set the fonts to 120 (that is, 25% bigger) so that I could read better.

The sound does not work fine. I tried to play a video on YouTube, and it worked, but now and then, I get no sound at all (even if I increase/decrease the volume, I get no sound from the DE). I guess that’s due to the “wireplumber” installed by default. On Arch News, they suggest using “pipewire-media-session” instead of “wireplumber”. So I do as suggested:

And reboot (you have to accept the removal of “wireplumber”).

EndeavourOS works great on this laptop! 🙂

Snapper and grub-btrfs in Arch Linux

2 Replies

Up to now, I’ve been using Timeshift and grub-btrfs in my Linux installations because I found Timeshift easy to use and straightforward to install. I was scared by Snapper because I thought it was hard to use and complex to install. I had been fooled by many tutorials I found online, but maybe they were obsolete, or they were not using the right packages. I was wrong: using the right packages provided in Arch and AUR repositories makes it straightforward to use Snapper and grub-btrfs. You also get a program that automatically takes a snapshot when installing/updating your system.

This is more of a report than a tutorial.

I tried this procedure on EndeavourOS and Arch, and, as expected, the final result was the same. However, as shown later, Arch requires a few adjustments in the /etc/fstab file.

The BTRFS subvolume layout of EndeavourOS is ideal for snapper snapshots and for booting them with grub: the subvolume “@” for “/”, “@home” for “/home”, and separate subvolumes for “/var/log” and “/var/cache”. That’s basically the same as I use for Arch installations.

If you already have grub-btrfs because you use it with Timeshift (e.g., with the procedure described in one of my previous posts), it’s better to remove the package so that it will also remove possible enabled services and the custom configurations for timeshift:

If you were using Timeshift, you also provided a custom configuration for grub-btrfsd, which is not automatically removed during the previous command. The files must be removed explicitly:

Also, remove timeshift and timeshift-autosnap

If you don’t do that now, you will be asked to do that when installing the packages for snapper anyway.

If you installed Arch the Arch way, when generating /etc/fstab, the command has added “subvolid=…” entries in /etc/fstab, which will disturb when restoring snapper snapshots. For example, if you tried to restore a snapshot with btrfs-assistant (which we’ll install in a minute), you’ll get such a warning dialog:

Since the generated /etc/fstab contains both “subvolid=…” and “subvol=…”, I find it safe to remove the “subvolid” parts. I do that with this sed command (of course, do that at your own risk and take a backup of the file first):

If you installed another Arch-based distro, like EndeavourOS, the /etc/fstab should already contain only “subvol=…” entries, so the above command is not required.

Install the following two packages with an AUR helper (e.g., “yay” in my case). The first one is a meta-package that will install snapper and other utilities like “snap-pac” (“Pacman hooks that use snapper to create pre/post btrfs snapshots when installing/upgrading/removing packages”) and “grub-btrfs” (the default configuration of grub-btrfs works already with snapshots created by snapper).

If you haven’t previously uninstalled timeshift and timeshift-autosnap, you’ll get this message, as I mentioned above:

During the installation of the above two packages, we can see a few interesting things in the log:

The installation creates a configuration for snapper for the root subvolume and configures the service to automatically update the grub menu for booting snapshots. It also creates the very first snapshot, “1”. Since we then install btrfs-assistant, it also creates a “pre” snapshot, “2”, and when the installation of btrfs-assistant finishes, it creates a “post” snapshot, “3”.

Let’s run btrfs-assistant:

Let’s explore its tabs:

Note the existing subvolumes and the newly created subvolume for snapshots “.snapshots”.

The next tab shows the snapshots taken during the installation command we issued to install the programs. Note the numbers of the snapshots and compare them with the installation log shown above. Moreounlike from “timeshift-autosnap”, “snap-pac” creates meaningful and comprehensible names for the snapshots.

Note that you act on a single configuration in this and in the next tab. By default, we have the one created during the installation for the root subvolume (see the “Select config” drop-down menu). If you have other configurations (e.g., for snapshots of the home subvolume), you must select the intended configuration.

With the first tab, you can create/delete snapshots. With the second tab, you can browse them or restore them:

On the last tab, you can see the enabled services and possibly perform further configuration. For the moment, I’m not touching that part: I’m OK without automatic snapshots (since I know they will be taken when installing/upgrading/removing commands) and with the automatic cleanup of old snapshots:

From btrfs-assistant, you can also select the checkbox to show existing Timeshift snapshots:

You might want to remove them once you’re sure the new setup with snapper and grub-btrfs works correctly.

Let’s do some experiments browsing the current snapshots. For example, let’s select the second one and click “Browse”:

Navigating to “/usr/bin,” we can verify that “btrfs-assistant” is not there. In fact, snapshot “2” was taken before installing btrfs-assistant.

Let’s browse snapshot “3”:

This time, “btrfs-assistant” is present in “/usr/bin”. In fact, snapshot “3” was taken after the installation of btrfs-assistant (it’s a “post” snapshot).

From the screenshots above, we can see that snapshots are also browsable from the file system: they are all inside “/.snapshots” (for the root subvolume configuration), each one with the corresponding number. You must be root to browse them.

Let’s experiment with booting snapshots from grub.

Before installing snapper and the other programs, I had previously installed “neofetch” on this machine. I’m going to remove it:

Two new snapshots have been automatically created by “snap-pac” (one before the removal and one afterward):

Let’s reboot the machine and navigate through the snapshots menus, selecting the snapshot corresponding to the state before the removal of neofetch:

Now, we’re inside that snapshot, and we can verify that neofetch is still there:

Let’s say that we want to restore this snapshot for good. Let’s run btrfs-assistant, select the snapshot we have just booted, and press “Restore”:

We get a confirmation dialog, and we can specify a name for the backup that will be taken (in this example, I’ll specify “before-restoring”):

Upon confirmation, we get a warning that urges us to reboot as soon as possible:

Let’s reboot. This time we select the default grub menu entry (not a snapshot).

We can verify once again that neofetch is still there.

From btrfs-assistant, we can see the subvolume with the backup, which we can delete once we’re sure that everything is still working:

If you are using “plocate” or “locate” (see also my older post about locate and BTRFS), you should also exclude “.snapshots” to “PRUNENAMES” (this should already contain some directories like “.git .hg .svn”:

And add “.snapshots” to “PRUNENAMES”, e.g.,

Configuration files are in the directory “/etc/snapper/configs/“. Currently, we have only one configuration, “root” (for the root subvolume), created during the installation.

In that file, we can see the line

corresponding to the setting in btrfs-assistant that disables the automatic timeline snapshots.

Moreover, we have the following:

which again corresponds to the setting in the btrfs-assistant screenshot shown above.

For further configurations, I suggest looking at Snapper’s great Arch wiki page.

To summarize, snapper with these additional programs looks nice and is more flexible than Timeshift and timeshift-autosnap.

You might want to give it a try! As usual, you might start with a virtual machine 😉

Using Dropbox on a PineBook Pro with Maestral

Leave a reply

Dropbox does not provide a client for the Linux Arm architecture, so you don’t have a client for a PineBook Pro.

However, you can use the open-source project Maestral:

Maestral is a lightweight Dropbox client for macOS and Linux. It provides powerful command line tools, supports gitignore patterns to exclude local files from syncing and allows syncing multiple Dropbox accounts.

The Arch AUR repository provides packages for Maestral:

So I’m going to install the “Qt interface for Maestral” with the “yay” AUR helper I already have on my PineBook Pro (this will install a lot of python packages, and the installation will take a few minutes):

Let’s run maestral GUI from the command line:

And the app appears:

Let’s click on the button to link to the Dropbox Account

And click on “here” to retrieve the authorization token. This should open the browser; alternatively, you’ll be asked to select an application to open the full URL in KDE. Unfortunately, selecting a browser in KDE does not work, and it will keep asking for the application.

Thus, in KDE, I run from the command line:

This allows me to print the auth URL to the console, copy it and paste it into a browser. I can then authorize Maestral on the Dropbox site.

The Dropbox website then shows me a token that I copy and paste on the Maestral window above and press “Link”. (The other run command, “maestral auth link,” can be interrupted.)

The setup proposes to select a local folder to synchronize with Dropbox. Note that by default, it proposes “Dropbox (Maestral)”, but I prefer the standard one “Dropbox”, so I modify it accordingly.

And now, it’s time to select the folders to synchronize. I start with a very minimal subset of my Dropbox folders. As noted below, the initial synchronization will take a lot of time (depending on the size of all the Dropbox contents, not the folders you select).

In the taskbar, you can see the Maestral icon that started to synchronize. The icon provides a context menu.

From the command line, you can see the status of the synchronization with

The first run takes much time, especially for the initial “Indexing”. That’s due to a known issue, https://github.com/samschott/maestral/issues/832:

It does index the entire Dropbox, even if only a few items are selected in Selective Sync.

For example, my Dropbox usage is

It took more than an hour just for “indexing”.

I guess that for the time being, we’ll have to accept that if we want to use Dropbox on the PineBook Pro.

Exa and icon fonts in Arch Linux

Leave a reply

I finally took the time to try exa, “a modern replacement for ls”.

This is a brief article for installing exa in Arch Linux with an additional package for the icon fonts (in a few installations, boxes were shown instead of icons, that’s why I’m writing this blog article, hoping to save you some time).

Installing exa in Arch is just a matter of running:

However, you need a “Nerd” font to get the icon symbols. This is the one I install:

In EndeavourOS KDE, this should already be installed. I seem to understand that this is not the case for EndeavourOS GNOME. If these fonts are not installed, you can install them with the command above and make sure to reboot.

The output is excellent, and I aliased many of my previous ls commands to exa:

This is the beautiful colored output you get, and note the icons for directories and known files types in Gnome (in particular, a “cup of coffee” for Java files):

The same holds for KDE:

I also have another alias for the tree output of exa:

And this is the output:

Note the “–git-ignore” command line argument to ask exa to skip all the files that match the patterns in the current “.gitignore” file.

Beautiful, isn’t it? 🙂

Network Printers Discovery in Arch Linux

2 Replies

In Arch Linux (and Arch-based distros like EndeavourOS), it’s easy to add a network printer if you already know its address. Still, network printer discovery does not work out of the box as it happens on other distributions like Fedora or Ubuntu.

The procedure to enable network printer discovery is, of course, documented in the Arch wiki. Still, in this post, I’d like to detail the steps to achieve that just as a confirmation or as additional help documentation.

First of all, let’s install the packages for printing:

I also install the following packages for drivers and HP (because I have HP printers):

Of course, we must enable the CUPS service

We must also make sure the following packages (“avahi” and “nss-mdns”) are installed:

And that the “avahi-daemon.service” is running and enabled:

Then, we must edit the file “/etc/nsswitch.conf” and change the line

into

Now, we should be able to discover local network printers.

I prefer the “system-config-printer” package for this purpose (in case you want to install it).

You can run it by searching for the application “Print Settings”. I’m showing an example in KDE:

“Unlock” by providing the password, press “Add,” and expand the “Network Printer”. If you have a firewall, like “firewalld”, you’ll be asked again for the password to change the firewall settings to enable the services for printer discovery:

Of course, you have to accept to adjust the firewall.

Then, the local network printer(s) should be discovered. In my example, my HP printer is discovered with the possible network protocols:

I chose the second one (the one with the local IP address) and HPLIP as the connection protocol (remember I had already installed the corresponding packages):

By pressing “Forward”, you wait for the drivers to be selected. You can print a “test page” and configure the printer as you see fit.

Ansible, Molecule, Docker and GitHub Actions

Leave a reply

UPDATES:

  • 19 February 2023: exclude ansible-lint problems on tests/test.yml
  • 27 April 2023: updated the molecule docker plugin

Last year, I got familiar with Ansible, the automation platform I now use to install and configure my Linux installations. I must thank Jeff Geerling and his excellent book “Ansible for DevOps“, which I highly recommend!

I have already started blogging about Ansible and its testing framework, Molecule. However, in the first blog post, I used Ansible and Molecule to demonstrate Gitpod with a minimal example.

In this blog post, I’d like to document the use of Ansible and Molecule with a slightly more advanced example and how to test an Ansible role against 3 main Linux distributions, Fedora, Ubuntu, and Arch. To test the Ansible role, we will use Molecule and Docker. Finally, I’ll show how to implement a continuous integration process with GitHub Actions. The example consists of a role for installing zsh, setting it as the user’s default shell, and creating an initial “.zshrc” file. It will be a long post because it will be step-by-step.

The source code used in this tutorial can be found here: https://github.com/LorenzoBettini/ansible-role-zsh. The GitHub repository is configured to be used with Gitpod (see my other blog post concerning using the online IDE Gitpod).

Install ansible and molecule

I’m assuming Docker, Python, and Pip are already installed.

First, let’s install Ansible and Molecule (with Docker support). We’ll use pip to install these tools. This method works on all distributions since it’s independent of the ansible and molecule packages provided by the distribution (Ubuntu does not even provide a package for molecule):

This will install ansible and molecule in “$HOME/.local/bin,” so this path must be in your PATH (it should already be the case in most distributions).

Create the role

This is the command to initialize a role with the directories and files also for molecule (with docker):

In this example, I’ll run:

This is the resulting directory structure of the created project (note that, at the time of writing, the official guide, https://molecule.readthedocs.io/en/latest/getting-started.html, is not updated with the directory and file structure):

What I do next is to enter the directory, remove “.travis.yml” (since we want to build on GitHub Actions), and create a Git repository (with “git init”). I’m also pushing to GitHub.

First, let’s adjust the file meta/main.yml with the information about this role and author:

The role’s name should be the same as the one specified in the “init” command (I don’t know why this file has not been generated with the role_name already set). Otherwise, the other generated files for Molecule will not work.

The role’s main tasks are defined in tasks/main.yml. Currently, the generated file does not execute any task.

Manual tests

The “init” command also created a tests directory to manually and locally test the role. We are interested in automatically testing the role. However, since the role is currently empty, it is safe to try to run it against our own machine. At least, we can check that the syntax of the role is OK, and we can perform a “dry-run” without modifying anything on our machine.

The current contents of the files generated in the “tests” directory will not work out of the box.

First, the tests/test.yml playbook:

Correctly refers to our role, but ansible will not be able to find the role in the default search path (because the role is the project’s path).

We can change the role reference with a relative path (the use of a relative path will require a few configurations to make linting happy, as we will see later):

Then, we can try to run it, checking the syntax and doing a “dry-run”:

The “dry-run” (–check) fails because, on my machine, there’s no SSH server, and by default, the tests/inventory file (specifying “localhost”) would imply an SSH connection:

To avoid SSH, we can change the file as follows:

Let’s try again with the “–check” argument, and now it works.

Run the complete Molecule default scenario

The “init” command created a default Molecule scenario in the file default/molecule.yml:

As we can see from this file, the Docker image used by Molecule is centos:stream8. For the moment, we’ll stick with this image.

Molecule will execute a playbook against a Docker container of this Docker image. We’re implementing a role, not a playbook. The playbook is defined in the file default/converge.yml:

In fact, “converge” is the action of performing the playbook against the Docker image, the “instance”. As you see, the “init” command generated this file automatically based on the role that we created.

There’s also a default/verify.yml file that is used to verify that some expected conditions are true once we run the playbook against the Docker instance. We’ll get back to this file later to write our own assertions. The contents of this generated file are as follows (the assertion is always verified):

To check that the scenario already works, we can run it end-to-end with the command “molecule test” issued from the project’s root. Remember that Molecule will download the Docker image during the first run, which takes time, depending on your Internet connection. This is the simplified output:

As reported in the first line, this is the entire lifecycle sequence:

dependency, lint, cleanup, destroy, syntax, create, prepare, converge, idempotence, side_effect, verify, cleanup, destroy

Thus running the entire scenario always implies starting from scratch, that is, from a brand new Docker container (of course, the pulled image will be reused). Note that after “converge,” the scenario checks “idempotence,” which is a desired property of Ansible roles and playbooks. After verification, the Docker instance is also destroyed. Of course, if any of these actions fail, the lifecycle stops with failure.

Setup the CI on GitHub Actions

Our role doesn’t do anything yet, but we verified that we could run the complete Molecule scenario. Before going on, let’s set up the GitHub Actions CI workflow. We’ll use the Ubuntu runner, where Docker and Python are already installed. We’ll have first to install ansible and molecule with pip, and then we run the “molecule test”.

Concerning the pip installation step, I created the file pip/requirements.txt in the project with these contents (they correspond to the pip packages we installed on our machine):

Then, I create the file .github/workflows/molecule-ci.yml with these contents:

Now that our CI is in place, GitHub Actions will run the complete Molecule test scenario at each pushed commit. The environment variables at the end of the file will allow for colors in the GitHub Actions build output:

Familiarize with Molecule commands

While implementing our role, we could run single Molecule commands instead of the whole scenario (which, in any case, will be executed by the CI).

With “molecule create,” we create the Docker instance. Unless we run “molecule destroy” (which is executed by the entire scenario at the beginning), the Docker container will stay on our machine. Once the instance is created, you can enter the container with “molecule login“. This is useful to inspect the state of the container after running the playbook (with “molecule converge“) or to run a few commands before writing the tasks for our role:

The “login” command is more straightforward than running a “docker” command to enter the container (you don’t need to know its name). Remember that unless you run “molecule destroy,” you’ll find the same state if you exit the container and back in.

Once you run “molecule converge“, you can run “molecule verify” to check that the assertions hold.

To get rid of the instance, just run “molecule destroy“.

Let’s start implementing our role’s tasks

To start experimenting with Molecule for testing Ansible roles, the official Fedora Docker image is probably the easiest. In fact, such an image comes with “python” already installed (and that’s required to run Ansible playbooks). Moreover, it also contains “sudo”, another command typically used in Ansible tasks (when using “become: yes”).

Thus, let’s change the image in the file default/molecule.yml:

You can commit, push, and let GitHub Actions verify that everything is still OK.

Now it’s time to edit the primary role’s file, tasks/main.yml. Let’s add the task to install ZSH. In this example, I’m using “ansible.builtin.package module – Generic OS package manager” so that we are independent of the target OS. This is useful later because we want to test our role against different Linux distributions. This Ansible module is less powerful than the specific package manager modules, but for our goals, it is sufficient. Moreover, in the Linux distributions that we’ll test, the name of the package for ZSH is always the same, “zsh”.

If we had already created the instance, we first need to run “molecule destroy” to avoid errors due to the previous Docker container.

Let’s run “molecule converge“. If you don’t have the “fedora:36” Docker image already in your cache, this command will take some time the first time. Moreover, also the task of installing the “zsh” package might take some time since the package must be downloaded from the Internet, not to mention that dnf is not the fastest package manager on earth. In fact, the Ansible package module will use the distribution package manager, that is, dnf in Fedora. Here’s the output:

Let’s enter the container with “molecule login“. Now, zsh should be installed in the container:

Of course, you could always run the entire “molecule test,” but that takes more time, and for the moment, we don’t have anything to verify yet. The idempotency of the Anslibe package module implies Idempotency.

Change the user’s shell and verify it

Now, we want to change the user’s shell to zsh, and we will verify it. Let’s follow a Test-Driven Development approach, which I’m a big fan of. We first write the verification tasks in verify.yml, make sure that “molecule verify” fails, and then implement the task in our role to make the test succeed.

First, how to get the user’s shell? In the Docker container, the $SHELL environment variable is not necessarily set, so we directly inspect the contents of the file “/etc/passwd” and some shell commands to get the user’s current shell. To write the shell commands, we can enter the container (molecule login), assuming we have already created the instance, and perform some experiments there. Remember that when we’re inside the container, we are “root”, so in our experiments, we’ll try to get the root’s shell.

So, we have our shell piped command to get the root’s shell:

In verify.yml, we want to get the shell of the user executing Ansible. In our molecule tests, it will be root, but the user will be different in the general use case. Thus, we use Ansible’s fact “ansible_user_id”:

Then, we’ll compare it against the desired value, NOT “/bin/bash”, but “/bin/zsh”. Note that, by default, the generated molecule/verify.yml has “gather_facts: false”. We need to remove or set that line to true so that Ansible populates the variable with the current user. Here are the contents (we must use the module “shell” and not “command” because we need the “|”):

Since we have already created the instance and converged that, let’s run “molecule verify“:

As expected, it fails.

Let’s add the task in our role to set the current user’s shell to zsh (we rely on the Ansible user module):

Let’s run “molecule converge” (since we had already converged before adding this task, the installation of zsh does not change anything):