Timeshift and grub-btrfs in Linux Arch

Leave a reply

After looking at the very nice videos of Stephen’s Tech Talks, in particular, this one https://www.youtube.com/watch?v=6wUtRkEWBwE, I decided to try to set up Timeshift, Timeshift-autosnap, and grub-btrfs in my Linux Arch installation, where I’m using BTRFS as the filesystem. These three packages allow you to have a timeshift snapshot automatically created each time you update your system; moreover, a new grub entry is automatically generated to boot into a specific snapshot.

The video mentioned above is handy, but unfortunately, some recent changes in Timeshift itself broke the behavior of the two other packages. In this post, I’ll try to show how to fix the problem and go back to a working behavior. I’ll also show an experiment using the snapshots so that, hopefully, it’s clear what’s going on in the presence of such snapshots and how to use them in case you want to revert your system.

First of all, let’s install timeshift and timeshift-autosnap (the latter depends on the former, and they are both available from AUR; I’m using the AUR helper yay here):

The first problem is that timeshift has recently changed the strategy for creating snapshots. Instead of creating them in /run/timeshift/backup/timeshift-btrfs/snapshots, it now creates them in /run/timeshift/<PID>/backup/timeshift-btrfs/snapshots, where <PID> is the PID of the Timeshift process. Each time you run Timeshift, the directory will be different, breaking grub-btrfs (which expects to find the snapshots always in the same directory).

Fortunately, there’s a workaround: we add an entry to /etc/fstab in order to mount explicitly the path /run/timeshift/backup/timeshift-btrfs/snapshots:

where, of course, <UUID> has to be replaced with the same UUID of the physical disk partition.

Reboot, and then Timeshift will also put the snapshot in that directory (besides the one with the PID, as mentioned above). You can try to create a snapshot to verify that (this also allows us to use the Timeshift wizard so that we specify to create BTRFS snapshots).

Let’s make sure the mount point is active (and note the unit name)

Let’s now install grub-btrfs

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

The file contents

should be replaced with

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

If we have already created a few snapshots, we can run update-grub (or, if you have not installed the package update-grub, use the command “grub-mkconfig -o /boot/grub/grub.cfg”) and verify that new grub entries are created for the found snapshots:

We can also restart the system and prove that we can access the GRUB submenu with the generated entries for the snapshots.

IMPORTANT: If you have several Linux distributions on your computer and you use a multiboot system like the one I blogged about, and this distribution is not the main one, you will have to manually tweak the entry in your main distribution’s GRUB menu. See the linked blog post near the end.

Some experiments

Let’s do some experiments with this configuration.

Here’s the kernel I’m currently running:

I’m updating the system (I’m skipping some output below, and you can ignore the “stale mount” errors):

So it created a snapshot before updating the system (in particular, it installed a new kernel version). Let’s reboot and verify we are running the new kernel (5.18.8 instead of 5.18.7):

Let’s reboot and select from GRUB the latest snapshot (remember, the one before applying the upgrade), so timeshift-btrfs/snapshots/2022-07-02_15-35-53 (snapshots are presented in the grub submenu from the most recent to the oldest one). We do that by pretending that the update broke the system (it’s not the case), and we want to get back to a working system before the update we have just performed.

You see that the “Authentication Required” dialog greets us, and in the background, you can see the notification that we “booted into Timeshift Snapshot, please restore the snapshot”:

The password is required because it’s trying to run Timeshift:

In the screenshot, you can see that we are now using the older kernel since we booted in that snapshot where the update has not yet been performed. We have to restore the snapshot manually; otherwise, on the next boot, we’ll get back to the updated system version and not in the snapshot anymore.

So, let’s restore the snapshot:

You see, Timeshift has just created another snapshot ([LIVE]). We now reboot normally (that is, using the main grub entry, NOT the snapshot entries).

Once rebooted normally, we can verify again that we are running the old kernel:

Let’s have a look at Timeshift, and we can see the last snapshot is an effective one, not a LIVE one:

Yes, we are now in a system where the update above has never been applied.

Let’s try to rerun the update command (we don’t effectively execute the update, it’s just an experiment):

Why? Because the snapshot had been created automatically by timeshift-autosnap before applying the updates while the package manager was running, its lock is still there.

Let’s remove the lock and try to rerun the update:

The output is similar to the one shown above (unless there are even more new updates in the meantime, which might happen in a rolling release), but something is missing:

Why? Because the downloaded packages in the cache are NOT part of the saved snapshot, they are still present in the current system, even though we restored the snapshot. Why are the cached packages still there, but the lock has been restored with the snapshot? That’s due to the way subvolumes are specified in the /etc/fstab:

You see, the cache of downloaded packages and the logs are NOT part of the snapshots, while /var/lib (including the pacman lock) is part of the snapshots.

Let’s now revert the snapshot: we select the one with “Before restoring…”.

Again, we are now in a LIVE situation, and Timeshift tells us again to reboot to make it effective.

Let’s reboot (normally, by using the main grub entry).

We’re back to the updated system, and there’s nothing to update (again, unless new updates have been made available in the meantime):

If we’re happy with the updated system, we can also remove those two snapshots (remember that grub-btrfs monitors the snapshots so that it will update its grub submenu entries):

I hope you find this blog post helpful, and I hope it complements the wonderful video of Stephen’s Tech Talks mentioned above.

KDE Plasma 5.25 in Arch

Leave a reply

After the recent release of KDE Plasma 5.25, this version landed a few days ago in Arch-based distros like EndeavourOS (the one I’m writing from).

Although I’m mostly a GNOME user, I also have a few distributions installed where I’m using KDE Plasma.

The new features that impressed me most are related to eye candies 🙂

First, the “Present Windows” effect now looks the same as the new “Overview” effect. If we compare the “Present Windows” effect in the previous version (5.24):

with the new one:

we can see a significant improvement: in the earlier versions, the windows not selected were too dark, making it hard to distinguish them. This behavior relates to an old bug (10 years old): https://bugs.kde.org/show_bug.cgi?id=303438. This bug has been fixed by rewriting this effect “to use the same modern, maintainable backend technology found in the Overview effect.”

I use this effect a lot (I also configured the “Super” key to use this effect, simulating what happens in Gnome for its “Activities” view), and I use the filter to filter the open windows quickly. So I appreciate this usability change a lot!

One detail I do not like in this new version of “Present Windows” is that the filter textbox remembers the entered text. Thus, the next time you use it, the presented windows are already filtered according to the previously entered text. I’m not sure I like this.

The other cool thing introduced is the automatic accent color! Accent colors were introduced a few versions ago in Plasma, but now you can have Plasma automatically adjust the accent color from the current wallpaper:

If you use a wallpaper changer mechanism (like the one provided by Plasma), possibly by downloading new wallpapers (like Variety), you will get nice accent colors during the day. Here are a few examples produced running Variety to change the wallpaper:

Maybe it’s not an important feature, but, as we say in Italy, “Anche l’occhio vuole la sua parte” 😉

The last new feature that positively impressed me is that now KRunner also shows Java files (and probably other programming languages related files) when you search a string. Previously, although “Baloo” (the file indexing and file search framework for KDE) knew about these files, KRunner was only showing .txt files and a few others, but not Java files.

Concerning Wayland, one thing I noted is that if I start a Plasma Wayland session using a brand new user, it automatically scales the display in case of an HDPI screen. Wayland usability in Plasma has not improved since my last experiments (see KDE Plasma and Wayland: usability).

 

Xtext 2.27.0: update your Xbase compiler tests

Leave a reply

If you update to Xtext 2.27.0 and have compiler tests for your Xbase DSL that assert the output of the compilation, you’ll get lots of failures after the update.

I am guilty of that 😉
Well, for a good reason, at least 🙂

In fact, I worked on this issue: https://github.com/eclipse/xtext-extras/issues/772 and its fix is included in Xtext 2.27.0.

Now, the Xbase compilation mechanism does not generate useless empty lines anymore (before, it added lines with two spaces). Your compiler tests will fail because the output is different.

I personally fixed my tests in my DSLs by simply using the Find/Replace mechanism of Eclipse with this substitution pattern (there are two space characters between the tab character and the newline character):

If you have deep nesting in your compilation output, you might have to repeat this substitution with more than two characters, but this should not be required unless you generate nested classes or something like that.

With the above substitution a test like the following one:

will become like the following one (you see the difference: no empty line with two characters between the two generated constructors:

Now your tests should be fixed 🙂

Configure Arch Pacman

Leave a reply

Pacman is the package manager in Linux Arch and Linux Arch-based distributions.

I’ve been using EndeavourOS for some time, and I enjoy it. EndeavourOS is pretty close to vanilla Arch. I also experimented with pure Arch (more on that in future blog posts). However, the output of pacman in EndeavourOS is much more excellent and “eye candy” than in Arch. However, it’s just a matter of configuring /etc/pacman.conf a bit in Arch to have the “eye candy” output.

These are the options to enable in the [options] section in that file (the ParallelDownloads does not have to with the output, but it’s a nice optimization):

Without these options, this is the output of pacman (e.g., during an upgrade):

And this is the output with the options above enabled:

Besides the colors, you can spot c’s for the progress representing “Pacman,” the video-game character, eating candies (that’s the aim of the option ILoveCandy)… waka waka waka!  🙂

The colors are also helpful when searching for packages:

Happy Pacman! 🙂

macOS: switch between different windows of the same application

Leave a reply

Maybe this is well-known to macOS users, but it wasn’t clear to me as a Linux user.

As a Linux user, I’m used to using Alt+Tab to switch between different windows. But I also use the shortcut to switch between different windows of the same application. In Gnome, the shortcut is Alt+<the key above Tab>, which is cool because it works with any keyboard layout. In KDE it is Alt+backtick (`), which has to be changed in Italian keyboards, like mine to Alt+\. Indeed, in the Italian keyboard layout, the key over tab is \.

In macOS it’s the same as in KDE: the shortcut is bound by default to ⌘+`, which of course it’s unusable in Italian keyboards (you should use a complex combination of keys only to insert the backtick ` character). You then have to configure the shortcut “Move focus to next window”, which is quite counterintuitive to me (I had always thought that it wasn’t possible in macOS to switch between windows of the same application if not by using the touchpad gesture or by pressing the down key after using the standard switcher):

Change it to something suitable for your keyboard layout. For the Italian layout I change it to ⌘+\:

And then you’re good to go! 🙂

KDE Plasma and Wayland: usability

2 Replies

It looks like KDE Plasma is getting usable with Wayland!

This is my current testing environment for this blog post:

Operating System: EndeavourOS
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Kernel Version: 5.15.41-1-lts (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 15,3 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

I had tested KDE Plasma with Wayland in the past, and the main problem I was experiencing, which made it unusable to me, was that I had to scale the display. I could scale the display, but the main problem was that, while KDE applications looked nice, the GTK applications looked blurred. This problem is still there, as you can see from this screenshot (here, I scaled the display to 150%):

You can see that the System settings dialog and Dolphin (in the background) look nice, but the EndeavourOS Welcome app and Firefox (in the background), which are GTK applications, look blurred!

Thus, I tried another way: I went back to 100% Display and tried to work on the Font HDPI scaling, though Plasma discourages doing that (it suggests using the display scaling). I tried with both 120 and 140 the result is satisfactory, as you can see from these screenshots:

IMPORTANT: You have to log out and log in to apply these changes. At least, I had to do that in my experiments.

There’s still one caveat to solve: GTK4 applications, like Gedit (the Gnome text editor) and Eye of Gnome (the Gnome image viewer), which, in this version of EndeavourOS, are already provided in their 42 version (using libadwaita). These applications are not considering font scaling. To solve that, you have to install Gnome Tweaks and adjust the “Scaling Factor” from there. Then, everything works also for those applications (Gedit is the one with “Untitled Document 1,” and Eye of Gnome is the dark window in the foreground):

With the Wayland session in Plasma, you can enjoy the default touchpad gestures (which, at the moment, are not configurable):

  • 4 Finger Swipe Left –> Next Virtual Desktop.
  • 4 Finger Swipe Right –> Previous Virtual Desktop.
  • 4 Finger Swipe Up –> Desktop Grid.
  • 4 Finger Swipe Down –> Available Window Grid.

Moreover, the scrolling speed for the touchpad can be configured (while, on X11, I wasn’t able to):

There are still a few strange things happening: the splash screen has the title bar and window buttons if you start Eclipse! 😀

I’ll try to experiment with this configuration also in other distributions.

Let’s cross our fingers! 😉

Dropbox and Gnome 42

Leave a reply

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

Leave a reply

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

3 Replies

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

3 Replies

4th July, updated with BTRFS installations.

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! 🙂

If you need to boot an installation in a BTRFS filesystem (which includes also the /boot directory and the grub.cfg), things are slightly more complex. In fact, BTRFS installations are typically based on subvolumes. The root subvolume is typically denoted by the label “@”. This must be taken into consideration when creating the menu entry.

For example, I’ve also installed Arch on my computer using BTRFS, and the root subvolume is denoted by “@”. The menu entry is as follows:

Note the presence of “/@” in the configfile specification.

That’s not all. If the GRUB configuration specified in configfile has submenus, for example, automatically generated by grub-btrfs, you also must define the prefix variable appropriately (in fact, grub-btrfs generates entries relying on such a variable):