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.

Installing Amarok on Arch Linux

Leave a reply

I have always liked Amarok, the (initially) default KDE media player. It’s very feature-rich, nothing compared to Elisa. Moreover, it has two crucial features that I haven’t found in any other players:

  • it saves statistics (play count and stars) directly into the music file
  • it synchronizes statistics with iPod

Unfortunately, while still maintained, you won’t find pre-built packages in mainstream distributions (e.g., Ubuntu). Thus, you must install that from sources, which is problematic. However, for Arch Linux, there’s an AUR package, which takes care of the compilation and, most of all, its dependencies.

In this blog post, I’ll summarize the steps for installing Amarok to access iPods (I still have an iPod classic).

First, you need to install the Phonon backend required by Amarok:

If you want to use Amarok with an iPod, you must first install

IMPORTANT: the iPod library (this must be present when Amarok is compiled from sources; if you forget about that, you’ll need to recompile Amarok, e.g., by specifying “–rebuild” as a command line argument to the AUR helper):

Then, we’re ready to install (i.e., compile from sources) Amarok from the AUR repository (I’m using the “yay” AUR helper here, but if you use another one, use your preferred one):

Now be patient: it will take several minutes for the compilation to finish (about 20 minutes on a decent machine)!

If you’re on KDE, you can now enjoy Amarok.

If you’re on GNOME, there’s still something to fix. In particular, you’ll see Amarok lacks lots of icons:

You need to install Breeze icons:

And now you can also enjoy icons:

Concerning the iPod: first, you have to mount it, and then you start Amarok so that Amarok can see the mounted iPod.

Enjoy your music! 🙂

Docker on macOS M1

Leave a reply

Although I’m a Linux user, I also recently bought a Mac Air M1, and I wanted to use Docker (a big part of my TDD book) to ensure that my projects based on Docker work on m1 as well.

I then went to the Docker website for macOS and downloaded the version for the Apple m1 chip:

Then, I continued with the installation:

Let’s start it. Although m1 is fast, starting Docker Desktop takes some time.

Although I’m already familiar with Docker (on Linux), I decided to follow the “getting started” tutorial, which is well done:

At least, I’m sure that Docker is working on this machine.

The desktop app is well done, with a few sections to inspect Images, Containers, etc.

And, of course, there’s the “Preferences” section. For the moment, I stick with the defaults.

From the terminal, I ran the usual “hello-world” image:

I also tried to run a Ubuntu container. Inside the container, I verified that it’s running an “aarch64” version instead of the x86 one (“amd64”).

I also installed “file” to verify that it’s using aarch64 binaries (“arm64”):

From the Desktop application, you can quickly enter a container with a terminal:

Now, it’s time to verify that my Java projects based on Docker work as expected.

Java & Maven

This is a simple Maven example (a pom.xml file) that uses the https://github.com/fabric8io/docker-maven-plugin to start and stop a MySql container:

Run “mvn docker:start” to start a MySql container with a random mapped port. The command will wait for the container to be ready (it looks for a “ready” string within 20 seconds). After the command succeeds, the container will be running in the background. Run “mvn docker:stop” to stop the started container.

To avoid errors in this shape:

You need a recent version of the https://github.com/fabric8io/docker-maven-plugin. For example, 0.38.1. It also works with the current latest version, 0.40.2.

Actually, the first time I tried this project, it did not work (not because of the above error), but after a recent update, it started to work, maybe because of this added link:

Note that not all the images are available for this architecture “aarch64”. For example, if you try to use this older version of “mysql”, you get this error:

However, you can force the intel architecture for an image, as documented here https://docs.docker.com/engine/reference/commandline/run/, e.g., with this environment variable correctly set:

For example, for the above Maven project:

If you now enter the container, you can verify that you’re running an x86_64 image:

However, such images will run slower because they are emulated:

Testcontainers

I also use Testcontainers to start Docker containers from the JUnit tests in my projects.

For example, I’m using this example from my TDD book, https://github.com/LorenzoBettini/it-docker-mongo-example, and it works out of the box.

Eclipse Docker Tooling

