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.

Dropbox and Gnome 42

Now that Gnome 42 has been released and available in most Linux distributions, I started experiencing problems with the Dropbox icon in the system tray.

First of all, I have no problem with Ubuntu 22.04, which comes with the extension “AppIndicator and KStatusNotifierItem Support” https://extensions.gnome.org/extension/615/appindicator-support/. Moreover, I think the problem is not there because, while Ubuntu 22.04 ships Gnome 42, it still ships Nautilus in version 41.

In Fedora and EndeavourOS, I usually install the same extension in the Gnome DE, and it has been working quite well.

Unfortunately, with Gnome 42 (provided by Fedora 36 and currently by EndeavourOS), I started experiencing problems, even with the extension above installed and activated.

If you had already installed Dropbox in your Gnome 41 DE and upgraded to Gnome 42 (e.g., you upgraded Fedora 35 to Fedora 36 after installing Dropbox), the icon is clickable. Still, you get a context menu always saying “Connecting…”

At least you can access “Preferences…”.

However, suppose you had never installed Dropbox in that Gnome 42 environment. In that case, the icon in the system tray appears (again, after installing the above extension), but no matter how you click on that, no context menu appears at all. That’s a disgrace because you cannot access Dropbox preferences, like “selective sync” (you have to use the command line, as I suggested in the previous post).

Instead of the extension “AppIndicator and KStatusNotifierItem Support” (disable it if you had already activated that), you can use the extension “Tray Icons: Reloaded,” https://extensions.gnome.org/extension/2890/tray-icons-reloaded/. Install it, activate it, logout and login, and now the context menu works as expected:

Remember that this extension does not seem to support all system tray icons. For example, Variety does not seem to be supported.

At least you can use this extension to set up Dropbox (e.g., selective sync) and then go back to the previous extension!

Testing the new Fedora 36

Fedora 36 has just been released, and I couldn’t resist trying it right away. I had already started using Fedora 35 daily (though I have several Linux distributions installed), and I’ve been enjoying it so far.

Before upgrading my Fedora 35 installations, I decided to install Fedora 36 on a virtual machine with VirtualBox.

These are a few screenshots of the installation procedure.

As usual, you’re greeted by a dialog for installing or trying Fedora, and I went for the latter.

The installation procedure is available from the dock:

To be honest, I’m not a big fan of the Fedora installer: compared to other installers like Ubuntu and EndeavourOS or Manjaro, I find the Fedora installer much more confusing. Maybe it’s just that I’m not used to such an installer, but I never had problems with Calamares in EndeavourOS or Manjaro, not even the very first time I tried Calamares.

For example, once a subsection is selected, the button “Done” is at the upper left corner, why I would expect buttons at the bottom (right).

I appreciate that you can select the NTP server time synchronization (at my University, I cannot use external NTP servers, and in fact, the default one is not working: I have to use the one provided by my University). Unfortunately, this setting does not seem to be persisted in the installed system. UPDATE 12/May: Actually it is persisted: I thought I’d find it in the file /etc/systemd/timesyncd.conf but instead it is in /etc/chrony.conf. Well done!

Since I’m installing the system on a VM hard disk for the partitioning, I chose the “Automatic” configuration. On a real computer, I’d go for manual partitioning. Even in this task, the Fedora installer is a bit confusing. Maybe the “Advanced Custom (Blivet GUI)” is more accessible than the default “Custom” GUI, or, at least, it’s much similar to what I’m accustomed to.

Finally, we’re ready to start the installation.

Even on a virtual machine, the installation does not take that long.

Once rebooted (actually, in the virtual machine, the first reboot did not succeed, and I had to force the shutdown of the VM), you’re greeted by a Welcome program. This program allows you to configure a few things, including enabling 3rd party repositories and online accounts and specifying your user account.

Then, there is the Gnome welcome tour, which I’ll skip here.

Here is the information about the installed system. As you can see, Fedora ships with the brand new Gnome 42 and with Wayland by default:

Fedora uses offline updates, so once notified of updates, you have to restart the system, and the updates will be installed on the next boot:

The installation is not bloated with too much software. Gnome 42 new theme looks fine, with folder icons in blue (instead of the old-fashioned light brown). Fedora also ships with the new Gnome Text Editor. Differently from the old Gedit, the new text editor finally allows you to increase/decrease the font size with Ctrl and +/-, respectively. I cannot believe Gedit did not provide such a mechanism. I used to install Kate in Gnome because I was not too fond of Gedit for that missing feature.

Instead, Fedora does not install the new Gnome terminal (gnome-console) by default. I installed that with DNF, and I wouldn’t say I liked it that much: with Ctrl +/-, you can zoom the terminal’s font, but the terminal does not resize accordingly. For that reason, I prefer to stay with the good old Gnome terminal (gnome-terminal).

First impressions

First of all, although I tried this installation in a VM, Fedora 36 seems pretty responsive and efficient. I might even say that the guest Fedora 36 VM looked faster than my host (Ubuntu 22.04). Maybe that was just an impression 😉

Since I chose the Automatic partitioning, Fedora created two BTRFS subvolumes (one for / and one for /home) with compression, and a separate ext4 /boot partition:

It also uses swap on zram:

