I experienced problems with the new version (2:2.11.1) of wpa_supplicant in PineBook Pro, where I have EndeavourOS. WiFi does not work anymore with the new version of wpa_supplicant.
That’s because, by default, the downgrade script uses this archive site https://archive.archlinux.org or the local cache (which I always clear). However, that archive is for the x86 architecture. You must use a corresponding archive for the arm architecture, like https://alaa.ad24.cz/, using the command line option:
1
2
--ala-url <url>
location of ALA server, defaults to "https://archive.archlinux.org"
So I ran (note that I also chose to add the package to “IgnorePkg” to avoid further future updates, at least until the bug is solved):
In this post, I’ll show how to configure GRUB (without os-prober, which doesn’t work well with different Linux distributions like Fedora and Arch) by delegating to other GRUB configurations (i.e., chain loading).
I’ll use ArchEndeavourOS (BTRFS) and Fedora. I’ll show the two possible solutions: EndeavourOS as the main GRUB delegating to Fedora and vice-versa.
First, we need to tweak both distributions’ GRUB configurations.
As a further alternative, if you want to keep the UEFI entry, you must remove the culprit call
1
fwsetup--is-supported
As usual, you must run “grub-mkconfig”.
Preparing Fedora
It’s better to remove os-prober since, as I said above, it wouldn’t work for other Linux distributions, and it takes some time when updating GRUB: edit with sudo the file “/etc/default/grub” and ensure you have this line:
1
GRUB_DISABLE_OS_PROBER=true
Also, ensure you have this line (if you use EndeavourOS as the principal GRUB, otherwise you will not see Fedora entries):
1
GRUB_ENABLE_BLSCFG=false
But then, you’ll have to update GRUB after you install a new kernel. (if you use Fedora as the principal GRUB, the above modification is unnecessary).
Add this entry (for more details on these entries, please see my old post):
1
2
3
4
5
6
7
8
9
menuentry "EndeavourOS" {
insmod part_gpt
insmod btrfs
insmod ext2
rmmod tpm
set root='hd0,gpt3'
set prefix="/@/boot/grub"
configfile "${prefix}/grub.cfg"
}
By default, Fedora does not show the GRUB menu, which would break this post’s intent.
To show the grub menu, run:
1
sudo grub2-editenv-unset menu_auto_hide
Update GRUB:
1
sudo grub2-mkconfig-o/boot/grub2/grub.cfg
Reboot the virtual machine configured to start with Fedora, and you’ll see the EndeavourOS entry to boot EndeavourOS (you will get to the EndeavourOS GRUB entries from the Fedora GRUB):
Booting Fedora from EndeavourOS
As done above, inspect the partitions:
Shell
1
2
3
4
5
6
7
8
9
10
11
[bettini@eos-multi-kvm~]$sudo lsblk
[sudo]password forbettini:
NAME MAJ:MIN RMSIZE RO TYPEMOUNTPOINTS
sr011:011024M0rom
vda254:00100G0disk
├─vda1254:10500M0part/boot/efi
├─vda2254:2050G0part
├─vda3254:3049,5G0part/var/log
/var/cache
/home
/
Fedora is in “vda2”:
Edit with sudo “/etc/grub.d/40_custom” and add this entry:
1
2
3
4
5
6
7
menuentry "Fedora" {
insmod part_gpt
insmod btrfs
insmod ext2
set root='hd0,gpt2'
configfile /boot/grub2/grub.cfg
}
Update GRUB:
1
sudo grub-mkconfig-o/boot/grub/grub.cfg
Reboot the virtual machine to start with EndeavourOS, and you’ll see the Fedora entry to boot Fedora (you will get to the Fedora GRUB entries from the EndeavourOS GRUB):
Final notes
Fedora has its way of updating the system, which requires rebooting, installing updates, reboot again. This process doesn’t work well when Fedora is not the principal booting system; at least, it requires attention to manually select the Fedora entry a few times during this update/booting process. Thus, it’s better to keep Fedora as the principal booting system.
Unfortunately, I also started to experience problems similar to those with KDE Plasma 6.1 (Linux EndeavourOS and Arch); as in the other blog post, the problem is only with Wayland.
I’ll use this example project (taken from my TDD book): https://github.com/LorenzoBettini/demo-attsw. It is a simple Java Swing application where UI tests are written with AssertJ Swing. I run “mvn verify,” and most of the UI tests fail (when the AssertJ Swing bot tries to interact with the application window, it mostly gets the position wrong). This is the leading cause of the failure: I get this dialog popping up from KDE, “Remote control requested”, coming from “xdg-desktop-portal-kde“:
This shows up as soon as one of the UI tests starts.
First, I must click “Share” (of course, tests have already failed). Note that the dialog remembers the setting for the application you used to run the tests. For example, if you change the Java version to run the tests, you’ll get the dialog popping up again.
Starting the UI tests again still leads to failures. I have to change these system settings:
Now, UI tests finally succeed. Though, they tend to be quite flaky. I see that while they run, since they interact with the keyboard and mouse, other windows get focused, and some interactions are performed on the other windows, not one of the applications under test. Things improve if you only leave the application under test on the screen. It is even better to place the mouse in the part of the screen where the application under test usually appears.
In general, with such kinds of UI tests, it might be better to switch to X11… 🙁
However, the next part is different from what I have always seen in a Fedora installation, at least the default Gnome one: you have more things to set:
I won’t show the other installation parts since they are standard in Fedora installation. I went with the defaults because I’m trying that in a virtual machine, so I’ll stick with the default partitioning scheme.
After the installation is concluded, let’s restart, and here’s the greeting login screen:
And once you log in:
No more help message: you’re on your own 😉
Probably, a basic knowledge of Sway is required and assumed.
At least, you may remember the SUPER + d shortcut to open the application launcher, and you can run something from there.
It’s better if you know about the basic shortcuts, which are the Sway default in this installation:
SUPER+SHIFT+Q: close the current window
SUPER+ENTER: run the default terminal, which here is “foot”
SUPER+SHIFT+C: reload Sway
The look and feel of the installed and configured Sway is nice; the “Waybar” is configured with a few helpful information. You have the tray icon (on the right) for network connections—the volume control opens a dialog to configure the volume and microphone. Moreover, media keys are already configured. For example, the ones for volume, and you have a visual feedback:
A few screenshot key bindings are also configured:
# Capture the currently active output
Print
# Capture the currently active window
Alt+Print
# Select and capture a custom rectangular area
Ctrl+Print
However, you have no visual feedback for such features; more effort could have been made.
Software-wise, you don’t have much installed: you have Thunar as a file manager but no text editor, for example.
The disappointing part is the configuration of Sway: you might expect you have everything already created in the “~/.config” subdirectories, following the standard Sway and other application structures. Unfortunately, it’s not like that: you have nothing in your home directory in that respect. Everything is configured system-wide. Of course, you can customize everything, but you must go through the documentation: https://docs.fedoraproject.org/en-US/fedora-sericea/configuration-guide/.
Several precedence rules are documented in the link, but I find that mechanism quite cumbersome. There are configuration files spread in many places:
1
2
3
4
/etc/sway/
/etc/sway/config.d/
/usr/share/sway/config.d/
/etc/sway/environment
You have to add additional files to your home folder or completely override a configuration file with one with the same name in your configuration folder.
I’ve just started experimenting with Sway; such a mechanism is hard to grasp and use.
For example, the installation procedure completely forgot the “Italian” layout I specified for the keyboard! There’s no “~/.config/swat/config” file to modify quickly. Should I copy the default one there and modify it; however, the part about the keyboard layout is not even commented on.
After reading the documentation, I came up with this (the configuration file’s name is my own; I haven’t followed a pattern; the important thing is the directory where the “.conf” file is):
Then, I reloaded Sway with SUPER+SHIFT+C and got the Italian keyboard layout.
But it wasn’t easy…
In general, I had the impression that Fedora Sway is not for beginners of Sway; however, it doesn’t seem to be for Sway experts either: they’d expect to customize Sway as they see fit anyway, and probably they have their dotfiles ready to be used.
However, maybe Fedora Sway is not bad for starting to experiment with Sway in the end. 🙂
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.