Currently, the Eclipse plugin for Docker, Docker Tooling, does not work: it cannot connect to Docker. This has been reported (https://github.com/eclipse-linuxtools/org.eclipse.linuxtools/issues/61), and a patch is available to make it work: follow the instructions detailed here https://github.com/eclipse-linuxtools/org.eclipse.linuxtools/issues/61#issuecomment-1326838270. I tested it, and it works:

To summarize, using Docker on macOS m1 seems to work fine! 🙂

Installing Arch Linux the (not so) hard way

1 Reply

After using EndeavourOS, an Arch-based distro, for some time with much pleasure and appreciating Arch mechanisms (packages and AUR), I decided it was time to try the “real thing” and install Arch the “hard way” 🙂 Spoiler: it’s not that hard!

I thought it was hard. For sure, it’s more complicated than other distro installation procedures, but, to be honest, after using Linux for more than 20 years, I thought there was not much to be scared of 😉

I now use Arch (besides other distros) on my machines greatly. Of course, I did many experiments with virtual machines before installing Arch on bare metal. I know there are many guides and tutorials, but I’d like to summarize my steps for installing Arch (with a SWAP partition, an EXT4 partition for data to be shared among distros, and a BTRFS primary partition). In particular, in this blog post, I’ll describe my steps for installing Arch on a virtual machine, which, as I’ve just said, it’s the best way to get confident with Arch and not be scared of installing Arch on a real computer. Moreover, on many guides, I noticed a few missing points, which, instead, are essential.

Of course, the best reference is the excellent official guide, and I’ll use the official guide as a reference while following along, https://wiki.archlinux.org/title/installation_guide. Note that there are still a few parts in the guide that refer to other parts of the excellent Arch wiki, and I had a few minor problems the first time I tried the Arch installation.

Here we go!

Create and configure the virtual machine with enough disk space (dynamically allocated so you won’t waste space on your disk), let’s say 100Gb. Make sure you enable EFI in the virtual machine configuration. Of course, insert the Arch Linux ISO as a live CD in the virtual machine. I’m going to use archlinux-2022.09.03-x86_64.iso.

As described in a previous post, I’d suggest performing the installation by connecting via SSH to the virtual machine. This way, you’re using a local terminal: copy and paste will work (since you’re on a local terminal). In particular, since the Arch installer is textual, being able to copy and paste commands from a local terminal makes everything easier. Moreover, the keyboard layout will be the host system’s keyboard layout. Thus, the keyboard layout will be already configured correctly. While in the virtual machine, you’d have to configure the keyboard layout.

(On a side note, even when installing Arch on a real computer, I prefer doing that via SSH, of course, from another computer.)

Before starting the virtual machine, we must map the SSH port of the virtual machine to a local port to connect from our computer. This requires knowing the name you gave to your virtual machine. In this example, I called the virtual machine “Arch Gnome” (because I’ll then install Gnome on the Arch installation). We must run these instructions from the host computer:

Port 2522 is the one we’ll have to use later for connecting to the virtual machine via localhost. Of course, feel free to use another free port number as long as you’ll use it consistently from now on.

Start the virtual machine:

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, 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 “[127.0.0.1]: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):

Let’s set the console keyboard layout (the default layout is US; if that’s fine with you, skip the next step). This step is not strictly required for our local terminal: even if we’re inside the virtual machine, we’re using our local terminal, so we already use the correct layout. However, let’s do that anyway since we want to simulate an actual installation. Moreover, having the proper layout is good if we want to run commands directly from the VirtualBox window.

I already know the layout I want for my Italian keyboard, so I run:

If you don’t know the exact layout, you can list the available ones with

You can verify in the VirtualBox window that the layout is applied correctly.

Since we are in a virtual machine, the machine should already be able to access the Internet if your host is correctly connected (and that’s required to install Arch Linux). However, if you want to simulate what you would do with an actual installation on bare metal, you can ping a remote host and verify that everything’s OK:

Before going on, as suggested in the official guide, it’s better to make sure the system clock is accurate by enabling network synchronization NTP:

Partitioning the disk

How to partition the disk is your choice. In this example, I will partition the disk according to my needs. However, you need at least two partitions: one for booting in UEFI mode and one for the root filesystem.

In this example, I’ll create 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.

Now, it is time to get to know the device name of our disk using the command lsblk:

As you might guess, sda is the disk we are installing Arch Linux upon. In a virtual machine, that’s probably always like that. On a real machine, it might be different (for example, if you have an NVME SSD, it will be something like nvme0n1). It’s needless to say that using the correct device name is crucial, especially on a real machine, or you might end up wiping away essential data. The nice thing about a virtual machine is that you’re in a “sandbox,” so, at worst, you’ll break your virtual machine.

So I run

If it is a new virtual machine, you’ll be asked a partition table: choose gpt.

Start creating your partitions. Just use the menus of cfdisk; it’s easy (on the bottom, you will find some help). Once you create a partition, set the “Type” correctly. By default, the type is “Linux filesystem”. For UEFI, you have to specify the type “EFI System,” and for the swap partition, “Linux swap”.

That’s my final result:

Let’s “Write” the partition table to disk and “Quit”. We can also verify with lsblk that the result is as expected:

Of course, you must know which partition is meant for what. In my example, sda1 is for UEFI, sda2 for swap, sda3 for my shared data, and sda4 for root.

