In this blog post, I’ll briefly discuss installing EndeavourOS on the same computer. I wrote it some months ago, so it’s not based on the new EndeavourOS Cassini version. It’s based on Endeavour OS Nova. However, the procedure and the results should be the same also with the current version of the EndeavourOS installer.
First of all, the installer detected my Ethernet card and nicely proposed using a working driver:
I choose the default.
Then, after the WiFi connection has been established, it’s time to start the installation:
First, I updated the mirrors, choosing my country (actually, it had already been detected by the installer):
I started the installer and chose the “Online” method to install KDE, not Xfce (the default DE).
I choose America English (though I’m Italian, I always prefer to have my OS in English). The location has been automatically detected again, and I’ll stick with the proposed settings:
I choose “Manual partitioning” because I want to keep Windows and my current two other Linux installations.
I mount the EFI partition to “/boot/efi” (the “boot” flag is automatically selected):
I create a new partition for the root partition on the free space, choosing BTRFS:
I also mount the existing EXT4 partition to share some common work data (including Docker images, containers, and Java-related stuff). The final layout is as follows:
When I continue, I get a warning because of the EFI partition, which is expected to be at least 300Mb; mine is smaller, but I’m sure there’s enough space, so I continue:
For the desktop, I select “Plasma KDE”.
Now we get to the package selection. Some packages are already selected by default:
I deselect from “Desktop Base” => “GPU drivers” the “xf86-video-intel” since it’s known to give a few problems (including the screenshot tool Spectacle capturing old screen contents), and I’ll rely on the default mesa. I also select the LTS kernel in additions since I prefer an LTS besides the latest kernel (in case of problems, the LTS kernel usually works best).
Moreover, I also select everything concerning printing:
After the user details, it’s time to review the partitioning, which looks reasonable.
Let’s start the installation! Remember to “Toggle log” to see what the installer is doing under the hood.
In a matter of minutes, the installation finished successfully.
Before rebooting, you might want to save the “endeavour-install.log” file generated by the installer in the home folder of the “liveuser”.
And here’s the installed system:
I set the fonts to 120 (that is, 25% bigger) so that I could read better.
The sound does not work fine. I tried to play a video on YouTube, and it worked, but now and then, I get no sound at all (even if I increase/decrease the volume, I get no sound from the DE). I guess that’s due to the “wireplumber” installed by default. On Arch News, they suggest using “pipewire-media-session” instead of “wireplumber”. So I do as suggested:
sudo pacman -Syu pipewire-media-session
And reboot (you have to accept the removal of “wireplumber”).
Up to now, I’ve been using Timeshift and grub-btrfs in my Linux installations because I found Timeshift easy to use and straightforward to install. I was scared by Snapper because I thought it was hard to use and complex to install. I had been fooled by many tutorials I found online, but maybe they were obsolete, or they were not using the right packages. I was wrong: using the right packages provided in Arch and AUR repositories makes it straightforward to use Snapper and grub-btrfs. You also get a program that automatically takes a snapshot when installing/updating your system.
This is more of a report than a tutorial.
I tried this procedure on EndeavourOS and Arch, and, as expected, the final result was the same. However, as shown later, Arch requires a few adjustments in the /etc/fstab file.
The BTRFS subvolume layout of EndeavourOS is ideal for snapper snapshots and for booting them with grub: the subvolume “@” for “/”, “@home” for “/home”, and separate subvolumes for “/var/log” and “/var/cache”. That’s basically the same as I use for Arch installations.
If you already have grub-btrfs because you use it with Timeshift (e.g., with the procedure described in one of my previous posts), it’s better to remove the package so that it will also remove possible enabled services and the custom configurations for timeshift:
If you were using Timeshift, you also provided a custom configuration for grub-btrfsd, which is not automatically removed during the previous command. The files must be removed explicitly:
If you don’t do that now, you will be asked to do that when installing the packages for snapper anyway.
If you installed Arch the Arch way, when generating /etc/fstab, the command has added “subvolid=…” entries in /etc/fstab, which will disturb when restoring snapper snapshots. For example, if you tried to restore a snapshot with btrfs-assistant (which we’ll install in a minute), you’ll get such a warning dialog:
Since the generated /etc/fstab contains both “subvolid=…” and “subvol=…”, I find it safe to remove the “subvolid” parts. I do that with this sed command (of course, do that at your own risk and take a backup of the file first):
If you installed another Arch-based distro, like EndeavourOS, the /etc/fstab should already contain only “subvol=…” entries, so the above command is not required.
Install the following two packages with an AUR helper (e.g., “yay” in my case). The first one is a meta-package that will install snapper and other utilities like “snap-pac” (“Pacman hooks that use snapper to create pre/post btrfs snapshots when installing/upgrading/removing packages”) and “grub-btrfs” (the default configuration of grub-btrfs works already with snapshots created by snapper).
If you haven’t previously uninstalled timeshift and timeshift-autosnap, you’ll get this message, as I mentioned above:
:: Checking for conflicts...
:: Checking for inner conflicts...
-> Package conflicts found:
-> Installing snapper-support will remove: timeshift, timeshift-autosnap
-> Conflicting packages will have to be confirmed manually
During the installation of the above two packages, we can see a few interesting things in the log:
:: Running pre-transaction hooks...
(1/1) Performing snapper pre snapshots for the following configurations...
(4/4) Performing snapper post snapshots for the following configurations...
==> root: 3
The installation creates a configuration for snapper for the root subvolume and configures the service to automatically update the grub menu for booting snapshots. It also creates the very first snapshot, “1”. Since we then install btrfs-assistant, it also creates a “pre” snapshot, “2”, and when the installation of btrfs-assistant finishes, it creates a “post” snapshot, “3”.
Let’s run btrfs-assistant:
Let’s explore its tabs:
Note the existing subvolumes and the newly created subvolume for snapshots “.snapshots”.
The next tab shows the snapshots taken during the installation command we issued to install the programs. Note the numbers of the snapshots and compare them with the installation log shown above. Moreounlike from “timeshift-autosnap”, “snap-pac” creates meaningful and comprehensible names for the snapshots.
Note that you act on a single configuration in this and in the next tab. By default, we have the one created during the installation for the root subvolume (see the “Select config” drop-down menu). If you have other configurations (e.g., for snapshots of the home subvolume), you must select the intended configuration.
With the first tab, you can create/delete snapshots. With the second tab, you can browse them or restore them:
On the last tab, you can see the enabled services and possibly perform further configuration. For the moment, I’m not touching that part: I’m OK without automatic snapshots (since I know they will be taken when installing/upgrading/removing commands) and with the automatic cleanup of old snapshots:
From btrfs-assistant, you can also select the checkbox to show existing Timeshift snapshots:
You might want to remove them once you’re sure the new setup with snapper and grub-btrfs works correctly.
Let’s do some experiments browsing the current snapshots. For example, let’s select the second one and click “Browse”:
Navigating to “/usr/bin,” we can verify that “btrfs-assistant” is not there. In fact, snapshot “2” was taken before installing btrfs-assistant.
Let’s browse snapshot “3”:
This time, “btrfs-assistant” is present in “/usr/bin”. In fact, snapshot “3” was taken after the installation of btrfs-assistant (it’s a “post” snapshot).
From the screenshots above, we can see that snapshots are also browsable from the file system: they are all inside “/.snapshots” (for the root subvolume configuration), each one with the corresponding number. You must be root to browse them.
Let’s experiment with booting snapshots from grub.
Before installing snapper and the other programs, I had previously installed “neofetch” on this machine. I’m going to remove it:
Two new snapshots have been automatically created by “snap-pac” (one before the removal and one afterward):
Let’s reboot the machine and navigate through the snapshots menus, selecting the snapshot corresponding to the state before the removal of neofetch:
Now, we’re inside that snapshot, and we can verify that neofetch is still there:
Let’s say that we want to restore this snapshot for good. Let’s run btrfs-assistant, select the snapshot we have just booted, and press “Restore”:
We get a confirmation dialog, and we can specify a name for the backup that will be taken (in this example, I’ll specify “before-restoring”):
Upon confirmation, we get a warning that urges us to reboot as soon as possible:
Let’s reboot. This time we select the default grub menu entry (not a snapshot).
We can verify once again that neofetch is still there.
From btrfs-assistant, we can see the subvolume with the backup, which we can delete once we’re sure that everything is still working:
If you are using “plocate” or “locate” (see also my older post about locate and BTRFS), you should also exclude “.snapshots” to “PRUNENAMES” (this should already contain some directories like “.git .hg .svn”:
And add “.snapshots” to “PRUNENAMES”, e.g.,
PRUNENAMES=".git .hg .svn .snapshots"
Configuration files are in the directory “/etc/snapper/configs/“. Currently, we have only one configuration, “root” (for the root subvolume), created during the installation.
In that file, we can see the line
corresponding to the setting in btrfs-assistant that disables the automatic timeline snapshots.
Moreover, we have the following:
# run daily number cleanup
# limit for number cleanup
which again corresponds to the setting in the btrfs-assistant screenshot shown above.
Dropbox does not provide a client for the Linux Arm architecture, so you don’t have a client for a PineBook Pro.
However, you can use the open-source project Maestral:
Maestral is a lightweight Dropbox client for macOS and Linux. It provides powerful command line tools, supports gitignore patterns to exclude local files from syncing and allows syncing multiple Dropbox accounts.
The Arch AUR repository provides packages for Maestral:
Qt interfaceforthe Maestral daemon
Open-source Dropbox client
Open-source Dropbox client
So I’m going to install the “Qt interface for Maestral” with the “yay” AUR helper I already have on my PineBook Pro (this will install a lot of python packages, and the installation will take a few minutes):
Let’s run maestral GUI from the command line:
And the app appears:
Let’s click on the button to link to the Dropbox Account
And click on “here” to retrieve the authorization token. This should open the browser; alternatively, you’ll be asked to select an application to open the full URL in KDE. Unfortunately, selecting a browser in KDE does not work, and it will keep asking for the application.
Thus, in KDE, I run from the command line:
$maestral auth link
-Linking newaccount for'maestral'config
-Retrieving auth code from Dropbox
?How would you like toyou link your account?
Open Dropbox website
>Print auth URL toconsole
This allows me to print the auth URL to the console, copy it and paste it into a browser. I can then authorize Maestral on the Dropbox site.
The Dropbox website then shows me a token that I copy and paste on the Maestral window above and press “Link”. (The other run command, “maestral auth link,” can be interrupted.)
The setup proposes to select a local folder to synchronize with Dropbox. Note that by default, it proposes “Dropbox (Maestral)”, but I prefer the standard one “Dropbox”, so I modify it accordingly.
And now, it’s time to select the folders to synchronize. I start with a very minimal subset of my Dropbox folders. As noted below, the initial synchronization will take a lot of time (depending on the size of all the Dropbox contents, not the folders you select).
In the taskbar, you can see the Maestral icon that started to synchronize. The icon provides a context menu.
From the command line, you can see the status of the synchronization with
It does index the entire Dropbox, even if only a few items are selected in Selective Sync.
For example, my Dropbox usage is
It took more than an hour just for “indexing”.
I guess that for the time being, we’ll have to accept that if we want to use Dropbox on the PineBook Pro.