I soon installed the extension “AppIndicator, KStatusNotifierItem and legacy Tray icons support to the Shell” by Ubuntu (https://extensions.gnome.org/extension/615/appindicator-support/) and it works in Gnome 42.

However, after installing Dropbox, while the icon shows on the system tray, clicking on that Dropbox icon (left or right-click or double-click) does not make the context menu appear, making that unusable. I seem to understand that it is a known problem, and maybe they are already working on that. For the time being, if you need the Dropbox context menu for settings like “selective sync,” you’re out of luck. However, you can use the dropbox command-line program for the settings. In that case, I first ignore all the folders and then remove the exclusion for the folders I want to have in sync.

For example, I only want “Screenshot” and “sync” from my Dropbox on my local computer, and I run:

On a side note, I find the Dropbox support for Linux a kind of an insult…

I look forward to upgrading my existing Fedora 35 installations on my computers, and maybe I’ll get back with more impressions on Fedora 36 on real hardware.

For the moment, it looks promising 🙂

Mirror Eclipse p2 repositories with Tycho

I had previously written about mirroring Eclipse p2 repositories (see this blog tag), but I’ll show how to do that with Tycho and one of its plugins in this post.

The goal is always the same: speed up my Maven/Tycho builds that depend on target platforms and insulate me from external servers.

The source code of this example can be found here: https://github.com/LorenzoBettini/tycho-mirror-example.

I will show how to create a mirror of a few features and bundles from a few p2 repositories so that I can then resolve a target definition file against the mirror. In the POM, I will also create a version of the target definition file modified to use the local mirror (using Ant). Moreover, I will also use a Tycho goal to validate such a modified target definition file against the local mirror. The overall procedure is also automatized in the CI (GitHub Actions). This way, we are confident that we will create a mirror that can be used locally for our builds.

First of all, let’s see the target platform I want to use during my Maven/Tycho builds. The target platform definition file is taken from my project Edelta, based on Xtext.

As you see, it’s rather complex and relies on several p2 repositories. The last repository is the Orbit repository; although it does not list any installable units, that is still required to resolve dependencies of Epsilon (see the last but one location). We have to consider this when defining our mirroring strategy.

As usual, we define a few properties at the beginning of the POM for specifying the versions of the plugin and the parts of the p2 update site we will mirror from:

Let’s configure the Tycho plugin for mirroring (see the documentation of the plugin for all the details of the configuration):

The mirror will be generated in the user home subdirectory “eclipse-mirrors” (<destination> tag); we also define a few other mirroring options. Note that in this example, we cannot mirror only the latest versions of bundles (<latestVersionOnly>), as detailed in the comment in the POM. We also avoid mirroring the entire contents of the update sites (it would be too much). That’s why we specify single installable units. Remember that also dependencies of the listed installable units will be mirrored, so it is enough to list the main ones. You might note differences between the installable units specified in the target platform definition and those listed in the plugin configuration. Indeed, the target platform file could also be simplified accordingly, but I just wanted to have slight differences to experiment with.

If you write the above configuration in a POM file (a <packaging>pom</packaging> will be enough), you can already build the mirror running:

Remember that the mirroring process will take several minutes depending on your Internet connection speed since it will have to download about 500 Mb of data.

You can verify that all the specified repositories are needed to create the mirror correctly. For example, try to remove this part from the POM:

Try to create the mirror, and you should see this warning message because some requirements of Epsilon bundles cannot be resolved:

Those requirements are found in the Orbit p2 repository, which we have just removed for testing purposes.

Unfortunately, I found no way to make the build fail in such cases, even because it’s just a warning, not an error. I guess this is a limitation of the Eclipse mirroring mechanism. However, we will now see how to verify that the mirror contains all the needed software using another mechanism.

We create a modified version of our target definition file pointing to our local mirror. To do that, we create an Ant file (create_local_target.ant):

Note that this also handles path separators in Windows correctly. The idea is to replace lines of the shape <repository location=”https://…”/> with <repository location=”file:/…/eclipse-mirrors”/>. This file assumes the original target file is example.target, and the modified file is generated into local.target.

Let’s call this Ant script from the POM:

Finally, let’s use Tycho to validate the local.target file (see the documentation of the goal):

Now, if we run:

we build the mirror, and we create the local.target file.

Then, we can run the above goal explicitly to verify everything:

If this goal also succeeds, we managed to create a local mirror that we can use in our local builds. Of course, in the parent POM of your project, you must configure the build so that you can switch to local.target instead of using your standard .target file. (You might want to look at the parent POM of my Edelta project to take some inspiration.)

Since we should not trust a test that we never saw failing (see also my TDD book 🙂 let’s try to verify with the incomplete mirror that we learned to create by removing the Orbit URL. We should see that our local target platform cannot be validated:

Alternatively, let’s try to build our mirror with <latestVersionOnly>true</latestVersionOnly>, and during the validation of the target platform, we get:

In fact, we mirror only the latest version of org.antlr.runtime (4.7.2.v20200218-0804), which does not satisfy that requirement. That’s why we must use with <latestVersionOnly>false</latestVersionOnly> in this example.

For completeness, this is the full POM:

And this is the YAML file to build and verify in GitHub Actions:

I hope you found this post valuable, and happy mirroring! 🙂

Multibooting with GRUB

Besides Windows (which I rarely use) on my computers, I have a few Linux distributions. Grub 2 does a good job in booting Windows and Linux, especially thanks to os-prober, in autodetecting other operating systems in other partitions of the same computer. However, there are a few “buts” in this strategy:

  1. Typically, the last installed Linux distribution, say L1, installs its own grub as the main one, and when you upgrade the kernel in another Linux distribution, say L2, you have to boot into L1 and “update-grub” so that the main grub configuration learns about the new kernel of L2. Only then can you boot the new kernel of L2. Of course, you can change the main grub by reordering the EFI entries, e.g., by using the computer’s BIOS, but again that’s far from optimal.
  2. Not all Linux distributions’ grub configurations can boot other Linux distributions. For example, Arch-based distros like EndeavourOS and Manjaro can boot Ubuntu-based distros, but not the other way round (unless you fix a few things in the grub configuration of Ubuntu)! Recently, I started to use also Fedora. I found out that os-prober in Ubuntu and EndeavourOS does not detect the configurations correctly to boot Fedora: recently, Fedora switched to “blscfg” (https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault), and as a result, Ubuntu and EndeavourOS create grub configurations that do not consider the changes you made in Fedora’s /etc/default/grub.

That’s why I started to experiment with grub configurations. I still have a “main grub” in a Linux installation, which simply “delegates” to the grub configurations of the other Linux installations. This way, I solve both the two problems above!

In this blog post, I’ll show how I did that. Note that this assumes you use EFI boot.

I have Windows 10, Kubuntu, EndeavourOS, and Fedora on the same computer in this example. I will configure the grub installation of Fedora so that it delegates to Windows, Kubuntu, and EndeavourOS, without relying on os-prober.

This is the disk layout of my computer so that you understand the numbers in the grub configuration that I’ll show later (I omit other partitions like Windows recovery).

The key point is modifying the file /etc/grub.d/40_custom. I guess you already know that you should not modify directly grub.cfg, because a system update or a grub update (e.g., “update-grub”) will overwrite that file.

The file /etc/grub.d/40_custom already comes with some contents that must be left as they are: you add your lines after the existing ones. For example, in Fedora, you have:

We will use the option configfile of grub configuration (see https://www.gnu.org/software/grub/manual/grub/grub.html#configfile): “Load file as a configuration file. If file defines any menu entries, then show a menu containing them immediately.” The Arch wiki also explains it well:

If the other distribution has already a valid /boot folder with installed GRUB, grub.cfg, kernel and initramfs, GRUB can be instructed to load these other grub.cfg files on-the-fly during boot.

The idea is to put in /etc/grub.d/40_custom an entry for each Linux distribution, pointing to the grub.cfg of that distribution, after setting the root partition. Thus, the path to the grub.cfg must be intended as an absolute path in that partition. If you look at the partition numbers above, these are the two entries for booting EndeavourOS and Kubuntu:

NOTE: the “rmmod tpm” is required to avoid TPM errors when booting those systems (“Unknown TPM error”, “you need to load the kernel first”). It happened on my Dell XPS 13, for example. Adding that line (i.e., not loading the module “tpm”) solved the problem.

Remember that the path assumes that the /boot directory is not mounted on a separate partition. If instead, that’s the case, you probably have to remove “/boot”, but I haven’t tried that.

Concerning the entry for Windows, here it is:

In this entry, the root must correspond to the EFI partition, NOT to the partition of Windows.

Save the file and regenerate the grub configuration. In other Linux distributions, it would be a matter of running “update-grub,” but in Fedora, it is:

Now reboot, and you should see the grub menu of Fedora and then, at the bottom, the entries for EndeavourOS, Kubuntu, and Windows. Choosing “EndeavourOS” or “Kubuntu” will NOT boot directly in these systems: it will show the grub menu of “EndeavourOS” or “Kubuntu.”

If you upgrade the kernel on one of these two systems, their grub configuration will be correctly updated. There’s no need to boot into Fedora to update its grub configuration 🙂

If you want to configure the grub in another Linux distribution, please remember that Fedora stores the grub.cfg in /boot/grub2 instead of /boot/grub, so you should write the entry for Fedora with the right path. However, if you plan to boot Fedora with this mechanism, you should disable “blscfg” in the Fedora grub configuration, or you will not be able to boot Fedora (errors “increment.mod” and “blscfg.mod” not found).

Now that we verified that it works, we can remove the entries generated by os-prober. In /etc/default/grub add the line:

and regenerate the grub configuration.

If you want grub to remember the last choice, you can look at this post.

On a side note, due to the way Fedora uses grub (https://fedoraproject.org/wiki/Changes/HiddenGrubMenu), without os-prober, you will not see the grub menu unless you press ESC. After the timeout, it will simply boot on the default entry. To avoid that and see the grub menu, just run:

And the grub menu will get back as usual.

Then, you can also remove os-prober in the other Linux installations, since that is useless now.

These were the original grub menus of Fedora and EndeavourOS, before applying the modifications described in this post:

Pretty crowded!

And this is the result after the procedure described in this post (note that from the Fedora grub menu you select EndeavourOS to land its grub menu and Kubuntu to land its grub menu):

Much better! 🙂

 

Getting started with KVM and Virtual Machine Manager

After playing with VirtualBox (see my posts), I’ve decided to try also KVM (based on QEMU) and Virtual Machine Manager (virt-manager).

The installation is straightforward.

In Ubuntu systems:

In Arch-based systems:

Then, you need to add your user to the corresponding group:

Reboot, and you’re good to go.

In this post, I’m going to install Fedora 35 on a virtual machine through Virtual Machine Manager (based on KVM and QEMU).

So, first, download the ISO of this distribution if you want to follow along.

Let’s start Virtual Machine Manager (virt-manager):

Press the “+” button to create a new virtual machine, and we select the first entry since we have downloaded an ISO.

Here, we select the ISO and let the manager detect the installed OS. Otherwise, we can choose the OS manually (the manager might not catch the OS correctly in some cases: it happened to me with ArcoLinux, for example).

Then, we allocate some resources. Since I have 16GB and a quad-core, I give the virtual machine 8GB and two cores.

Then, we allocate storage for the machine. Alternatively, we can select or create a custom image file in another location. By default, the image will NOT occupy the whole space physically on your disk. Thus, I will not lose 60GB (unless I’ll effectively use such a space on the virtual machine). The file will appear of the specified size on your drive, but if you check the free disk space on your drive, you will note that you haven’t lost so many Gigas (more on that in the next steps).

In the last step, we can give a custom name to our machine and customize a few settings before starting the installation by selecting the appropriate checkbox (we also make sure that the network is configured correctly).

If we selected “Customize configuration before install,” by pressing “Finish,” we get to the settings of our virtual machine.

In this example, I’m going to change the chipset and specify a UEFI firmware:

We can also get other information, like the path of the disk image:

And we can click “Begin Installation.” After the boot menu, we’ll get to the live environment of the distribution ISO we chose:

You can also specify to resize the display of the VM automatically if you resize the window and when to do that. (WARNING: this will work correctly only after installing the OS in the virtual machine since this feature requires some software in the guest operating system. Typically, such a software, spice-vdagent, is automatically installed in the guest during the OS installation, from what I’ve seen in my experiments.)

And we can start the installation of the distribution (or try it live before the actual installation), as usual. Of course, the whole installation process will be a bit slower than on real hardware.

I’ll choose the “Automatic” choice for disk partitioning since the disk image will be allocated only to this machine, so I will not bother customizing that.

While installing, you might want to check the disk image size and the effective space on the disk:

After a few minutes, the installation should be complete, and we can reboot our virtual machine

And upon reboot, we’ll get to our new installed OS on the virtual machine:

In the primary Virtual Machine Manager window, you can see your virtual machines, and, if they are running, a few statistics:

In the virtual machine window’s “View” menu, you can switch between the “Console” view (that is, the virtual machine installed and running OS) and the “Details” view, where you can see its settings, and change a few of them.

Note that now the automatic resize of the machine display and the window works: in the screenshot I resized the window (made it bigger) and the display of the machine resized accordingly.

When you later restart a virtual machine from the manager, you might have to double-click on the virtual machine element and possibly switch to the “Console” view.

After installing the OS, you might want to check the image file and the actual disk usage again. You will find that while the image file size did not change, the disk usage has:

What I’ve shown in this blog post was one of my first experiments with KVM and the Virtual Machine Manager. To be honest, I still prefer VirtualBox, but maybe that’s only because I’m more used to VirtualBox, while I’ve just started using virt-manager.

That’s all for now! Stay tuned for further posts on KVM and virt-manager, and happy virtualization! 🙂

Limiting Battery Charge on LG Gram in Linux

I’ve been using this laptop for some months now (see my other posts). In Windows, you can easily set the battery charge limit to 80% using the LG Gram control center. In Linux, I did not find any specific configuration in any system settings in any DE (not even in KDE Plasma, where, for some laptops, there’s support for setting the battery charge limit).

However, since kernel 5.15, you can do it yourself, thanks to some specific LG Gram kernel features, https://www.kernel.org/doc/html/latest/admin-guide/laptops/lg-laptop.html:

Writing 80/100 to /sys/devices/platform/lg-laptop/battery_care_limit sets the maximum capacity to charge the battery. Limiting the charge reduces battery capacity loss over time.

This value is reset to 100 when the kernel boots.

So you need to write ’80’ in that file. I do that like that:

After that, you can see that when charging reaches 80%, the laptop will not charge the battery anymore. Depending on the DE, either you see the charging notice disappear, or the charging stuck at 80%. The DE might even tell you that it still needs some time until fully charged, but you can ignore that. That notice will stay like that, as shown in these two screenshots (KDE Plasma), taken at different times:

Note that in the quotation shown above, you also read

This value is reset to 100 when the kernel boots.

If you reboot, the value in that file will go back to ‘100’, and charging will effectively continue. Note that this also holds if you hibernate (suspend to disk) the laptop since when you restart it from hibernate, you’ll boot it anyway, so that will reset the value in the file. However, if you put the laptop to sleep, the value in the file will not change.

Above I said that you need kernel 5.15. I think the feature described above was introduced even before, but in kernel 5.13, that does not seem to work: no matter what you write in that file, the change will not be persisted. In my experience, this only works starting from kernel 5.15.

With kernel 5.15, it works for me in EndeavourOS, Manjaro, and Kubuntu.

Linux EndeavourOS review

I’ve been using Linux EndeavourOS (the latest version, “Atlantis neo”) for a few days now, and I love it!

I mainly use Ubuntu and Kubuntu, but I recently enjoyed Manjaro, an Arch-based distro. I still haven’t tried to install the pure Arch distribution, but I learned about EndeavourOS, an Arch-based distro, which is pure Arch. For sure, it’s more Arch than Manjaro since EndeavourOS uses the Arch repositories, plus a small EndeavourOS repository. On the contrary, Manjaro heavily relies on its independent repositories (which also contain software packages not provided by Arch). So, they’re both rolling releases, but EndeavourOS is Arch but with a much simpler installation procedure.

I’ll first briefly recap the installation procedure and then do a short review.

Installation

The installation starts with an XFCE desktop and a dialog where you can set a few things, including the screen resolution in case you need to:

Now it’s time to connect to the Internet, e.g., with a WIFI (the setting will be remembered in the final installation so that you will not have to re-enter the WIFI username and password).

Then, we can start the installer:

I prefer to choose “Online” so that I can select a different desktop environment (I don’t use XFCE, which is the only choice if you perform the “Offline” method):

One of the exciting aspects of the EndeavourOS installation process is that it automatically shows a terminal with the log. This terminal can be helpful to debug possible installation problems.

The installer is Calamares, which you might already know if you used Manjaro.

I’m going to show only the interesting parts of the installation.

The partitioning already found the main SSD drive.

Since I have a few Linux installations already on this computer, I choose to replace one of them with EndeavourOS.

In particular, I select the Manjaro Linux (21.2rc) checkbox to replace that installation (see the “Current:” and the “After:” parts):

Since I chose the “Online” installer, I can now select the software to install. Note the printing support software:

I also decide to install both KDE and GNOME (maybe I’ll blog in the future about the coexistence of the two desktop environments). That’s another exciting feature of EndeavourOS: it lets you install as many desktop environments as you want right during the installation. Other distributions typically only provide ISOs for specific desktop environments (the so-called “spins”).

If you expand the nodes in the tree, you can see the installed software for each DE. I can anticipate that for both KDE and GNOME, the installed programs are not so many.

Time for looking at the summary, and then we’re good to start the installation, which takes only a few minutes on my computer.

Review

As I have already anticipated, I’m enjoying this distribution so far.

I mainly use the KDE Plasma desktop. Plasma looks like it is very close to vanilla Plasma in this distribution. It does not come with many preinstalled KDE software, but all the necessary KDE applications are there.

I had to install a few additional KDE applications I like to have. The corresponding packages are plasma-systemmonitor, kdeplasma-addons (for other task switchers), and kcalc.

Of course, pacman is already installed, but you also have yay already installed.

Since I like the GUI front-end pamac, I had to install that manually:

Remember that, besides an EndeavourOS repository, everything else comes from the official Arch repositories.

EndeavourOS ships with the latest Linux kernel 5.15, and on my computers, it works like a charm.

The “Welcome” application automatically appears when you log in, and it provides a few helpful buttons: for updating the mirrors, the packages, and configuring package cache cleaning:

For updating the software packages, yay will start in a terminal window. Indeed, EndeavourOS defines itself as a “terminal-centric distro.”

Speaking about software updates, you get a system tray notification when they are available:

But unfortunately, clicking on that does not do anything: you have to update the software manually (e.g., by using the above-mentioned “Welcome” app).

Another minor defect (if I have to find defects) is the empty icon on the panel: it refers to the KDE “Discover” application, which is not installed by default. That is confusing, and probably the installation should have taken care of not putting it there by default.

Besides that, I enjoy the KDE Plasma experience provided by EndeavourOS.

Concerning GNOME, again, the installed software is minimal, but you get the essential software, including Gnome Tweaks. No specific GNOME extensions are provided, but you can install them yourself. In the end, it’s vanilla GNOME.

All in all, I guess I’ll be using EndeavourOS as my daily driver in the next few days!

I hope you try EndeavourOS yourself and enjoy it as much as I do 🙂

How to install Linux on a USB drive with UEFI support using VirtualBox

That’s the third post on installing Linux on a USB drive!

Remember that the idea is to have a USB drive that will work as a portable Linux operating system on any computer.

In the first post, How to install Linux on a USB drive using Virtualbox, the USB drive with Linux installed could be used when booting from a computer with “Legacy boot” enabled: it could not boot if UEFI were the only choice in that computer.

In the second post, How to install Linux on a USB with UEFI support, I showed how to install Linux on the USB drive directly, without using VirtualBox, while creating a UEFI bootable device. However, you had to be careful during the installation to avoid overwriting the UEFI boot loader of your computer.

In this post, I’ll show how to install Linux on a USB drive, with UEFI support, using VirtualBox. In the end, we’ll get a UEFI bootable device, but without being scared of breaking the UEFI boot loader of your computer, since we’ll do that using a virtual machine.

The scenario

First of all, let’s summarize what I want to do. I want to install Linux on a portable external USB SSD. I don’t want a live distribution: a live distribution only allows you a little testing experience, it’s not easily maintainable and upgradable, it’s harder to keep your data in there. On the contrary, installing Linux on a USB drive will give you the whole experience (and if the USB drive is fast, it’s almost like using Linux on a standard computer; that’s undoubtedly the case for an external SSD, which are pretty cheap nowadays).

In the previous post, I described how to create such an installation from VirtualBox. As I said, you can boot the USB drive only in Legacy mode. This time, we’ll be able to boot the USB drive in any UEFI computer.

I’m going to perform this experiment:

  • I’m going to use VirtualBox installed on a Dell XPS 13 where I already have (in multi-boot, UEFI), Windows, Ubuntu, Kubuntu, and Manjaro GNOME
  • I’m going to install Ubuntu 21.10 into an external USB SanDisk SSD (256 Gb)
  • then I’m going to install on the same external USB drive also EndeavourOS (an excellent distribution I’ve just started to enjoy) along with the installed Ubuntu

I have already downloaded the two distributions’ ISOs.

I’ve installed VirtualBox in Ubuntu following this procedure

and then reboot.

By the way, since the second distribution will take precedence over an existing UEFI configuration on the USB, it’s better to start with Ubuntu and then proceed with EndeavourOS (Arch based). While an Arch GRUB configuration has no problem booting other distributions, Ubuntu cannot boot an Arch-based distribution. Of course, the second distribution’s GRUB menu will let you also boot the first one. We could solve the booting problem later, but I prefer to keep things easy and install them in the above order.

In the screenshots of the running virtual machine, the USB SanDisk is /dev/sda.

I will boot a virtual machine where I set the ISO of the current distribution as a LIVE CD. I’m going to use a different virtual machine for each distribution. Maybe that’s not strictly required, but since the two OSes are different (the first one is an Ubuntu OS, while the second one is an Arch Linux), I prefer to keep the two virtual machines separate, just in case.

Create the first virtual machine and install Ubuntu on the USB drive

I’m assuming you’re already familiar with VirtualBox, so I’ll post the main screenshots of the procedure.

Let’s create a virtual machine.

We don’t need a hard disk in the virtual machine since we’ll use it only for installing Linux on a USB drive, so we’ll ignore the warning.

.

Now it’s time to configure a few settings.

The important setting is “Enable EFI” to make our virtual machine aware of UEFI, and the booted Live OS will also be aware of it. As we will see later, the booted Live OS will correctly install GRUB in a UEFI partition.

We also specify to insert the ISO of the distribution (Ubuntu 21.10) so that when the virtual machine starts, it will boot the Live ISO.

Let’s start the virtual machine, and we will see the boot menu of the Live ISO.

We choose to Try Ubuntu, and then we plug the external SanDisk in the computer, and we make the virtual machine aware of that by using the context menu of the USB connection icon and selecting the item corresponding to the USB hard disk (in your case it will be different)

After that, the Ubuntu Live OS should notify about the connected disk. We can start the installation, and when it comes to the disk selection and partition, I chose to erase the entire disk and install Ubuntu:

Of course, you can choose to partition the hard disk manually, but then you’ll have to remember to create a GPT partition table, and you’ll also have to create the FAT32 partition for UEFI manually. By using “Erase disk and install Ubuntu,” I’ll let the installer do all this work.

You can see the summary before actually performing the partition creation. Note that we are doing such operations on the external USB drive, which, as I said above, corresponds to /dev/sda.

Now, we have to wait for the installation to finish. In the end, instead of restarting the virtual machine, we shut it down.

Let’s restart the computer with the USB drive connected. Depending on the computer setup, you’ll have to press some function key (e.g., F2 or, in my Dell XPS 13, F12, to choose to boot from a different device). Here’s the menu in my Dell XPS 13, where we can see that the external USB (SanDisk) is detected as a UEFI bootable device. It’s also detected as a Legacy boot device, but we’re interested in the UEFI one:

We can then verify that we can boot the Ubuntu distribution installed in the USB drive.

By the way, I also verified that, without the USB drive connected, I can always boot my computer: indeed, the existing UEFI Grub configuration is intact (remember, I have Windows, Ubuntu, Kubuntu, and Manjaro GNOME; the grub menu with higher priority is the one of Manjaro):

Create the second virtual machine and install EndeavourOS on the USB drive

Let’s create the second virtual machine to install on the same USB drive EndeavourOS, along with the Ubuntu we have just installed.

To speed up things, instead of creating a brand new machine, we clone the previous one, and we change a few settings (basically the name, the version of Linux, which now is Arch, and finally we change the Live ISO):

Let’s start the virtual machine and land into the EndeavourOS Live system

As before, we have to connect the USB drive to the computer and let the virtual machine detect that (see the procedure already shown in the first installation section).

We start the installer and choose the “Online” version so that we can choose what to install next (including several Desktop Environments). The installer is Calamares (if you used Manjaro before, you already know this installer).

When it comes to the partitioning part, we make sure we select the SanDisk external drive (as usual, /dev/sda). Note that the installer detects the existing Ubuntu installation. This time, we choose to install EndeavourOS alongside:

And we use the slider to specify how much space the new installation should take:

Let’s select a few packages to install (a cool feature of EndeavourOS)

And this is the summary before starting the installation:

Once the installation has finished, we shut down the virtual machine and reboot the computer with the USB drive inserted. This time we see the EndeavourOS grub configuration, including the previously installed Ubuntu. Remember, these are the installations in the USB drive (as usual, note the /dev/sda representing the USB drive):

And now we have a USB drive with two Linux distributions installed that we can use to boot our computers! However, some drivers for some specific computer configurations might not be installed in the Linux installation of the external USB. Also, other configurations like screen resolutions and scaling might depend on the computer you’re booting and might have to be adjusted each time you test the external USB drive in a different computer.

I hope you enjoyed the tutorial!

Happy installations and Happy New Year! 🙂

Using the Unison File Synchronizer on macOS

For ages, I’ve been using the excellent Unison file synchronizer to synchronize my directories across several Linux machines, using the SSH protocol. I love it! 🙂

Unison gives you complete control over the synchronization, and, most of all, it’s a two-way synchronizer.

Quoting from its home page:

Unison is a file-synchronization tool for OSX, Unix, and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.

On Linux, I never experienced problems with Unison, especially from the installation point of view: it’s available on most distributions’ package managers. If that’s not the case, you can download a binary package from https://github.com/bcpierce00/unison/releases.

However, I had never used Unison on a macOS computer, so today, I decided to try it.

Please, keep in mind that you must use the same version of Unison on all the computers you want to synchronize (at least, I seem to understand, the major.minor version numbers must be the same on all computers, and this also includes the version of OCaml, on which Unison relies).

For macOS, you go to https://github.com/bcpierce00/unison/releases, and you download the .app.tar.gz file according to the Unison (and OCaml) version you need. The other macOS .tar.gz archives, without the .app, contain the command-line binary and a GTK UI binary, which, however, requires the GTK libraries to be already installed on your system and, to be honest, I have no idea how to do that in a compatible way. On the contrary, the .app.tar.gz contains the macOS application, which, I seem to understand, it’s self-contained.

By the way, there’s also a brew package for Unison, but that’s only the command line application, so you won’t get any UI, which is quite helpful, especially when you want to have complete control over the elements to be synchronized and you want to have the last chance to select or unselect the files before the synchronization starts. Moreover, the UI is quite helpful when you have conflicts to solve.

Then, you extract the archive, and you need to run this command (assuming you have extracted it in the Downloads folder):

otherwise, macOS will complain (with an unhelpful error message about a damaged app) since it does not recognize the archive provider.

Move the Unison.app into your Applications, and you’re good to go, assuming you already know how to use Unison.

The first time you run the app, it will ask you to install also the command-line version of Unison, which is also helpful:

And here’s a screenshot showing the files that are going to be synchronized in an example of mine (from the direction of the arrows, you can see that this is a two-way synchronization):

I find the Linux UI of Unison much simpler to understand and deal with, but maybe that’s because I’ve been using it for ages, and I still do.

Happy synchronization! 🙂

Playing with KDE Plasma Themes

I want to share some of my experiences with KDE Plasma Themes in this post.

These themes are pretty powerful, but, as it often happens with KDE and its configuration capabilities, it might not be immediately clear how to benefit from all its power and all its themes’ power.

I’m assuming that you already enabled the KWin Blur effect (In “Desktop Effects”), which is usually the case by default. Please remember that desktop effects, like “blur,” applied to menus, windows, etc., will use more CPU. This CPU usage might increase battery usage (but, at least from my findings, it’s not that much).

First, installing a theme using “Get New Global Themes…” is not ideal. In my experiments, the installation often makes the System Settings crash; the artifacts of the theme might be out of date concerning the current Plasma version. Moreover, the installation usually does not install other required artifacts, like icons and, most of all, the Kvantum theme corresponding to the Plasma theme. In particular, the themes that I use in this post all come with the corresponding Kvantum theme. Using such an additional theme configuration is crucial to enjoying that Plasma theme thoroughly.

Thus, I’ll always install themes and icons from sources in this post.

I mentioned Kvantum, which you have to install first. In recent Ubuntu distributions

In other distributions, the package(s) names might be different.

Quoting from Kvantum site:

Kvantum […] is an SVG-based theme engine for Qt, tuned to KDE and LXQt, with an emphasis on elegance, usability and practicality. Kvantum has a default dark theme, which is inspired by the default theme of Enlightenment. Creation of realistic themes like that for KDE was my first reason to make Kvantum but it goes far beyond its default theme: you could make themes with very different looks and feels for it, whether they be photorealistic or cartoonish, 3D or flat, embellished or minimalistic, or something in between, and Kvantum will let you control almost every aspect of Qt widgets. Kvantum also comes with many other themes that are installed as root and can be selected and activated by using Kvantum Manager.

As described in https://github.com/tsujan/Kvantum/blob/master/Kvantum/INSTALL.md,

The contents of theme folders (if valid) can also be installed manually in the user’s home. The possible installation paths are ~/.config/Kvantum/$THEME_NAME/, ~/.themes/$THEME_NAME/Kvantum/ and ~/.local/share/themes/$THEME_NAME/Kvantum/, each one of which takes priority over the next one, i.e. if a theme is installed in more than one path, only the instance with the highest priority will be used by Kvantum.

On the contrary, the KDE themes artifacts are searched for in ~/.local/share. Since some of the themes we will install from the source do not provide an installation script, we will have to copy artifacts manually. In the meantime, you might want to create the Kvantum config directory (though the installation commands we will see in this post will take care of that anyway):

After Kvantum is installed, going to “Appearance” -> “Application Style,” you’ll see the kvantum style that you can select as an application style (we won’t do that right now). Once that’s set, the application style will be configured through the Kvantum Manager, which we’ll see in a minute.

So let’s start installing and playing with a few themes. As I anticipated initially, we’ll install the themes from sources. You’ll need git to do that. If not already installed, you should do that right now.

Nordic KDE

https://github.com/EliverLara/Nordic

This theme does not come with an installation script, so I’ll show all the commands to clone its source repository and manually copy its contents to the correct directories (see the note above concerning directories for Plasma and Kvantum themes):

Now, we got to “Appearance” -> “Global Theme,” and we find two new entries for the Nordic theme we’ve just installed:

Select one of the Nordic global themes (I chose “Nordic”) and press “Apply.”

Here’s the result (this is not yet the final intended look of the theme):

We can see that the menus are nicely blurred (of course, if you like blur effect 🙂

Go to “Application Style,” you see that “kvantum” is selected (that has happened automatically when selecting the “Nordic” global theme):

However, we still need to apply the Nordic Kvantum theme.

Launch Kvantum Manager, select one of the Nordic themes (Kvantum finds the Nordic Kvantum theme because we installed them in the correct position in the home folder), and press “Use this theme”:

and now everything looks consistent with the Nordic theme (the menu is still blurred). Keep in mind that applications have to be restarted to see the new theme applied to them:

Let’s make sure that applications like Dolphin are blurred themselves: go to the tab “Configure Active Theme” -> “Hacks” and make sure “Transparent Dolphin View” is selected. IMPORTANT: if you use fractional scaling in Plasma (e.g., I use 150% or 175%), you must ensure that “Disable translucency with non-integer scaling” is NOT selected.

Scroll down and press “Save”; remember to restart the applications. Now enjoy the nice translucent blurred effect in many applications (including the Kvantum manager itself); I changed the wallpaper to something lighter to appreciate the transparency better:

Of course, you can change a few Kvantum Nordic theme configurations parameters, including the opacity and other things.

You might also have to log out and log in to the Plasma session to see the theming applied to everything.

This theme also installs a Konsole color scheme, so you can create a new Konsole profile using such a color scheme: here’s the excellent result (this color scheme comes with blurred background by default):

In this example, I’m still using the standard Breeze icon theme, but of course, you might want to select a different icon theme.

Lyan

https://github.com/vinceliuice/Layan-kde

Lyan is one of my favorite themes (and one of the most appreciated in general). It’s based on the Tela icon theme (also very beautiful), https://github.com/vinceliuice/Tela-icon-theme, so we’ll have to install the icon theme first. Both come with an installation (and, in case, an uninstallation) script so that everything will be much easier! We’ll have to clone their repositories and then run the installation script.

These are the command lines to run to set them both up (note the -a in the Tela installation command: this will install all the color variants; if you only want to install the default variant or just a subset, please have a look at the project site):

Then, the procedure to apply the Global Theme and the corresponding Kvantum theme is the same as before. Once you have selected the Global Theme and the Kvantum theme for Lyan, you should get something like that:

Look at all the beautiful transparency and blur effects on Dolphin, on the title bars, and in some parts of Kate and the System Settings, not to mention the blur on menus.

WhiteSur

https://github.com/vinceliuice/WhiteSur-kde

This theme is for macOS look and feel fans. I’m not one of those but let’s try that as well 🙂

For this theme as well, we’ll install the recommended icons (we can rely on their installation scripts also in this case):

Once the corresponding Global Theme is selected, if you are using a fractional scaling like me (as I also said before), you’ll get a nasty surprise: huge borders as shown in the screenshot (independently from the selected Kvantum theme):

However, this theme comes with a few versions suitable for fractional scaling concerning “Window Decorations” (ignore the previews shown in the selection, which do not look good: that does not matter for the final result). There’s no version for my current 175% scaling, however, selecting the Window Decoration for 1.5, the borders are better, though still a bit too thick:

If you have a Window scaling factor for which there’s a specific Window Decoration of this theme, then everything looks fine. For example, with 150% scaling and by selecting the corresponding Window Decoration, the window borders look fine:

The rest of the screenshots are based on 175% scaling and the x1.5 variant. As I said, it does not look perfect, but that’s acceptable 😉

Note that if we apply this Global Theme, the installed WhiteSur icons are used as well.

After applying the Kvantum theme as before, changing the wallpaper with the one provided by this theme, and setting the Task Switcher to Large Icons here’s the result:

Please keep in mind that if you end up with thick borders, the resizing point is not exactly on the edge, but slightly inside, as shown in this screenshot:

Edna

https://gitlab.com/jomada/edna.git

This does not come with an installation script either. We’ll have to copy all the artifacts manually in the correct folders (in the following commands, directories are created as well if not already there):

This is another theme with the huge border problem when using fractional scaling:

Unfortunately, this one comes with a single version and no variant for fractional scaling. Thus, when using fractional scaling, we have to manually patch the theme: open the file ~/.local/share/aurorae/themes/Edna/Ednarc and change the lines

as follows (these values fit 150% scaling)

For 175% scaling, use the same values but this one

The windows already opened will still show the huge border, but the new windows will show smaller borders. Feel free to play with such values til you get a border size you like most. In the following screenshot, I’m using this theme together with the Tela icon (the green variant) that we installed before and I also created a new Konsole profile using the Konsole Edna color scheme (which comes with transparent background):

This theme also provides a complex Latte dock layout, with several docks. We won’t see this feature in this post, you might want to experiment with that.

Conclusions

I hope you enjoyed this tutorial and that you’ll start playing with KDE themes as well 🙂