Format the partitions

According to my intended layout shown above, I’ll format the four partitions with the following commands:

Mount the partitions

This is also delicate, so you must use the correct device names. What follows is, of course, correct according to my layout.

First of all, let’s deal with the swap partition:

The presence of the BTRFS file system for the root partition makes things a bit more interesting (or a bit more complicated, as you prefer 😉

First, we must mount the BTRFS filesystem on /mnt. Note that we are mounting the BTRFS on /mnt only temporarily and to create the subvolumes (in a minute, we will mount the subvolumes in their final shape on /mnt, together with the other partitions):

This will allow us to create the subvolumes. Again, what follows is the BTRFS subvolume layout I prefer. You might want to choose a different one. To use Timeshift, you must have at least @ for / and @home for /home. This is how I create the subvolumes I want:

As I said, this mount was temporary, just for creating subvolumes. In fact, we now unmount /mnt:

And we mount every single subvolume in its final “position” inside /mnt by also specifying a few additional options like the general “noatime” and the BTRFS-specific “compress” to enable the ztsd compression:

The “-m” option makes mount create the target directory if it does not exist.

Finally, we can mount the remaining partitions. The UEFI one should be mounted to “/boot/efi” inside “/mnt”. I like to mount the “common” partition in “/media/bettini/common” inside “/mnt” because that’s where I’ll use it (relying on the fact that I’ll create a user “bettini” for myself). Again, choose something else for yourself. These are the commands:

This is the final layout of /mnt, which, remember, is where our system will be installed:

Select the mirrors

This part, documented in the official installation guide, is usually skipped in several blog posts I found online. Instead, this step is essential.

The mirrors are specified in the file /etc/pacman.d/mirrorlist.

The guide says:

On the live system, after connecting to the internet, reflector updates the mirror list by choosing 20 most recently synchronized HTTPS mirrors and sorting them by download rate.

The higher a mirror is placed in the list, the more priority it is given when downloading a package. You may want to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account

You can verify that by inspecting the file /etc/pacman.d/mirrorlist. In my case, the Italian mirror is the last one, so it will be given the lowest priority. This sounds wrong to me. In particular, the documentation also points out:

This file will later be copied to the new system by pacstrap, so it is worth getting right.

Thus, I prefer to run the program reflector myself (see the reflector documentation for the single arguments; of course, I’m using “Italy” as the country because that’s where I leave; I could also specify several values separated by a comma, e.g., “Italy,Germany”):

The following step does not seem to be required in the installation guide. However, to make sure we have an updated PGP keyring (for checking signatures of packages), at this point, I also run:

Running pacstrap

Now, it’s time to install the base packages, Linux kernel, and firmware for standard hardware using the pacstrap script. You specify the target directory, which, as you might guess, it’s /mnt, and the packages.

This is the command I run (I prefer to use the LTS kernel; if you want the latest kernel, use “linux” package instead of “linux-lts”; you can also install them both and then select one from the grub menu):

This command will download about 500Mb, which might take time depending on your Internet speed.

Configuring the system

Since we have already manually mounted all our partitions (on /mnt), the Arch ISO can generate for us the file fstab automatically through the command genfstab:

The “-U” option tells genfstab to use UUID to refer to partitions (alternatively, “-L” can be used to use labels instead).

You can have a look at the result (of course, UUID will be different in your case):

Note that although we used the option “compress=zstd” when mounting our BTRFS subvolumes, genfstab turned that into “compress=zstd:3” because “3” is the default compression value for zstd in BTRFS. If we wanted to make the compression value explicit, e.g., “1”, we should have done that when mounting the subvolumes. Of course, you can always tweak the generate fstab as you see fit.

Now, we can “enter” our installation with “chroot” or, better, with the enhanced arch-chroot, which automatically binds other things like /dev and /proc:

The root directory is what’s inside /mnt, so / refers to what’s inside /mnt. Also, the prompt has changed to reflect this:

We now set the timezone of the installed system. You must use Region/City according to your location. Timezones are available in the directory /usr/share/zoneinfo/. In my case (Italy), I run:

Then, we use hwclock to set the Hardware Clock from the System Clock:

Then, we edit /etc/locale.gen and uncomment the locales we need; in my case, en_US.UTF-8 UTF-8 and it_IT.UTF-8. Since I already know the two locales, instead of editing the file (where all locales are commented out), I append the two locales to the end of that file:

And we generate the locales:

We must also create the /etc/locale.conf file, and set the LANG variable accordingly. This can be done as follows:

We also make permanent the initial changes to the console layout (remember, I used “it”; in your case, you need to use the code you previously specified):

We’ll deal with the network configuration (of the installed system) in a minute. But we can already create the files /etc/hostname and /etc/hosts. You have to choose your preferred hostname. In this example, I’m going to use “arch-vm-gnome”. So I generate the two files with the following two commands:

The boot loader

Since we use BTRFS, we might want to tweak the file /etc/mkinitcpio.conf with these two modules:

And regenerate the initramfs images:

Let’s now install the bootloader. I prefer GRUB. So let’s install a few packages:

During the installation, you might want to take note of the recommendation for installing and configuring grub and the optional dependencies:

Now we install grub in the UEFI partition. Note that, unlike standard GUI Linux installations, you can specify the “–bootloader-id”, which will be the identifier of this grub installation in UEFI. This is useful if you have several bootloaders on your machine. In this example, I’m using ArchGnome:

Hopefully, the installation should succeed, and we can generate the grub menu:

Here’s the output of these two commands:

User accounts

Don’t forget to set the following passwords, or you will not be able to log in to the installed system once you reboot later.

We can now set the root password. This is the effective password for root in the installed system. This should be chosen carefully:

I prefer to use “sudo”, so I first install that

This is also the moment to create your own user account; in my case, it is “bettini”.

I add the user to a few essential groups, in particular, “wheel” which makes my user a superuser account. Just relying on the group “wheel” is not enough: we must allow members of the group wheel to execute any command. This is done by uncommenting this line in the /etc/sudoers: “%wheel ALL=(ALL:ALL) ALL”. A sed command will accomplish that:

That would be enough to reboot and try our installation. However, we would have no networking (actually, since this is a virtual machine, networking should work out of the box since you don’t need to configure any WiFi network, for example) and no desktop environment. So let’s go on with some further installations and configurations:

Install Gnome

In this example, I’m going to install the GNOME desktop environment. Besides GNOME, I’m installing other necessary packages like the “NetworkManager” (for easily configuring networking in GNOME), “firewall”, “firefox”, the package for choosing a power profile (useful for laptops), and other base packages, including the kernel headers (here I’m using “linux-lts-headers” because I installed the LTS kernel; otherwise, use “linux-headers”):

About 700Mb will be downloaded.

Once done, we have to enable the services at boot (in particular, GDM, the login manager, and the NetworkManager):

Time to reboot!

Now, it’s time to leave the environment and unmount all the partitions:

And reboot into our new Arch Linux installation.

If everything goes fine, we should see the login manager, and we can enter Gnome:

So, in the end, it’s not so hard to install Arch 😉

Maybe it’s a long procedure, but… most of that can be scripted! That’s will be the subject of another blog post, so stay tuned! 🙂

Linux EndeavourOS Cassini Review

1 Reply

I have already blogged about EndeavourOS, which I use most of the time on all my computers (desktops and 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 Cassini, released a few days ago. However, I wanted to try this new release by installing it from scratch (of course, using BTRFS).

I’ll first go through the installation, but I can anticipate that, once again, I’m impressed by EndeavourOS. This installation is smooth, with some novelties: you can choose between “grub” and “systemd-boot” now. Moreover, they switched from “mkinitcpio” to “dracut” for the generation of initramfs (this requires a few adjustments if you want to enable hibernation). Most of all, EndeavourOS is pure Arch but with outstanding defaults. Indeed, the KDE and GNOME environments are vanilla ones, with only a few customizations.

This time, I’ll install GNOME (but I’ll briefly say something about the KDE version at the end of this article).

Installation

First, I’m using Ventoy to boot the installer because I keep several Linux ISOs on the USB stick. I first made sure to update Ventoy because I read that the old versions did not work correctly with the latest Arch-based ISOs. Moreover, once I selected the “Cassini” ISO:

I got another menu (that’s something new), where I selected GRUB:

As usual, the first thing to do, once booted into the live environment, 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 possibly another one near you) with the “Welcome” application:

Then, let’s start the installer.

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

I always prefer to install any operating systems in English, so I select “American English”:

The location has been found successfully, and while the language is the one I chose, it proposes to use my Italian locale for dates and numbers:

After setting the keyboard layout, I select the GNOME desktop:

And then, I can select the single packages. Since you choose the packages after selecting the desktop, a few packages, in particular, the ones of the chosen desktop, have already been selected:

Then, I typically unselect “xf86-video-intel”, which is known to give a few problems:

And I select all the packages concerning “Printing Support” (including “HP”) and also the “LTS kernel in addition” (because if anything goes wrong with the latest kernel, I can switch to the LTS one).

Now there’s a big novelty: you can select the bootloader. The default is “systemd-boot”, but I prefer to stay with GRUB (since I know it works for my use cases like booting Timeshift snapshots and booting other distros):

It’s time for partitioning. Since I have another (EndeavourOS) Linux installation and Windows on this computer, I choose Manual partitioning:

First, I specify to mount the existing EFI partition (into “/boot/efi”) without formatting it and ensure the “boot” flag is selected. This way, the installer can properly install GRUB.

Then, I select the (existing) partition I’m going to replace with this installation; I specify to format it as BTRFS and mount it as the root partition:

There’s also an existing EXT4 partition that I use to share common data among my Linux installations, so I select that (without formatting it) and specify my desired mount point:

That’s the final layout of the primary SSD disk:

I also have another HD on this computer with some existing partitions I want to access from the installed system. So I select this other disk from the top drop-down list, and I specify the final mount points:

As usual, there’s the “Users” section, which I will not detail.

Finally, we can have a look at the summary, which looks good to me:

OK, let’s start the installation!

The installation went fine, and it took about 5 minutes. This is an old computer (6 years old), so it was pretty fast.

First impressions

Here we are in the installed system!

As usual, the GRUB menu is beautifully pink and purple:

And here’s GNOME:

You see that these are not the standard GNOME icons. In fact, EndeavourOS provides GNOME with the “Qogir” icons, which look great to me:

Besides that, I seem to understand that’s vanilla GNOME (it does not have “minimize” and “maximize” buttons enabled by default). It’s good that “GNOME Tweaks” is already installed. However, there’s no GNOME extension installed (the first one I installed was “AppIndicator and KStatusNotifierItem Support”). The terminal is the new “GNOME Console”, which I’ll soon replace with the old “GNOME Terminal” (I prefer that one). Standard GNOME applications like “Calendar” and “Contacts” are not installed either. At least, we have the new GNOME Text editor, which replaces the (IMHO) unusable “Gedit”.

There are no standard GNOME wallpapers, just the EndeavourOS one. Of course, you can install other wallpapers using the “Welcome” app. However, I’ll switch to Variety soon.

The Wayland session is enabled by default. It’s OK to me because GNOME and Wayland are usable nowadays.

The BTRFS subvolumes were created as expected, that is, with a separate “@home” and separate subvolumes for “/var/log” and “/var/cache”. Unfortunately, we also have nested subvolumes for “/var/lib/machines” and “portables”, which are known to give headaches if you restore a Timeshift snapshot:

Thus, since I’m not planning to use them, I removed them (this will make the two nested subvolumes disappear), and I recreated them as standard directories (I seem to understand that those two directories must exist; otherwise systemd will recreate them anyway):

So it’s time to start installing my applications and tweak a few GNOME settings.

In particular, since I have both the “linux” and “linux-lts” kernel, the GRUB configuration sets the LTS version as the default. To change that, I edit “/etc/default/grub” and specify

And regenerate the GRUB configuration:

Concerning KDE

I have also tried EndeavourOS KDE on a virtual machine. With Cassini, you get a new custom (and beautiful) Plasma theme, dark and purple (as usual in EndeavourOS).

To summarize

To summarize, EndeavourOS once again proved to be a fantastic Arch-based Linux distribution:

  • Easy to install
  • Arch-based (e.g., not like Manjaro)
  • not bloated with too much software
  • close to the vanilla DEs (at least for the ones I tried, GNOME and KDE)
  • with a wonderful and warm community, by the way 🙂

Happy new Linux year! 🙂

Enabling Hibernation in EndeavourOS (with dracut)

Leave a reply

EndeavourOS is an Arch-based Linux distro, so the technique for enabling hibernation for an Arch-based distro should work out of the box. That was true until the new ISO released this December, “Cassini”, where they switched from “mkinitcpio” to “dracut”.

Now, a few things must be adapted to make hibernation work in EndeavourOS, and the automatic tool described in my previous post can no longer be used. However, don’t worry; it’s not hard to enable hibernation. In this post, I’ll describe the steps to enable it.

IMPORTANT: my instructions assume that you have a SWAP partition; for a SWAP file, you’ll have to adapt a few things, but I can’t help since I never use SWAP files.

First, you need to have a swap partition already set up. For example, in /etc/fstab, you should have something like

The UUID is essential, and you should take note of it.

Then, we must tell “dracut” about hibernation so that it generates initramfs accordingly. It is enough to create the file “/etc/dracut.conf.d/resume.conf” with this line:

By the way, a quick way to do that is by running this command:

Then, we regenerate initramfs:

Now, edit your /etc/default/grub and specify resume in GRUB_CMDLINE_LINUX_DEFAULT, with the UUID of your swap partition. So it should be something like (remember that <UUID of your swap partition> must be replaced with the UUID; the “…” refer to existing options):

Save the file and update the grub configuration:

Now, reboot and hibernate should work. You can try that with the following:

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.

Acer Aspire Vero, Unboxing and First Impressions

Leave a reply

During the last “Black Friday,” I bought this laptop:

Acer Aspire AV15-51-58J2 39,6 cm (15.6″) Full HD Intel® Core™ i5 16 GB DDR4-SDRAM 512 GB SSD Wi-Fi 6E (802.11ax) Windows 11 Home. (Intel Evo certified, by the way)

I paid 599 instead of 899 euros, that’s a significant discount (especially for its features, mentioned above and detailed in the post)!

This laptop caught my attention a few months ago due to its “eco” and “green” construction choices. You might want to look at https://www.acer.com/us-en/laptops/aspire/aspire-vero to know more about the recycled materials used for its construction. Besides these “green” appealing characteristics, I immediately found the laptop “beautiful” and pleasant at the touch.

In this blog post, I’ll describe my first impressions.

Here’s the unpacking. As you can see, the packaging is made of recycled paper:

The charger is not USB-C, unfortunately. However, it is pretty light. And the only USB-C port CAN NOT be used for charging, but only for data transfer:

And look: one of the containers can be used as a stand for the laptop (excellent!):

Besides the standard papers and a very minimal getting started guide (pretty useless), there are also some ecological stickers 🙂

Also, the inverted “R” and “E” (for the three words “Reduce”, “Reuse”, and “Recycle”) are a slight distinguishing touch (they’re on the keyboard cover as well):

 

And there are lots of ports (right side: USB 2 and headphone Jack; left: one HDMI, two USB 3, one USB-C – only data, no recharging, and an ethernet port, besides the recharging port). To be honest, I did not find the ethernet very comfortable to use, but maybe I need to get used to it.

This means there’s no SD card reader… Too bad!

The back shows that it should be easy to open the laptop (standard screws), though I still haven’t tried that:

Oh, and there are no painted elements on the laptop: there are engraved symbols and writings:

You see that the surface is anything but smooth, but that makes the laptop very pleasant to touch. Probably the best laptop surface I have ever had! Yes, that part is mostly recycled too, which is ecologically good! 🙂

The two lights on the right will tell you when the battery is charging (“red”: charging, “blue”: fully charged) and when the computer is on:

Unfortunately, these are the only LEDs provided by this laptop. This means that unless the operating system tells you something, you cannot know whether the num lock or the capslock is selected.

When you open the laptop (you can also open it with one hand), the screen slightly lifts the back of the laptop so that the ventilation works better.

Let’s turn it on and enjoy the nice booting logo:

The keyboard is backlit, and the light is good enough to use the keyboard comfortably. Unfortunately, after the backlight turns off because you haven’t used it for a while, just using the touchpad will not turn the backlit back on: you have to press a key.

The keyboard is lovely! At least, that’s the best keyboard I’ve used. Yes, better than Mac air, DELL XPS, and LG GRAM. It’s a great pleasure to type on this keyboard. The only bad part of this keyboard is that the “ENTER” key (“Invio” in Italian) is large enough but too close (actually, attached) to the other key (“ù” in the Italian version). But that’s a problem only for the first minutes of usage. I got used to it.

On the contrary, the touchpad is only “OK”. My other above-mentioned laptops have a much better touchpad. Having said that, this touchpad is usable anyway, though a bit tougher in some external points. If you click on the center, you have no problem. The touchpad is probably too smooth, and if your fingers are wet, you will experience some friction.

Another mechanism I had to change immediately was the function keys. As it happens in several modern laptops, by default, a function key does not behave like a function key but as the other functionality provided by the key (e.g., volume adjustment, light adjustment, etc.). Luckily, I almost immediately found the procedure to achieve that (once and for all) on the Acer website:

  1. Enter the BIOS (you must press F2 while the laptop is booting when you see the “Acer” logo; in the BIOS, you can press Ctrl+S to enable hidden and advanced features; that’s not required for what I need to do in this specific case).
  2. Then, in the main tab, you must change the “Function key behavior” to “Function Key”. Save and restart.

The laptop comes with Windows 11 Home installed. If you read my blog, you know that I’m not a Windows fan 😉 (I have already installed a few Linux distros in multi-boot, and I’ll blog about that in the future). However, Windows 11 is not that bad (well… it’s still Windows 😉 The theme provided by Acer is, of course, “green,” and I like it:

Of course, there were already several updates to apply, which took about an hour! The Windows installation already comes with Firefox installed and several other software. Unfortunately, this includes Norton security, which I had to uninstall immediately (too heavyweight).

The screen resolution is 1920×1080 60,05 Hz and by default Windows already configures 125% scaling. I had to turn it to 150%. Otherwise, it was too fainting for my eyes to using it.

Power consumption is good. I’m used to LG GRAM, Dell XPS, and Mac air, which provide much better battery time. However, this Acer is not impaired in that respect: they say it should provide about 9 hours of battery time. Of course, it’s less, but I found that by using it pretty intensively, you get 5 hours. In that respect, Acer provides its own application (just search for “Vero” in Windows) for choosing a battery profile:

Note that between the usual “Powersave” and “Balanced,” you have an additional “Eco Mode”.

This program also allows you to set the battery charge limit (to increase battery life):

Moreover, there’s also the program “Acer Aspire Center” with other valuable utilities:

To summarize, my first impressions are great! I like this laptop, and for the price I paid, it has excellent features. Moreover, as I said above, I also find it very beautiful. I appreciate the “green” and “eco” ideas and design choices behind this laptop!

Concerning portability, my Dell XPS 13, LG GRAM 16, and Mac air are, of course, better, but in the end, this laptop weighs less than 2 Kg, so it’s heavier than the others mentioned, but still portable enough.

Stay tuned for more blog posts on this laptop, especially concerning Linux on this laptop 🙂

Installing Arch Linux on a PineBook Pro (external storage)

3 Replies

This post will describe my experience installing Arch Linux on a PineBook Pro on external storage (USB stick in this example). Thus, the Manjaro default installation on the eMMC will not be touched. You should use a fast USB Stick, or the overall experience will be extremely slow. I’m using a SanDisk Extreme PRO, which is fast and feels like an SSD. This USB stick will be erased entirely, so don’t use a USB stick with essential data on it.

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 Gnome.

First part

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

I insert my USB stick, which is /dev/sda. (Use “lsblk” to detect that.) 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 USB stick. Moreover, make sure you specify the right device, or you might overwrite the eMMC of the computer.

This process creates the partition table for the device, with the first partition for Tow-Boot. This created first partition must not be modified further. In fact, as you see in a minute, when we further partition the disk, we make sure to skip the first partition.

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:

These are the 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 the existing ext4 signature):

Now we must format the boot and the root partitions. I’m going to use EXT4 for both:

Note that although the second command returns immediately, the EXT4 partition will be formatted in the background and will take some time (even with a fast USB stick).

Now we mount the two partitions:

  1. mount the root partition (the 3rd partition) on “/mnt”
  2. create the boot directory at the root of the mounted system
  3. mount the boot partition (the 2nd partition) on “/mnt/boot”

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):

