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.

A first look at XeroLinux

It’s been a long time since I wanted to test this Arch-based Linux distribution, XeroLinux. Finally, I found some time, and I first tested it in VirtualBox, and then I also installed that on one of my laptops.

What XeroLinux is about is summarized on its home page:

A Hobbyist Arch-Based Distro, built using ArcoLinux’s ALCI scripts that is meant to provide you with a stable base, making it simpler to install ArchLinux (Calamares) with a well optimized & Customized KDE Plasma, that you can shape YOUR way, the easy way… !

It’s an Arch-based distribution (not like Manjaro): it’s basically Arch with a few additional repositories that are mainly devoted to one of the main exciting features of XeroLinux, that is, a beautiful (good looking) KDE customized experience. And, although the “beauty is in the eye of the beholder”, XeroLinux KDE DE is indeed amazingly beautiful.

In this (long) post, I will summarize my overall experience of XeroLinux, starting from the installation to daily usage. Maybe it’s because I’m used to Arch, but I really like it!


The installation process starts, as usual, with a Live ISO. One of the fun things is that when you boot the Live image, the GRUB countdown emits a beep every second 🙂

When you get to the live environment, you can already understand the beauty of the KDE customizations (dock, global menus, blurring, etc.)

You’re then greeted by the XeroLinux Hello program:

If on a virtual machine, you can use one of the two buttons to fix the screen resolution. In general, you might want to “Update Arch Mirrorlist” right away. Then, just “Launch installer”.

The installer is based on the good old Calamares. If you’re already familiar with that, it will be easy! If not, it will not be that hard since the installer will ask you only the basic questions and will install all the default packages without further intervention.

Of course, the “Partitions” section is the critical one.

You probably wipe the whole (virtual) disk in a virtual machine. As usual, you can select a swap partition with hibernate. XeroLinux defaults to XFS, but I prefer BTRFS, which I’ve selected in my installations. As we’ll see later, the default layout of BTRFS subvolumes created by XeroLinux is also good!

When installed on my laptop, where I have several Linux installations, I chose the manual partitioning and manually created a new BTRFS partition while mounting another shared data partition. As usual, if you have an existing EFI partition, you must manually mount it in “/boot/efi”:

After reviewing the summary, it’s time to start the installation:

Do you see that green button on the bottom right? Click it, and you can see the log of the installer:

When the installation finishes, you get a message that the installation log can be found in the installed system:

The name of the LOG file is wrong. I opened a PR, In any case, finding the LOG file in the /var/log directory in the installed system is easy.

Note: the first time I tried the installer on a virtual machine, Calamares crashed:

I had to start from scratch. The next time, I updated the mirrors before starting the installation, and the installation went fine. I can’t tell what went wrong the very first time.

The installed system

Let’s start with the impressions about the installed system.

The BTRFS subvolume layout looks good to me, or at least, that’s how I create the subvolumes myself in other distributions:

where, besides the standard @ and @home, we have @log, @tmp and @cache that correspond to the directories in /var, @root is for the /root folder, and @srv for /srv.

These are the mount options of the BTRFS subvolumes (in the /etc/fstab file):

I don’t like the “discard=async” in the file /etc/fstab. Since fstrim is enabled once a week, I prefer not to have “discard=async” so I edited /etc/fstab accordingly. From what I know, the “ssd” should not be necessary since BTRFS should recognize that it’s using an SSD. However, it shouldn’t harm.

Another thing I don’t like is that the journald log is not persisted on reboots. I reported that on the forum, Apparently, that’s not intended. I can fix this by editing /etc/systemd/journald.conf and changing the line

to the default (you could simply remove the line, but I prefer to comment it to remember that the default is “auto”):

Moreover, I had to delete the file /etc/systemd/journald.conf.d/volatile-storage.conf (which also contains the “Storage=volatile”). Reboot, and now the log stays there even after rebooting.

The home page mentions, “This distro is 90% ArchLinux & 10% custom.” Indeed, these are the additional packages Besides a few pre-compiled packages (instead of the source versions of the same packages in the AUR repository), there are many packages about theming. I’d tend to say that XeroLinux is “very” Arch, and I like that.

The installed KDE

As I had already anticipated, the KDE desktop environment, customized by XeroLinux, looks really good. It uses many parts from the Lyan theme and Tela icons (I had already blogged about that), however, for the “Application Style”, it uses Lightly instead of Kvantum (as shown in the XeroLinux site and videos, you can easily switch to different themes, actually “rices”, provided by XeroLinux itself). I was already a fan of Lyan and Tela, so I liked the outcome.

You find a dock at the bottom, which is a Latte dock. (By the way, by default, the Latte dock is set to “Dodge Maximized”, which is not ideal for me: I prefer “Dodge Active”.) Also, the top panel is not a standard panel: it’s, again, a Latte panel. They are both transparent (blurred), and you have a global menu, a la macOS. I’m not a big fan of the global menu, but I’ll try to stick with that for the time being. There are a few useful widgets: in the bottom dock, you have the CPU usage, and in the top panel, you have the network usage.

For KDE applications, you don’t need to go to the menu if you use the shortcut “Ctrl + Alt + I,” which opens a global search on the menus of that application (the so-called HUD). For example, here’s the HUD for Dolphin:

Speaking of KDE Desktop effects, you have several effects enabled by default: “Slide back”, “Wobby Windows”, etc. Not the “Magic Lamp” effect, which is one of my favorites, but enabling that is easy.

Moreover, you get “blurred” in most places. It’s eye candy, and I like it 🙂 In that respect, as mentioned on the XeroLinux site, you need a powerful computer to deal with all these effects. On my Dell XPS 13, everything is smooth. Moreover, I don’t see such effects impacting power consumption when on battery.

Look at the blurred effect on the custom Konsole profile (which is set as the default one):

And what about the cool “ls” output? Well, that’s because “ls” is automatically aliased to exa, a modern replacement for ls.

Here are the blurred menus:

Lightly also can blur the Dolphin view, which is enabled by default. Unfortunately, since I’m using fractional scaling, that does not work.

By the way, Dolphin is already configured with the Dropbox plugin enabled. As soon as you install Dropbox, you have overlay decorations on the Dropbox folder.

Moreover, also the KDE drop-down terminal, Yakuake, is already configured and ready to use with F12.

Speaking of searching, the custom “Application Menu” separates search results (files, i.e., “Desktop search”, “Settings”, “Applications”, etc.):

A thing that gave me a few headaches with Kalendar and Korganizer (e.g., for accessing Google Calendar accounts) is that the KWallet subsystem is DISABLED by default (that’s one intentionally). As a consequence, I wasn’t able to access any Google calendar without any feedback. However, it’s just a matter of enabling the KWallet subsystem. By the way, I have no problem with the KWallet subsystem enabled, despite what was described in the XeroLinux forum as the motivation for disabling the KWallet subsystem.

XeroLinux specific features

The Xero Hello program is also very useful! It provides several menus

The “Install Drivers”:

I particularly like the “Post-Install System Configuration”:

For example, it has a menu for switching the shell from BASH to ZSH with Oh My Zsh (including a few common plugins, e.g., completions, suggestions, and source highlight, not to mention the beautiful Powerlevel10k theme). It takes care of cloning Oh My Zsh, and its plugins and sets the shell for the current user:

Speaking of beauty, XeroLinux comes with a very good set of good-looking wallpapers! (see

The “Update System Now” is also very powerful. It gives you a choice to update Everything (by relying on Topgrade): not only Pacman, AUR, and Flatpak packages but also fuwpd, Oh My Zsh and its plugins (if you installed that), and Docker images (if you have installed Docker).

Final thoughts

I like XeroLinux, and I like its BEAUTIFUL theming! It makes me want to use KDE again 🙂

Most of all, I think it is similar to EndeavourOS, which I also like: it’s basically Arch (not like Manjaro, which I evaluated in the past, but which somehow twisted Arch) with interesting customizations.

Developing Ansible roles on a PineBook Pro with Gitpod

In a previous post, I showed an example of an Ansible role tested with Molecule and Docker using the Gitpod development environment. With such an approach, you develop using Visual Studio code on your browser. Resources and computational power is provided by Gitpod, not by your computer. When your computer is a PineBook Pro, an arm-based laptop with low computational power and just 4 Gb of RAM, using Gitpod makes the difference. Though I guess it’s possible to install Docker on the PineBook Pro, I doubt it’s feasible to efficiently use it for testing Ansible roles with Molecule and Docker.

But with Gitpod, it can be done! Here’s my Firefox browser on a PineBook Pro with an open Gitpod workspace:

I can quickly develop and run Molecule tests or manually enter the Docker containers after running Ansible playbooks on them!

I doubt developong and testing such things completely on a PineBook Pro would be this comfortable and efficient! 🙂

The Overview effect got better in KDE 5.26

I’ve updated KDE to version 5.26, which arrived in Linux Arch. In particular, I’m testing this new version in my XeroLinux installation.

One of the improvements that caught me immediately was how this version’s Overview effect has improved!

In the previous version (KDE 5.25), the Overview allowed to search both in applications and in currently opened windows (besides providing search results for other things such as files, folders, and other options configured in “Plasma Search”). However, opened windows and other search results were all mixed in the dropdown list. Although opened windows were reported slightly different from other results, they were all together. Moreover, open windows were not shown after you started typing in the filter text box. On the contrary, I would have liked some visual filtering for open windows, like in the “Present Windows” effect. For this reason, I was using “Present Windows” most of the time for searching for open windows and KRunner for everything else.

This behavior has changed now: the Overview behaves just like I would have liked. If what you typed in the search text box matches any open windows (name of the application or title of a window), the open windows are filtered, and no other search results are shown. On the contrary, if what you typed in the search text box does not match any open windows, you get the other results! Well done! 🙂

Here are a few screenshots demonstrating this new behavior (I opened a few applications and Firefox on a page containing “KDE” in the title).

This screenshot shows the Overview effect when invoked:

If I press “k”, only Kate, Konsole, and Firefox windows are shown (remember, Firefox has “KDE” in the title):

If I enter “ka”, only Kate is shown:

If I enter “ko”, only the two Konsole windows are shown:

If I enter “kd” or “fi”, then only Firefox is shown:

If I enter “chr”, then since “No matching windows” are found, I get the standard search results:

I hope this behavior of the Overview effect won’t change in future versions because I like it, and, IMHO, that’s how it should be 🙂

Note: as it happened in the past, the Overview effect sometimes crashes when you select a window or something from the search results. As a result, kwin restarts automatically. Sometimes, after an update, this is fixed. Sometimes, the bug shows up again.

As a comparison, this is the old behavior of the Overview. Here’s a screenshot with two applications opened, including a Konsole window:

If I start typing “kon”, I get the full list of search results:

It is true that the open window of Konsole is the first result, but I find this old behavior harder to use: it’s harder to spot the open window.

An Ansible role tested with Molecule in Gitpod

I’m mainly a Java developer and still haven’t found a way to use Gitpod for Java development. Gitpod allows you to spin up fresh development environments from your GitHub projects so that you can code with Visual Studio on the web (that’s just a very reductive definition, so you may want to look at its website for the complete set of features). I honestly prefer to have my IDE (Eclipse) on my computer.

However, I probably found a use case for Gitpod that’s also good for me! I recently started playing and having fun with Ansible to automate all my Linux installations. I’m also test-addicted and want to test my Ansible playbooks and roles automatically. For testing Ansible playbooks and roles, I use the mainstream technology Molecule. Molecule allows you to thoroughly test Ansible tasks by running them against a Docker container. (I’ll blog about my Ansible playbooks, roles, and how I use Molecule shortly.)

Once you have Docker installed on your system, setting up Ansible and Molecule is not hard. However, due to the used technologies, running Molecule tests stresses your computer a bit due to disk usage (because of Docker images and containers; also because Molecule allows you to test Ansible tasks against different Docker images) and due to computational power. Indeed, it would be best if you had a powerful computer to use Molecule. I don’t always have one with such computation power with me; if I have, I might need that with some concurrent development tasks.

That gave me a chance to evaluate Gitpod for the task of testing an Ansible role with Molecule on Gitpod. In this blog post, I’ll detail, step by step, how I set up my Gitpod development environment for this job. The Ansible role used in this example is trivial and is not the post’s goal.

On my computer, I install Ansible and Molecule (with Docker support) with the following pip command:

Then I create an Ansible role ready to be tested with Molecule as follows:

I created a Git repository and pushed that to GitHub:

To access Gitpod easily from a GitHub repository, I installed the Gitpod browser extension.

Now, I can start Gitpod for this repository using the button (as I said, you need to use a browser extension; otherwise, you have to prefix the URL appropriately):

Let’s press the “Gitpod” button. The first time you use Gitpod, you’ll have to accept a few authorizations.

NOTE: in this blog post, I’m using the light theme of Visual Studio in Gitpod.

Once the Visual Studio code was open in the browser, I was welcomed by a “Get Started with Gitpod”:

First, let’s set up the main developer tools in the Gitpod workspace (a Linux OS): Ansible and Molecule. We’ll install them using Python Pip (as I’ve done on my local machine), which is already available in Gitpod.

In the Visual Studio terminal, I run:

The above command will take about a minute to terminate (we’ll get back to this later)

Then, we can verify that molecule (and ansible) are installed:

Now we can run Molecule from within the Gitpod workspace. We can try and run “molecule converge” (though our Ansible role doesn’t do anything at the moment). After that, we can enter the container with “molecule login” (from the generated molecule/default/molecule.yml file, we can see that it’s based on the Docker image ““):

Instead of running “converge”, we can let Molecule create the Docker image with “molecule create“. We would still be able to enter the Docker image as above.

Let’s stop the workspace:

(To close a workspace, we could close the workspace browser tabs: within three minutes, the workspaces will be stopped.)

If we get back to Gitpod and create a new workspace (that is, we don’t use the Gitpod dashboard to restart the workspace we have just stopped), we will lose the installed programs ansible and molecule. Let’s make the installation of these tools permanent, so we’ll find them each time we start a Gitpod workspace for this GitHub project.

To do that, let’s run “gp init“. This command will create a new .gitpod.yml file (with some example contents; see the documentation for more details about this file) where we can configure the workspace for our project. This configuration will be stored in the git repository of this project. Once this file is in place, Gitpod will pre-configure our workspace each time we enter Gitpod for the current project.

I’m changing the file as follows:

As written in the documentation:

To test your .gitpod.yml file, you need to commit and push the file to your repository and open a new workspace either by using the Gitpod extension or prefixing your repo URL with

If you don’t want to have multiple commits as you’re testing and making changes to your .gitpod.yml, you can make changes from a new branch.

For the moment, let’s commit and push directly to the master or main branch (of course, by using Visual Studio):

Let’s stop the workspace and get back to Gitpod. We will see the output of our “init” command, and Ansible and Molecule will be available.

However, from what I understand, for installing programs that are indispensable during development, instead of using an “init” task, it’s better to provide a custom Docker image with the programs already installed.

To do that, we add this section to the .gitpod.yml file:

Then, we create the file .gitpod.Dockerfile. As soon as the file is created and opened, Visual Studio suggests we install the Docker extension in Visual Studio:

Let’s choose “Install Do not Sync”. Once the extension has been installed, we can use the gear icon and specify to add the extension to the .gitpod.yml file:

The file will be automatically modified with the following new section:

This way, each time we open the workspace of the project or someone else does (e.g., for contributing), the Docker extension will be automatically available.

Let’s implement the Dockerfile by starting from the full Gitpod workspace image (the one we have used so far because it’s the default image) and by installing Ansible and Molecule in the Docker image:

Note: Gitpod suggests using a specific tag instead of “latest” to help the reproducibility of the workspace. For this simple example, we’ll simply use “latest”.

Now that we have a custom Dockerfile for the image of our Gitpod workspace, instead of stopping the workspace and opening a new one, it might be better first to verify whether we can build such an image (remember, in Gitpod, you have docker available after all):

Then, we can enter that image and verify that our desired programs are installed:

Doing such a check before starting a new workspace lets us immediately spot possible problems with our custom image.

You notice that building the Docker image takes a lot of time. That’s because we started from the full Gitpod base Docker image (a big image), which contains support for several languages. We’ll optimize this later.

We remove the “init” task from the .gitpod.yml file. However, we can use a “before” task specific to this project (the pip packages are typical of Ansible and Molecule projects). We have Molecule create the Docker instance (see the molecule.yml file shown above in the screenshot). This will make the Docker image used in our Molecule tests already pulled when we open the workspace:

To summarize, this is the .gitpod.yml file (note that I also added the Gitlens extension, which is very useful for Git repositories):

We can start a new workspace. Now Gitpod knows about our custom Dockerfile and builds that image for us. In particular, whenever we start Gitpod for this repository, Gitpod checks whether the Dockerfile has been updated and rebuilds the image if needed. Thus, building our custom Docker image will take some time only the first time, and if we change the Dockerfile.

When the workspace start, we’ll see Gitpod building our image:

Similarly to when we built our custom Docker image in the workspace, this will take some time because we start from the vast “workspace-full” image.

Maybe we can do better and start from the Gitpod workspace image that provides only Python support. After all, for this project, that’s all we need (we don’t need Java, C++, etc.):

I also took the chance to update Pip itself. In the previous runs, I had seen such a message:

As done before, let’s first check that the image builds fine locally and that, in the end, it contains our required software.

We can start a new workspace. Gitpod realizes that our Dockerfile has changed and rebuilds it. This time, this should be faster.

It took some time, but now we have an IDE for our project on the web. The files we have created can be reused for similar projects. For projects using different languages, the customization will be different.

We can start implementing the tasks for our role. For example, let’s edit the file tasks/main.yml. In this example, we want to install ZSH:

Let’s save, and run “molecule converge” (remember, the Docker image for our molecule test has already been downloaded during the workspace opening). We’ll get an error:

That’s because “sudo”, which is required by our task (“become: true”), is not installed in the Docker image we use for testing (““). We can prepare our instance with a molecule/default/prepare.yml playbook or use another RedHat-based Docker image, which already comes with “sudo”, e.g., “fedora:36”. For this simple example, I’ll go with the latter solution. We change molecule/default/molecule.yml accordingly:

Since we have now changed the Docker image for Molecule tests, we must first “destroy” the current Molecule image (“molecule destroy“) and then try to “molecule converge” (this time, a new Docker image will be downloaded). Now “converge” should succeed. We can also run a complete Molecule scenario with the command “molecule test” (this will also check idempotency and verify possible assertions; currently, we don’t have any assertions).

We can also add a badge to the README of the GitHub repository to quickly jump to Gitpod. That’s useful for contributors who don’t have the Gitpod extension. The markdown code for the badges can be found at For this project, I add this markdown code to the README file:

You may want to experiment with other Visual Studio extensions like the “Ansible” extension. If you install that, you’ll get a warning of the shape:

That’s because we haven’t installed the command “ansible-lint”. We can do that with Pip. We should also update our custom Docker image accordingly. I will not do that for this simple example, though.

That’s all for now. I hope you found this post useful to get started with Gitpod 🙂

Timeshift and grub-btrfs in Ubuntu

UPDATED 20/Nov/2022, ChangeLog:

  • 20/Nov/2022: documented the new version of grub-btrfs and its new grub-btrfsd daemon; the configuration for Timeshift is much simpler, but you have to install another package: inotify-tools.
  • 17/Nov/2022: documented that I could also create additional subvolumes and move existing contents from the running system

In this post, I’ll describe the same procedure I described in one of my previous posts but applied to Ubuntu (in particular, Ubuntu Jammy 22.04). I’m not describing an autosnap mechanism when performing package updates in Ubuntu, though you might want to try timeshift-autosnap-apt for that.

If you choose the BTRFS filesystem when you install Ubuntu, you get the two subvolumes “@” for “/” and “@home” for “/home”, which will make Timeshift work since that’s what Timeshift expects to find to take BTRFS snapshots.

However, some adjustments are still worth making to avoid useless data ending in the snapshots and to be able to boot snapshots directly (with the help of grub-btrfs).

Adjust compression

Ubuntu does not mount BTRFS subvolumes with compression. Instead, I prefer to have compression on BTRFS.

To do that, right after the installation, I change /etc/fstab by adding compression and “noatime” to the existing entries for “/” and “/home” (as usual, UUID must be replaced with the UUID of your disk partition):

Save the file, reboot, and perform “defragment” so that the existing data gets compressed:

It’s also best to create /var/lib/portables and /var/lib/machines if not already there

I’m not using these directories, but it looks like systemd creates them automatically as nested subvolumes. Nested subvolumes will force you to do some manual removal after restoring a snapshot and removing old snapshots.

The current situation of subvolumes should be as follows:

Create additional subvolumes

With the current subvolume layout, things like logs and caches will end up in snapshots, giving you problems when you try to boot a snapshot (which we want to be able to do).

Creating a subvolume for the whole /var directory is not ideal because we lost the contents of essential things like /var/lib in the snapshot, so we could not restore a snapshot correctly. Instead, we create subvolumes to mount /var/log, /var/cache, and /var/tmp.

Since we have to move the existing contents of such directories into the new subvolume, it’s better to operate from a Live ISO.

UPDATE 17/Nov/2022: I also tried to create the new subvolumes and move the existing contents in the running system, following the steps described below. It worked! However, I’d still suggest you do the next steps from a Live ISO because you never know 😉

So, let’s boot a Live ISO (e.g., Ubuntu live installation medium).

Switch to superuser (no password required in the live media):

Mount the BTRFS filesystem into /mnt, which should already exist in the live media. We have to mount the partition hosting our existing installation. In my example, it is /dev/sdb10:

You should see the existing subvolumes in the mount directory:

Create the new subvolumes

Here are the new subvolumes:

Let’s move the contents of /mnt/@/var/log to /mnt/@log and the same for /mnt/@/var/cache into /mnt/@cache

The directory /mnt/@/var/tmp/ should be empty, so there’s nothing to move (you may want to check that).

Adjust the fstab of the installed system to point to the renamed subvolumes and mount the new subvolumes as /var/log, /var/cache, and /var/tmp

You will have to use the correct UUID, which is the same as the one for the already mounted volumes (when you copy and paste, make sure you update both the mount point and the subvolume name consistently):

Remember to double-check everything!

Let’s unmount the partition

and we should be able to reboot the system, hopefully without problems

Install Timeshift

We can install it from the Ubuntu repositories with

NOTE: since this is not the latest version, Timeshift will always generate snapshots in the same directory, so there’s no need for the additional fixed mount point as in Arch (see my previous post).

Let’s create a new Timeshift snapshot and browse it with the Timeshift toolbar button “Browse”. We can verify that the directories @/var/log, @/var/cache, and @/var/tmp are empty in the snapshot. The same holds for home (but that was already true thanks to the initial subvolume for home).

Configure grub-btrfs

We have to install grub-btrfs from sources because there’s no official package for Ubuntu. However, after installing the dependencies,

the installation procedure is straightforward:

We now need to configure that to monitor the Timeshift snapshot directory instead of the default one (/.snapshots).

Updated version (20 November 2022)

UPDATE 20/Nov/2022: A new version of grub-btrfsd is available only by installing from sources. What follows is based on this new version. At the bottom of the post, there are still the old instructions, but they’re not valid anymore.

If you see an ASCII splash screen installing grub-btrfs from sources, you’re using the latest version.

Now, let’s make sure grub-btrfs can find Timeshift’s snapshots (remember, we’ve just created one). So let’s run update-grub, and we should see in the end something like the following output:

The last lines prove that grub-btrfs can detect snapshots.

Automatically update the grub menu upon snapshot creation or deletion (20 November 2022)

UPDATE 20/Nov/2022: A new version of grub-btrfsd is available only by installing from sources. What follows is based on this new version. At the bottom of the post, there are still the old instructions, but they’re not valid anymore.

Grub-btrfs provides a daemon watching the snapshot directory and updates the grub menu automatically every time a snapshot is created or deleted.

Important: This daemon requires an additional package:

By default, this daemon watches the directory “/.snapshots” (the default directory for Snapper). Since Timeshift uses a different directory, we have to tweak the configuration for the daemon.

Let’s run:

We must change the line


This is required for Timeshift version 22.06 and later because Timeshift creates a new directory named after their process ID in /run/timeshift every time they are started. Since the PID will be different every time, also the directory will be different. Grub-btrfs provides the command line argument –timeshift-auto to correctly detect the current snapshot directory (In previous versions of grub-btrfs, we had to tweak /etc/fstab to deal with that).

Let’s start the daemon

In the journalctl log, we should see something like (where the date and time have been stripped off):

Let’s start Timeshift. In the journalctl log, we should see something like this:

Let’s verify that if we create a new snapshot, grub-btrfs automatically updates the GRUB menu: in a terminal window, run “journalctl -f” to look at the log, then create a new snapshot in Timeshift. In the log, you should see something like the following lines:

Similarly, if we delete an existing snapshot, we should see something similar in the log.

Remember that it takes a few seconds for grub-btrfs to recreate the grub menu.

Once we’re sure everything works, we can enable the daemon to always start at boot:

The next time we boot, our grub menu will also show a submenu to boot snapshots.

Concerning doing some experiments booting a snapshot and restoring it, please look at my other post.

Old version (with old release 4.11)

UPDATE 20/Nov/2022: These are the older instructions for the previous version of grub-btrfs, where there was no “grub-btrfsd.service” and there was another systemd program (“grub-btrfs.path”).

I leave these instructions here just for “historical reasons”.

The file contents

should be replaced with

Let’s reload and re-enable the monitoring service:

If we have already created a few snapshots, we can run update-grub and verify that new grub entries are created for the found snapshots:

Let’s verify that if we create (or delete) a snapshot, grub-btrfs automatically updates the GRUB menu: in a terminal window, run “journalctl -f” to look at the log, then create a new snapshot in Timeshift. In the log, you should see something like the following lines (where the date and time have been stripped off):

This output tells you that the grub-btrfs monitoring service works!

The next time we boot, our grub menu will also show a submenu to boot snapshots.

Concerning doing some experiments booting a snapshot and restoring it, please look at my other post.

Taming KDE baloo

Quoting from,

Baloo is the file indexing and file search framework for KDE Plasma, with a focus on providing a very small memory footprint along with extremely fast searching.

Unfortunately, it has a bad reputation for being a resource hog. However, it all boils down to configuring it appropriately (of course, according to your needs), and not only will it be “tamed”, but it will also work fast, using a few resources, and it will be your friend when using KDE.

In this article, I describe how I configure it to be fast and functional without being a resource hog.

I anticipate that I use baloo only for file search, NOT content searching. I don’t think baloo is the best tool under that concern because it updates its index continuously. For content searching, I suggest Recoll. You can configure Recoll to update the index a few times daily, which is typically enough. Moreover, Recoll provides more powerful query mechanisms for content searching than baloo. If you want baloo to index file contents, remember that this requires more resources and time to complete.

First of all, configuring baloo should be the first thing you do after you install KDE and log in to KDE for the first time. At least, it would be best if you disabled it before filling your home folder with all your contents.

Whether baloo is enabled or disabled by default depends on the distribution. Go to System Settings -> Search -> File Search.

In this example, it’s disabled. Let’s check “Enable File Search” and uncheck “Also index file content” (at least, I disable indexing of file contents for the reasons I said above). DON’T PRESS “Apply” yet. Another problem with the default configuration is that it will index all the files in your home folder. That’s probably too much unless you want to search everywhere in your home folder (including temporary files, locally installed binaries, etc.).

In that respect, I prefer to exclude my home folder and provide some subfolders to be indexed. So I use the dropdown menu and exclude my home folder:

Then, I add the folders I want to be indexed with the button “Start indexing a folder…”:

Now, you can hit “Apply”, and after some time, you can see that indexing completes. With an SSD and indexed folders that do not contain many files, it takes baloo just a moment to index the selected folders.

You may also want to learn to use the command balooctl from the terminal to have more control over baloo and retrieve indexing information. For example, here’s an example of the status subcommand and its result on my system after the configuration above and after the indexed directories are filled with my data:

Learning more about baloo configuration to have fine-grained control of its indexing functionality is even better. For example, you can refine the configuration by excluding some files from the specified indexed folders based on their extensions or with regular expressions. As far as I know, you cannot do that from the system setting’s dialog shown above. You have to tweak the configuration file ~/.config/baloofilerc.

The interesting part is “exclude filters=…” where you specify a comma-separated list of regular expression for excluding files or folders. It comes prefilled with some sensible values for exclusions. You can add your own exclusion filters.

After modifying this files, I’d suggest you rebuild the index with this command:

After the index is recreated, many files have been excluded:

You can enjoy baloo file search from the “Search” in the “Application Menu” and from “KRunner” (Alt+space). In that respect, KRunner might take some time before it correctly shows the indexed files after a re-index.

Now, baloo is tamed and you can enjoy its features without losing your resources.

Final thoughts: for you sure, you must make sure things like BTRFS snapshots don’t end in the folders to be indexed, or you will have several problems, including lots of resource usage not to mention duplicate results during the search.

Fixing Docker problems in Fedora

In this post, I’ll describe a few problems with Docker in Fedora and how to fix them. In particular, I’ll try to provide an analysis of the problems and the sources of the solutions.

I’ve experienced a few problems with Docker in Fedora (35 and 36). I first installed docker-ce by following the official documentation: Things went smoothly at the beginning with the first Docker images, e.g., the “hello-world”, “ubuntu,” and a few others.

However, I started to experience severe problems with this image “mysql:5.7”: the container took a lot of time to start, and I noted that Docker immediately ate my whole RAM, 16 Gb. If I don’t terminate the process, the computer will likely hang in a minute or less.

This is a docker-compose file to recreate the problem:

Save it to “docker-compose.yaml” and start it with “docker-compose up” and see the problem.

You must install the package docker-compose from Fedora’s repositories to verify the problem. I anticipate that the problem is not due to docker-compose because I have precisely the same problems with the above Docker image even if I run it without docker-compose (e.g., during a Maven build).

There’s no problem with a more recent version of the MySQL image, e.g., “mysql:8.0.27”. However, there’s something wrong with Docker in Fedora because the same docker-compose file using “mysql:5.7” does not give me any problem and works perfectly in other Linux distributions like Ubuntu and Arch.

I also experienced slow performance and ram draining when running an ansible molecule test with one of my ansible playbooks, e.g., running a flatpak installation in a Docker container. Again, only in Fedora.

I reported here without getting any solution.

Here are the solutions I found myself.

Use moby engine (and tweak its configuration)

Instead of using “docker-ce”, I tried moby-engine (, which provides the same “docker” command line tools. The existing docker-compose works with moby as well. As stated here, moby-engine is the “Fedora’s way” (though the official Docker package is said to work as well).

Surprise! the above docker-compose file works like magic: it starts fast and does not eat RAM. Also, my ansible molecule tests work perfectly.

Unfortunately, you run into problems using the excellent Testcontainers library. This problem is due to SELinux (that figures!!!). You can use this example project (taken from my TDD book): If you have Java and Maven installed, you can clone the repository, enter the directory “,” and run “mvn verify”. When it comes to Testcontainers tests, you get errors of this shape:

If you temporarily disable Selinux:

The Testcontainers tests will succeed.

However, let’s try to fix this problem once and for all.

To understand why moby-engine’s docker command works while docker-ce’s docker does not I inspected the version of the file /usr/lib/systemd/system/docker.service file provided by the moby-engine’s installation and the version provided by docker-ce’s installation.

These are the interesting parts of the docker.service file that comes with the moby-engine package:

While these are the corresponding parts in the version of the file provided by the docker-ce package:

The main differences are:

  • docker-ce uses a simple command to start the Docker daemon
  • moby-engine passes more arguments and relies on additional arguments (the OPTIONS environment variable) read from the additional file /etc/sysconfig/docker, whose contents are listed here:

First, I like this approach of relying on a separate file, which the user can customize. I understand that updates to the moby-engine package will not overwrite this file.

Thus, to avoid the Selinux problem with Testcontainers, it is enough to remove the “–selinux-enabled” argument in the above file. These are the steps:

  • Stop docker, “sudo systemctl stop docker”
  • Modify the file as follows:

  • Restart docker “sudo systemctl daemon reload && sudo systemctl start docker”

Moreover, disabling SELinux in the above file is also required if you, like me, prefer to have the docker directory (by default, it is /var/lib/docker) in another place (e.g., in a standard partition, which is not BTRFS and which is shared among several Linux distributions on the same computer).

Here’s an example of customization of the above file to tell Docker to use a different root directory:

If you use a different root directory with SELinux enabled, you might get errors when running containers of the shape

Fixing docker-ce

By taking inspiration from the configuration of moby-engine, we can also fix docker-ce by tweaking its configuration.

Of course, stop the Docker service (“sudo systemctl stop docker”) before doing the following steps.

It makes no sense to modify the file /usr/lib/systemd/system/docker.service directly because that will be overwritten by docker-ce package updates (I’m sure about that: I’ve seen it).

Instead, we first create the file /etc/sysconfig/docker (which does not exist in docker-ce installation) by removing a few arguments that would not work in docker-ce:

Then, we create another service file to specify the Docker daemon execution command:

And these are the contents of the created file:

Restart docker “sudo systemctl daemon reload && sudo systemctl start docker”. Everything should now work with docker-ce!

Of course, this approach also works with a specified “–data-root” argument, as seen in the moby-engine example.


On a side note, it might be enough to use only a subset of arguments in the docker-ce configuration taken from moby-engine. However, I think I wasted enough time debugging these problems in Fedora, and for the time being, I’m happy with these existing configurations.

I also want to stress my disappointment about how Fedora makes developers’ lives hard in these situations. I decided to debug these Docker problems and find solutions as a challenge. However, my interest in Fedora and my initial appreciation for this distribution significantly decreased. I won’t stop using it shortly, but I will not use it as my daily driver. For that, there’s Arch! 🙂

VirtualBox in Fedora Linux

I have no problem installing VirtualBox and the related tools and extensions in Ubuntu and Arch. In Fedora, things are a little bit harder.

First, I think it’s better NOT to download binaries distributed by VirtualBox: I’m using Fedora packages that are available from RPM Fusion Free. Thus, first of all, you have to enable such a repository.

Then you run

It’s also best to add your user to the VirtualBox group:

And reboot, of course.

Then, to have additional features, you should install the VirtualBox extension pack. That’s where Fedora gets complicated. Differently from Ubuntu (package virtualbox-ext-pack) and Arch (package virtualbox-ext-oracle), you will not find a corresponding package in the RPM Fusion repositories.

You need to download the file from the VirtualBox website manually, You must download a file of the shape Oracle_VM_VirtualBox_Extension_Pack-<VERSION>.vbox-extpack where <VERSION> must match the version of VirtualBox you installed. Then, you install it inside VirtualBox with File => Preferences => Extensions.

If the versions don’t match, you will have trouble starting your virtual machines with errors of the shape:

I experienced such a problem and asked on the Fedora forum.

Then, I realized that VirtualBox had been upgraded during a system update, but I forgot to download and install the updated extension pack. You can see the versions don’t match:

I then downloaded the corresponding file And added it to the “Extensions” preference (selecting “Upgrade”):

That was enough to go back to running my VirtualBox machines.

However, I must admit that the whole procedure for using VirtualBox in Fedora is much more cumbersome and error-prone than in other distributions 🙁 It’s far too easy in Fedora to forget about package upgrades that require manual interventions. In general, I’d like to avoid manual interventions at all 😉

Again woes for KDE and Google Accounts

TL;DR If you want to access your Google Calendars from Korganizer or Kalendar, remember to enable “Enable the KDE wallet subsystem”.

I had already written about the cumbersome procedure to access Google accounts in KDE, and I thought I had learned enough to “easily” set my Google calendars in KDE. I was wrong. Today I tried KDE again (I’m mainly a GNOME user for the moment) in a brand new Arch-based installation. I also decided to try the new calendar application, Kalendar. I managed to add a new calendar by selecting “Google Groupware”:

(By the way, once you selected “Google Groupware”, can you spot any “Add”, “OK”, or any other way to confirm the selection? There’s “Close”, but I’d assume that is for canceling the selection… IIRC, you must double-click on the selection; anyway, that’s odd!)

But then, I couldn’t configure it: I pressed the button “Edit,” and nothing happened!

I mean, no error pop-up. Nothing printed on the console if I ran Kalendar from the command line. Nothing in the journalctl log. NOTHING!

The same happens with Korganizer. The Google Groupware calendar already appeared because Kalendar and Korganizer share the same calendars. The problem is still there: the calendar is not configured and clicking “Modify” led to nothing. No error. NOTHING again!

To cut a long story short: you must enable the wallet subsystem in the KDE system settings:

How could it be possible? In 2022, KDE and its programs cannot cooperate in providing meaningful information when something goes wrong! And in KDE, things often go wrong.

For example, it’s been more than one year since KAddressBook cannot access Google’s address book!

SSH into a VirtualBox machine

I use VirtualBox a lot for testing purposes, mainly to experiment with a Linux distribution (to see whether it’s worthwhile to install it on bare metal) and to test procedures that might involve some complex (and maybe “dangerous”) operations.

After you install VirtualBox Guest Additions, things like bidirectional copy-and-paste will work. Some distributions seem to enable and install such additions right from the start (e.g., Fedora, if I’m not wrong). However, there are many situations where you’re installing a distribution in a VirtualBox machine. If Guest Additions are not already working, you will not be able to copy and paste anything. For example, the ISO of Arch Linux even comes in textual mode only, and it’s helpful to be able to copy and paste commands.

In such situations, I prefer to SSH into the virtual machine from a local terminal: copy and paste will work (since I’m in a local terminal). Moreover, the keyboard layout will be the one of the local system (the host). Thus, the keyboard layout will be already configured correctly. While in the virtual machine, you’d have to configure the keyboard layout. Finally, you can quickly transfer files via SSH between the host and the virtual machine without configuring shared folders.

Before being able to SSH in a virtual machine, you need two things:

  • An SSH server up and running in the virtual machine (how to do that depends on the specific Linux distribution)
  • Configure port forwarding in the virtual machine: for instance, all connections to a specific port on the host will be forwarded to port 22 (the default SSH port) on the virtual machine.

I could do the second operation through the “Settings” of the machine. That requires a few dialogs and filling a few table cells. However, I prefer to do that with a single command from the host. For example, I create and configure a new virtual machine, let’s say with the name “My Machine”. When it is not running, I run from the host:

Then, when I start the virtual machine, assuming the SSH server is configured in the virtual machine, I SSH into the machine through the local port 2522. Of course, you can choose any free port number on your host. For example, assuming there’s a user foo in the virtual machine, I run:

Let’s see a complete example.

Let’s say I create a virtual machine called “Arch Gnome” for installing Arch Linux. I configure it appropriately. In particular, I “insert” the ISO of Arch Linux into the virtual CD ROM drive of the machine. Before starting the machine, I run from the host:

Start the virtual machine:

Inside the live environment of Arch Linux, 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, and if you’re in a trusted local network, you can choose an easy one.

Now, we can connect via SSH to the virtual machine through localhost. If you have already connected via SSH to localhost, you might get an error of the shape:

All you have to do is edit the known_hosts file by removing the offending lines and try again. You will have to remove all the lines that start with “[]:2522”.

Note that we’re using port 2522 because we previously used that for creating the port mapping. Let’s connect to the virtual machine and type the password we have previously specified for the root account inside the virtual machine (Accept the fingerprint, when asked.):

In your local terminal, you see that you get the colors of the virtual machine (now, you’re inside the virtual machine):

The keyboard layout is the one of the host; as usual, you copy and paste the text into the local terminal and run commands in the virtual machine, but more comfortably since you’re in your local terminal. You can also transfer files with “scp”.

For transferring files, you could also configure your file manager to access the “remote” server (the virtual machine) and browse and perform operations on the virtual machine’s file system from your local file manager.

Some benchmarks for building an Eclipse project: Linux, Windows, macOS (M1)

I want to share some benchmarks for building an Eclipse project with Maven/Tycho. I built the project on Linux, Windows, and macOS (in particular, on my Mac Air M1 2020).

I stressed that the macOS environment is an M1, the new Arm-based chip from Apple, which is said to be quite efficient and performant. However, I also used an older Mac Air 2016, so no M1 here.

Concerning Linux and Windows, I used an LG GRAM 16. Both are good machines with powerful processors, 16Gig RAM, and NVMe disk. I ran the same build on a few Linux distributions (Arch, Ubuntu, Fedora) and the results concerning Linux are basically the same.

The Eclipse project is Edelta,, “An Xtext DSL for EMF metamodels refactoring and migration.” It’s quite a complex project with an extensive test suite: unit tests, integration tests (JUnit Plug-in tests), and SWTBot tests. The project also includes a custom Maven plugin, which is also tested. Yes, I’m test-addicted 😉

To avoid the Internet connection influencing the benchmarks, I first run the Maven build once so that Maven downloads and caches all the dependencies. Moreover, I first mirrored the p2 Eclipse artifacts so that the target platform definition is resolved against the local mirror.

LG GRAM 16 (LINUX) Total time: 03:25 min

LG GRAM 16 (WINDOWS) Total time: 04:20 min

MACBOOK AIR M1 Total time: 02:49 min

MACBOOK AIR 2016 Total time: 08:17 min

I must say I was impressed by the best performance shown by the M1 processor!

As expected, on the same machine, Windows performs worse than Linux 🙂

The performance of the old Mac Air is not impressive, but that’s an old machine.

Just for fun, I ran the same build on the PineBook Pro (which runs Manjaro KDE): Total time: 21:27 min. Of course, that’s not usable for intensive development 😉

Finding a type in the classpath of an Eclipse Java project

Recently, I started to contribute and maintain Pitclipse, an Eclipse plugin for running mutation testing with PIT.

We needed a mechanism to detect whether JUnit 5 is in the classpath of a Java project (so that we could run PIT with its JUnit 5 plugin).

The first implementation of such a mechanism was rather cumbersome since it manually inspected the Java project’s classpath entries. Something like that:

That’s rather unclear, and there are lots of paths to test.

I opened an issue for investigating an alternative implementation,, and I was thinking of something simpler, along these lines:

We could try to load some classes of the JUnit 5 engine by constructing a classloader using the classpath of the Java project.
Something like (untested):

That’s simpler and cleaner, but we can do better than that 🙂

JDT provides a lot of API for such things. For what we need to do, we can simply rely on IJavaProject method findType:

IType findType(String fullyQualifiedName)
Returns the first type (excluding secondary types) found following this project’s classpath with the given fully qualified name or null if none is found.

So it’s just a matter of creating a reusable method, e.g.,

And we can simply call it by specifying the fully qualified name of a type that we know belongs to JUnit 5 (PR

Now we don’t even have to test several cases: we simply rely on the correctness of the implementation of findType. This is expected to work on Java projects, Maven projects, Gradle projects, etc.

My notes on the Grub incident in Linux Arch

In this post, I’d like to share my thoughts and the solution I adopted to circumvent the terrible incident that happened a few days ago with grub in Linux Arch. The bug affected all Arch-based distributions (not Manjaro, which is not really Arch-based, but for sure EndeavourOS and Arch itself).

You can find the details of the problem online:

If you’re reading this, you’re already aware of the bug, and maybe you’ve been hit by it. Thus, I’m not going into the details of the issue itself.

First of all, although I’ve been enjoying Arch for some time, I must say I was not pleased with the way the Arch team handled the problem (it’s really a severe issue, and having bootable snapshots does not save you from that if you don’t take countermeasures to avoid it or to fix the problem, once you’ve already been hit). After a few days, the Arch team closed the bug, blaming other Arch-based distros because they have hooks that update the grub configuration during package upgrades. The Arch team says that if you use grub the “Arch way,” you have no problem. However, if I understand the details of the issue correctly, as soon as you have a software update that installs a new kernel version, it will also update the grub configuration, and the bug will hit you. (update: no, that’s not the case in Arch, since the kernel image file always has the same name and does not have the version in the name).

Moreover, I have hooks to take Timeshift snapshots before a system upgrade and to generate grub entries to boot the snapshots. Isn’t this the “Arch way”? For sure, it’s a safety mechanism widely adopted. After all, Linux is about choice! 🙂 (update: since, as said above, the kernel image file name is always the same, even, for example, if you update from version 5.19.4 to 5.19.5, having bootable snapshots is even more crucial in Arch).

The issue is said to be fixed by showing a warning during the upgrade of the grub package saying:

Seriously?! That’s just a warning, which is likely to go unnoticed. That’s not a fix; it’s a patch (In the true sense of the word).

However, let’s say that you note that warning and do what it says.

You will have no problem on the next boot, but I found these huge drawbacks (at least for me):

  • The grub installation of the current Arch distribution will replace the default UEFI boot configuration. Of course, you can reorder the boot configurations from the UEFI setup, but that’s an unwanted side-effect if you had already configured things the way you wanted;
  • Related to the previous point, if you have another grub configuration (e.g., of another distro) to boot other distros on the same machine (see, e.g., my blog post on this mechanism), including this Arch installation, it will not work anymore. That’s expected because the other grub does not know anything about the new grub configuration anyway.

Moreover, in my humble opinion, what the grub developers have done in this new version does not make much sense: why do you want to execute a command to generate a boot entry dynamically?! Perform that choice when generating the grub configuration once and for all!

If you’re curious, that’s the difference after the grub update in the file used to generate the culprit entry in the grub.cfg (old file on the left, new file on the right):

So, after restoring my computer with arch-chroot (because I was hit by the bug), instead of their proposed “solution,” I ignored the package update by adding this line to /etc/pacman.conf:

This way, I won’t be hit by the bug again (until, hopefully, grub developers will revert that implementation decision, and Arch developers will provide a new grub package)

Then, I realized that, in the end, I don’t need a grub entry to enter UEFI! I can enter UEFI when starting the computer with a key combination (not to mention that, as I said above, my main grub is not the Arch one, but the Fedora one, as shown in my blog post)! Thus, I updated the grub package (of course, after removing the IgnorePkg entry shown above). Before rebooting (that’s crucial), instead of following the suggestion shown during the upgrade, I simply removed the grub file to generate the culprit configuration for UEFI in the grub.cfg (and, of course, I regenerated the grub configuration afterward):

That’s all! Your grub.cfg will not have an entry for entering UEFI anymore. I don’t need that.

Of course, you have to repeat these operations if Arch releases an update to the grub package without fixing the problem. However, I prefer this solution, which does not have the abovementioned drawbacks.

A first look at Crystal Linux

Crystal Linux is a brand new Linux distro based on Arch. Although it has not been officially released, you can already download an ISO and try that in its current development state.

Quoting from its home page:

Crystal Linux is a brand new Arch Linux based distribution.
Powerful and easy to use.

And, in particular

Why Crystal?
What’s so different about Crystal compared to other distributions?

  • Easy to use package manager
  • Beginner Friendly
  • Easy Btrfs snapshots
  • Easy to install

Since I’ve been using Arch and Arch-based (mainly EndeavourOS) distros for a while, I decided to try it, even if it’s not officially released, to briefly evaluate its current development status.

I downloaded the ISO crystal-live-08-20-22-07-55-x86_64.iso and tested it on a VirtualBox VM.

After the BOOT, you’re greeted by the GNOME desktop. I searched for the installer. I thought I’d find it in the dock, but that was not the case. I searched for an “install” string in the GNOME Activities. Again I got no results. Then, I recalled that Crystal names its installer Jade, and that’s how I found it.

The installer provides several screens to specify the typical information of a Linux installation. I would say that it does that in a very clear way. Here are a few screenshots of the pages of the installer:

Since it’s based on Arch, Crystal can provide a good selection of desktop environments. However, you can select only one:

Another interesting section is the next one, where you can enable Timeshift (recall from the introduction that “Easy Btrfs snapshots” is one of the advertised features):

Regarding partitioning, the Crystal Linux installer shows its “work-in-progress” state: you can only select the disk for the installation and nothing else. As noted in the dialog, it will wipe the whole disk and automatically partition it. Nothing is said about the file system, but I guess it will be a Btrfs filesystem (Spoiler: it is):

However, they are still working on the partitioning program:

Then, you get the summary for a final review. When you’re ready, start the installation:

The installer shows the installation log, which is excellent and helpful. Unfortunately, when the installation finishes, the log is not available anymore. It would be good to have access to that window still, to copy the log somewhere for a later examination.

OK, let’s reboot and see the distribution in action.

Crystal Linux should come with a customized GNOME desktop, Onyx, but that’s not installed by default. So you get a vanilla GNOME session (just like in Arch) with only a few programs installed (so, in this respect, it’s not bloated):

You don’t even have a Text Editor with a GUI (but at least you have Gnome Tweaks):

Of course, you can install whatever you want with pacman or with the Crystal custom AUR helper, amethyst, but beware: the command to run it’s ame; it took me some time to discover that 🙂 The AUR helper amethyst looks nice. Just like “yay”, you run it, and it also executes an update (“-Syu”). Besides that, the command line arguments are the same as pacman and yay, at least, that’s my first impression. Just like yay, amethyst also updates the AUR packages. Moreover, it is also configured to execute “pacdiff” at the end:

Unfortunately, the keyboard layout and the time zone I specified during the installation was not considered. I had to set them again in the GNOME settings.

The default shell is ZSH, which I like. However, it’s not configured at all, with any default. Thus, the first time you open a terminal, you have to do that yourself:

Let’s see how the installer created the partitions:

So we have BTRFS, with the two standard volumes @ and @home, which are suitable for Timeshift. No SWAP partition (swap is not configured at all). Moreover, there’s no compression on the BTRFS subvolumes, while I usually prefer to have compression.

There are also other subvolumes (I guess to exclude from snapshots the virtual machines you might create with Kvm):

Concerning repositories, Crystal is similar to EndeavourOS: it relies on Arch repositories and adds just a few custom repositories that you can also browse at You can see that there are not so many packages there. Besides the Crystal programs, you also find a few packages you typically install from AUR, like timeshift and timeshift-autosnap.

This allows me to talk about the “Easy Btrfs snapshots.” The Crystal installer has already set up timeshift, timeshift-autosnap (which creates snapshots before package upgrade), and grub-btrfs (which adds “btrfs snapshots” to the grub menu to boot your system on a “snapshot” from the grub menu). (I wrote about these 3 tools previously).

For example, that’s what you see when you perform an upgrade (note the automatic creation of the snapshot and the creation of the grub menus for the snapshot):

In fact, the next time you boot, you also get the grub entry for the snapshots:


I liked a few things and a few things I did not like, but I enjoyed the installation, and, in general, I have an excellent impression of this new distribution. It’s not for beginners, but it’s easy for users who have already tried a few Linux distributions.

In any case, I found Crystal promising, and I really look forward to the official ISO release!

Ubuntu Jammy and Nvidia

I installed Ubuntu Jammy a few months ago, when it was released, on a desktop computer. It was a terrible experience: crashes now and then, and the Wayland session was not working well on some applications. After a week, I uninstalled it immediately and switched to Fedora on that computer.

Then, a new point release came out, 22.04.1. I heard that, in the meantime, many bugs were fixed. I decided to give it another chance. In particular, I decided to install that on an older computer, a Dell m3800, because it comes with an integrated video card and a “terrible” Nvidia card, which is well-known to give headaches to Linux users 😉 In the past, I used Bumblebee on such a computer to keep the power consumption low. However, Bumblebee gave me problems in the past, and I seem to understand that it is not actively maintained anymore. So, let’s try a fresh installation of Ubuntu Jammy and see how it deals with the Nvidia card.

The installation went fine and smoothly. In the end, when rebooting into the new installation, I could verify that the Nvidia drivers were installed automatically and working correctly (meaning no crashes or other issues)!

Since it uses Nvidia, Ubuntu does not show any gear icon on the login screen to switch the graphical session: it’s X11 automatically, and you cannot change it. I guess that’s done because Nvidia does not work correctly in a Wayland session.

Another nice thing is that it detected my huge screen resolution, 3200×1800, and automatically enabled 200% scaling. However, I seem to remember that this is a feature of Gnome itself.

Having said that, I found using the Nvidia drivers really a problem: the computer gets immediately hot, the fans get pretty noisy, and it looks like the battery does not entirely charge even when connected to the AC. It also looks like the battery goes down a bit, even when connected to the AC.

I opened the Nvidia settings. However, it looks like Hybrid mode will not work with this version of the driver.

Of course, when running on battery, the power consumption is too much, and the battery would drain in less than two hours, as reported by powertop. That’s the reported consumption (even when the computer is idle):

33.6 W of power consumption is too much.

Since I’m not using graphical intensive software, I tried to switch to the integrated Intel graphics card. You cannot select this choice in the Nvidia settings because it’s greyed out (you can find many posts on the Internet reporting this problem without a solution). However, we can use the command line:

Let’s reboot, and now the gear icon appears, and you can select the Wayland session since the Nvidia card is not used. By the way, Nvidia settings still have the greyed-out entry for the integrated card, but at least it recognized that’s the one selected:

The power consumption on battery is better (about 15 W, i.e., half), but I seem to understand that the Nvidia card itself it’s still using power since it’s not completely turned off:

At least the computer is not that hot anymore, and the battery seems to charge correctly.

Let’s try to use a tool to turn the Nvidia card off: EnvyControl.

Let’s install that:

As noted here, there are a few additional steps when installing EnvyControl in Ubuntu:

We could use the envycontrol command to set the card, but let’s now install a Gnome extension with a GUI for the switch: GPU profile selector.

Let’s also activate the extension.

Let’s reboot, and now, in the Gnome dropdown menu about the battery and power profile, we also have the menu entries to select the card:

Remember that we had to set the “on-demand” mode for installing EnvyControl. That’s why the “Hybrid” entry is selected.

Let’s select “Integrated” and reboot; now, the Nvidia card should be off.

The power consumption on battery is even better now (13.8 W):

If we switch to the Wayland session, it even improves a bit:

I find this installation usable, and I saw no issues for the moment.

That’s all for now!

Cropping images with KDE Gwenview

I’ve always been using GIMP for cropping images (for articles, books, etc.), and it works pretty well, but I never thought that you could do the same much quicker with the default image viewer of KDE, Gwenview. In KDE Plasma, I’ve always used Gwenview as an image viewer, but it’s much more:

Gwenview is a fast and easy to use image viewer by KDE, ideal for browsing and displaying a collection of images.


  • Supports simple image manipulations: rotate, mirror, flip, and resize
  • Supports basic file management actions such as copy, move, delete, and others

In fact, you just open an image with Gwenview:

Press “Show Editing Tools” and then select “Crop” from the palette:

The box for cropping is ready to be resized:

When you’re done, just press ENTER:

and the image is ready to be saved!

With GIMP, the number of steps is much more significant.

Moreover, with Gwenview, once you cropped and saved the current image, you just press the right arrow to go to the next one. Much faster!

Installing Arch Linux with the archinstall script

After using EndeavourOS for a while, I also decided to try Arch itself!

I did not feel ready to go through the manual procedure (but I’ll do that someday), and I heard about the archinstall script, which comes in the Arch official ISO. After watching a few videos and reading a few blog posts, I tried that myself, first on a VM and then on a real machine.

I can anticipate that I liked this installation procedure. Still, it is not perfectly usable in a multi-boot environment, as I’ll say near the end of this post, where I summarize my experience with the installation.

In this post, I’ll first show an installation on a VM (and I suggest you try that one), then briefly describe the installation on a real machine.

If you want to try that, you have to download an official Arch ISO. Once you booted into the live ISO, you must connect to the Internet as described in the official documentation.

Now, it’s time to run the installer:

And you have access to the main installation menu:

You see, it’s easy to use, especially if you’re familiar with other Linux installation programs.

The first three entries are easy to deal with.

The fourth, “Select harddrives,” requires some care because it’s where you deal with your disk! You have to select the correct drive. In my case:

Since I’m on a VM, I’ll simply choose to wipe everything on that drive and let the installer handle the partitioning automatically. That’s easy in a VM, and that’s what I’ve seen in all demos on the web (but, as I’ll show later, things are more complicated in a multi-boot environment):

Then, you choose the filesystem EXT4, BTRFS, etc.

For the bootloader, I chose GRUB, which is the one I’ve always used.

Concerning the user accounts, it’s best NOT to set a root password: it’s better to create a user with administrator rights (so that you later rely on the good ol’ “sudo”). An interesting feature of this installation procedure is that it lets you create as many users as possible. On the contrary, typically, other Linux installations only allow you to create a single user.

The other interesting menu entry is the one to choose the profile. I’m choosing “desktop”:

And in particular, I’m choosing GNOME (you see that you have plenty of choices):

Moreover, you can select the graphic drivers:

And the kernels:

Since, for the moment, you could just select from a predefined set of choices, you are given a chance to manually specify additional packages to install (but you have to know them by their name). In this example, I’m installing “firefox”:

It’s also crucial to configure the network for the installed system. If you use GNOME or KDE, I’d say that it’s best to choose “NetworkManager”:

Once you’ve done with all the menu entries, before starting the actual installation, you’re given a chance to save these configurations, which is helpful if you want to use the same configurations on other machines or to do some further customizations:

Now, it’s time to choose “Install”; a countdown starts to abort the installation in case you just remembered you’ve done something wrong:

The installation starts and in a few minutes (where a few packages will be downloaded)…

…you should get to the end of the installation, where, if you want, you can also tweak the installed system before rebooting:

If you choose “no”, you’re back to the live environment:

And you can now reboot to (hopefully) enjoy your installation:

Having installed GNOME, I’m presented with a few options, and I choose the first one, that is, GNOME on Wayland:

You see that the GNOME installation is a vanilla one.

OK, that was a VM, and it was straightforward to install Arch with the installation script. It’s also easy if you plan to install ONLY Arch on your computer (by wiping all the rest).

Things are not working completely fine if you want to install it on a computer with other Linux installations, which you want to keep and be able to boot into. In this case, of course, you cannot wipe the selected hard drive and must do manual partitioning. The installation script is still helpful in that respect (I’m not showing anything in this blog post), but you must be aware of a small problem.

In fact, due to an issue, which, at the time of writing, is still open, specifying to mount an existing EFI partition into “/boot/efi“, which, as far as I know, it’s the standard mount point in most distributions (every distribution I know at least). You must specify a mount point “/boot” and that must be a boot partition (with the boot flag). Of course, that’s what I’ve done myself; I specified the exiting EFI partition (the first partition of the installation drive in my computer) for the mount point “/boot”. However, the installer will treat that directory as if it was /boot/efi in other installations. Thus, it will copy the booting files directly there. As a sad result, the Arch installation will not be detected when rebooted. You will only see an existing installation’s GRUB menu (and running os-prober from an existing installation does not seem to help). Thus, you end up with the Arch installation that you cannot boot.

The only solution I found to boot into the Arch system was to apply the mechanisms shown in my other post and configure the Fedora GRUB with an entry pointing directly to the EFI partition, i.e., according to the post mentioned above, something like the following (remember, on my computer the EFI partition is the first one, and I installed Arch on the partition 13):

Or even like that (i.e., without specifying the root partition of the Arch installation at all and just relying on the grub that the installer created directly on the EFI partition):

Besides this problem, the installation script archinstall is really interesting and still under development.

Locate and BTRFS

I’ve always been using the locate command (provided by the mlocate package or by the new plocate package), which quickly searches for files and directories by their names. The command relies on the database built by the command updatedb (which should be run periodically, e.g., by enabling the plocate-updatedb.timer service for plocate).

Unfortunately, by default, it does go well with the BTRFS filesystem and its subvolumes (see, e.g., this bug), resulting in empty results for all searches basically.

Fortunately, the solution is quite simple:

  1. edit the file /etc/updatedb.conf
  2. replace PRUNE_BIND_MOUNTS = “yes” with PRUNE_BIND_MOUNTS = “no”
  3. save, exit and re-run updatedb

Then, you can enjoy locate’s search results 🙂

Linux EndeavourOS Artemis Review

I have already blogged about EndeavourOS, which I use most of the time on a few laptops. Since EndeavourOS, based on Arch, is a rolling release, I update it almost daily and don’t need to install it from scratch when a new release comes out, like Artemis, which was released a few days ago. However, since I wanted to switch from the EXT4 file system to BTRFS (since I started to experiment with this file system and its snapshot capabilities), I took the chance to try this new release by installing it from scratch (of course, using BTRFS this time).

I’ll first go through the installation, but I can anticipate that, once again, I’m impressed by EndeavourOS. This installation feels really fast, maybe due to BTRFS or the new kernel (instead of the LTS kernel, I now use the latest one provided by the distribution) or both. Most of all, EndeavourOS is pure Arch but with outstanding defaults. Indeed, the KDE and GNOME environments are vanilla ones.


As usual, the first thing to do, once booted in the live environment, which in this case is XFCE, is set up the network connection. You might also want to change the keyboard layout (Disable system defaults and install your layout, in my case, it’s the Italian layout):

Then, let’s update the mirrors (typically by selecting your state) and start the installer.

I choose the “Online” method because I want to install KDE Plasma instead of Xfce.

You have to wait a few seconds (or about a minute) for the installer to download the modules (I always prefer to install any operating systems in English):

Maybe, due to a bug, the location has been found successfully, but the English version proposed is not the right one, so I have to change it to Americ English again:

After setting the keyboard layout (this time for the installed system), it’s time for partitioning.

Since on this computer I have a few Linux installations, including the old version of EndeavourOS I’m going to replace, I choose Manual partitioning (and not “Replace a partition” because that would keep the same file system type, EXT4, while I want to switch to BTRFS).

I Edit the partition, select “Format” (otherwise, I cannot change the File system type), modify the File system (BTRFS), and specify the mount point.

Before going on, we must specify to mount the EFI partition (into /boot/efi) without formatting it and ensure the “boot” flag is selected. This way, the installer can properly install GRUB.

WARNING: on another computer, the installer complained that I did not select a boot partition with at least 300Mb (mine was just 200Mb). Since I knew there was enough space in that partition, I ignored the warning, and the installation went fine.

As for the desktop, I select Plasma.

And then, we can select the single packages. Note that, different from my previous review, you choose the packages after selecting the desktop, so that a few packages, in particular, the ones of the chosen desktop, have already been selected:

In this blog post, I’m not going to install GNOME besides KDE, but I also select the “Printing-Support” and the “Support for HP Printer/Scanner” checkboxes.

As usual, then you have to specify your user’s details, and then it’s time to take a look at the summary:

Let’s start the installation. It might take a few minutes because it’s an “Online” installation, so it has to download several packages.

You can press “Toggle log” during the installation to see the installer’s log.

When it’s done, it’s time to restart the computer.

First impressions

As in the previous blog post, I must note that the Discover icon is still in the taskbar, though the software manager Discover is not installed at all.

Maybe because I selected KDE Plasma only, the Wayland session has not been installed, while in my previous post, I installed both GNOME and KDE. However, I just had to run this command:

And then I could enjoy Plasma also in Wayland, which seems to be pretty usable.

A nice addition is a firewall applet in the taskbar

Here’s neofetch:

Printing support is excellent! I connected an old USB HP Deskjet printer, and I got these notifications from Plasma:

The printer has been automatically installed correctly (I only had to configure a few things like paper size and color mode).

Setting up my Google accounts (drive access and calendar) is as cumbersome as always, but I did not experience any problems once I finished.

Power consumption on the battery is also excellent, but that was true in the past, so nothing changed in that respect.

All in all, this distribution keeps on being awesome.

As I initially anticipated, you have Arch and its vanilla desktop environments, but with useful and reasonable defaults. Moreover, the installation is effortless! 🙂

Enabling Hibernation in Arch-based distros

I had already posted about enabling hibernation in Linux, particularly in Ubuntu.

Thanks to the script hibernator, the procedure is much more straightforward in Arch-based distros (including Manjaro and EndeavourOS).

First of all, make sure you first install the package update-grub.

The package hibernator is available from AUR, but currently, there’s a problem with the build instructions. Thus, we must install it manually. There’s no need to install the script anywhere: it’s just a matter of cloning the script from GitHub and running it once:

Then, before running the script (as a superuser), we must decide where we want the suspend-to-disk to take place: either in a swap partition or in a swap file (please keep in mind that currently, the script cannot handle hibernation into a swap file of a BTRFS partition).

If we want a swap file, the script can create that for us, and we can also specify the size of the swap file. Here’s the quote from the home page of the project

Hibernator accepts desired size of swapfile as arguments. Running hibernator 2G creates 2 Gb swapfil, hibernator 1000M creates 1000 Mb swapfile. The script defaults to 4G if no arguments are given.

If we want a swap partition, we must ensure the partition is already in place and that our /etc/fstab already refers to that (i.e., it mounts it appropriately).

When we’re ready, we just run the script with sudo. The script will update the GRUB command line with the resume option and a resume hook to /etc/mkinitcpio.conf. Finally, it will update the GRUB configuration (with update-grub, that is why you need to install this package beforehand).

Here’s an example of the output:

And that’s all: we just reboot, and hibernation is ready to be used!

Before rebooting, you might want to check that the GRUB_CMDLINE_LINUX_DEFAULT variable in /etc/default/grub has been set with a valid resume entry (if you rely on a swap partition, which has been properly specified in /etc/fstab, it should contain a reference to the UUID of the swap partition):

You can test that, as usual, with

You may also want to refer to the older post enabling hibernation in Linux, particularly in Ubuntu, for other mechanisms related to hibernation, like suspend and then hibernate.