We create the file “/etc/fstab” in “/mnt” accordingly (remember, the UUIDs and the partition types must be specified accordingly). I run “nano /mnt/etc/fstab,” and I append the following contents (I use “noatime” to reduce the number of writes on the external USB stick when used to run the installed OS):

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

Once again, the contents depend on the UUID we discovered above for the root filesystem, so the contents must be adapted accordingly:

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 additional 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 that is 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”).

Before going on, I prefer to set up a SWAP file (of 8 Gb). The PineBook Pro has only 4 Gb of RAM, and it is likely to exhaust it. Using ZRAM did not work in my experience with Manjaro, so it’s better to have a SWAP file to avoid system hangs.

I run as root (“sudo su -“):

This takes some time. Then, I add the following line at the end of “/etc/fstab”:

Install GNOME

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

I’m going to install GNOME with some fonts, pipewire media session, firefox, and the NetworkManager (I’ll ignore dependencies that cannot be installed, e.g., “gnome-boxes” since I’m not going to use virtual machines on this machine):

It’s more than 500 Mb of packages to install, so please be patient.

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

OK, time to reboot.

This time the graphical GDM login manager should greet us, allowing us to get into GNOME and select a WiFi connection.

NOTE: when GDM starts, I always hear a strange noise. 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.

And here’s the GNOME 43 setting on the right top corner showing the connected WiFi and the currently selected power profile “Balanced”:

By default, GNOME starts with the Wayland session. Everything seems to work; touchpad gestures work out of the box (3 finger swipes). Something does not look right in the Wayland session, though. For example, if you run Firefox, you cannot switch to it with Alt+Tab. I prefer to go for the X11 session for the time being (that’s selectable from the GDM’s gear icon on the bottom right corner once you select your user).

Here are a few screenshots of the GNOME activities and the currently installed applications:

The GNOME 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 GNOME (installed programs and configurations).

Stay tuned! 🙂

UI Tests in Another Display in Linux

Leave a reply

UI tests are delicate since when you run them, you must not interact with the computer, or you will disturb the tests, which will likely fail.

In Linux, you can use Xvfb, but windows will not have a title, which might break UI tests that rely on that. For example, Eclipse SWTBot tests work best if windows have titles.

The solution (I’m still talking about Linux) is to use Xephyr:

  • you start Xephyr by specifying a DISPLAY number
  • you start a Window manager on the same display
  • you run your UI tests on the same display

Now, you can interact with your computer without disturbing the UI tests. That’s very important if you need to debug the UI tests: if they don’t run in another display, the UI tests will likely fail if you switch to the debugger.

IMPORTANT: this works only when you’re on an X11 session (not Wayland).

The name of the package for Xephyr depends on your distribution. For example, in Arch Linux, you install it like that:

Now, from a terminal window, you can start Xephyr (in this example, using the DISPLAY 50) and run a Window manager inside, specifying that it must run with X11.

If you’re on Gnome, you use mutter:

If you’re on KDE, you use kwin:

This is an example in Gnome: I ran the above commands, and then, from the same terminal (where DISPLAY is set to “:50”), I started the Gnome Text Editor, which appears in the Xephyr window:

In the following screenshot, I’m running the Maven build of one of the examples of my TDD Book, which uses AssertJ Swing for the UI tests of a simple Java Swing application (I started another terminal, where I exported the DISPLAY environment variable set to “:50”):

The UI tests (see the “MyAppWindow”) are undisturbed in the Xephyr window, and I can interact with my computer without breaking them.

From Eclipse, e.g., for a SWTBot test, you have to tweak the run configuration in the “Environment” tab:

And these are a few SWTBot tests for my Eclipse project EMF Parsley, which started from Eclipse but running in the Xephyr window:

Happy UI testing! 🙂

Maven profiles that are really active by default

Leave a reply

While working on my TDD book, I played with Maven profiles to write the chapter.

If you use Maven profiles, you might want to use an activation strategy to enable the profile under certain circumstances automatically. There’s also a particular option, “<activeByDefault>”, which seems self-explanatory. This must mean that that profile will be constantly active by default unless you explicitly disable it, e.g., with “-P!profileid”.

Here’s a possible minimal example:

By using the maven-help-plugin‘s goal “active-profiles,” we can verify that:

Unfortunately, this will probably never work as we expect. For example, let’s add another profile (without any activation strategy in this example):

If we explicitly enable such a profile, we’d expect the previous one is still “active by default”, but we have a terrible surprise:

As it is documented (https://maven.apache.org/guides/introduction/introduction-to-profiles.html):

This profile will automatically be active for all builds unless another profile in the same POM is activated using one of the previously described methods. All profiles that are active by default are automatically deactivated when a profile in the POM is activated on the command line or through its activation config.

Counterintuitive, but it’s like that, like it or not.

However, the documentation also tells you how to achieve the “really active by default”; it’s a matter of activating the profile when a property is NOT defined. Let’s create another profile following this approach:

And verify that:

The profile we’ve just added will be activated when the system property “skipMe” is not defined. So, it’s really active by default unless you pass to the command line “-DskipMe”.

Note also that the “<activeByDefault>” property is really misleading. In fact, as long as another profile is automatically activated (i.e., not explicitly), the “<activeByDefault>” is useless. In fact, with the profile we’ve just active since it’s really active by default, it also disables, by default, “notReallyActiveByDefault”:

Let’s do some further experiments and add another profile, which is activated when the property “activateMe” is defined:

Let’s define the property on the command line, and we get the expected result:

We can also refine the activation:

If we define that property, the profile will be activated, and if we define that property with another value, it will not be activated (in any case, “reallyActiveByDefault” is still activated):

REMEMBER: You CANNOT activate that profile by defining a property in the POM, though:

If you want, you can temporarily switch the activation with a negated property, similar to what we’ve done before:

And verify the expected result:

That’s the complete example of POM:

However, please remember not to abuse profiles, or the build will easily become hard to maintain.

A first look at XeroLinux

Leave a reply

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!

Installation

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, https://github.com/xerolinux/calamares-config/pull/1. 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, https://forum.xerolinux.xyz/thread-184.html. 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 https://github.com/xerolinux/xerolinux_repo/tree/main/x86_64. 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 https://github.com/xerolinux/kde-wallpapers/tree/main/usr/share/wallpapers):

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

Leave a reply

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

Leave a reply

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

Leave a reply

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: https://github.com/LorenzoBettini/ansible-molecule-gitpod-example.

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 “quay.io/centos/centos:stream8“):

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 https://gitpod.io/#.

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 (“quay.io/centos/centos:stream8“). 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 https://www.gitpod.io/docs/introduction/getting-started. 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

8 Replies

UPDATED 22/Dec/2022, ChangeLog:

  • 22/Dec/2022: added the flag “-czstd” for defragmentation and compression.
  • 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

into

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):