Gentoo Configuration Guide: GNOME on systemd
Getting a perfect GNOME configuration on Gentoo is not hard but is tricky. In other words, it would be a piece of cake once you have done it, but it is not easy to get it right with only one shot for the first time. The GNOME Guide on Gentoo Wiki is a good resource and is enough for a barely functional GNOME installation, but there are plenty of rooms for improvements, like removing the authentication dialog when modifying network settings, and enabling Wayland screen sharing in web browsers like Google Chrome.
In this article, I will list the important steps for getting GNOME to run smoothly on Gentoo. Some fundamental steps are already covered by the Gentoo GNOME Guide; others are enhancements not covered by that guide but improve the overall user experience.
This article assumes a Gentoo system that uses systemd, instead of OpenRC.
Select Profile and Install GNOME Packages
The Gentoo Handbook instructs users to select a profile
during system installation, and users might have promptly selected the GNOME
systemd profile for a system with GNOME and systemd. Please note that enabling
this profile alone will not cause GNOME to be installed. The only purpose of
the profile is to set up USE flags and other Portage options that are necessary
for GNOME to run. This means after enabling the GNOME profile, users need to
manually install the GNOME meta-package with emerge
.
# emerge --ask gnome-base/gnome
Enable systemd Unit for GNOME Display Manager
To start GNOME automatically upon system boot, the systemd unit for GNOME Display Manager (GDM) needs to be enabled manually. Otherwise, the text-based login console will still be presented after system boot.
# systemctl enable gdm.service
If gdm.service
has already been enabled, but after rebooting the system, the
GNOME login screen is still not shown, then please try explicitly setting
systemd’s default target to graphical.target
:
# systemctl set-default graphical.target
Enable Additional systemd Units for GNOME Settings
There are some systemd units that need to be enabled if the user wants to
adjust computer settings via the GNOME Settings app (a.k.a.
gnome-control-center
).
- To manage network connections from GNOME Settings, enable
NetworkManager.service
. This enables NetworkManager, which is capable of managing the system’s network connections. Ifsystemd-networkd
is also enabled, it is a good idea to disablesystemd-networkd.service
to avoid any conflict between these two services. - To access Bluetooth settings, enable
bluetooth.service
. - To enable printing settings, enable
cups.service
.
# systemctl enable NetworkManager.service
# systemctl disable systemd-networkd.service
# systemctl enable bluetooth.service
# systemctl enable cups.service
Allow Modification of Network Settings Without Authentication
By default, superuser privileges are required to modify network settings from GNOME Settings, so users might be asked to authenticate when they connect to a new Wi-Fi network or change network settings, as shown below:
To allow every user account to modify network settings, create a *.rules
file
under /etc/polkit-1/rules.d
, and add a rule which permits so to the file:
/* /etc/polkit-1/rules.d/10-networkmanager.rules */
// Allow any user to manage network connections via NetworkManager
polkit.addRule(function (action, subject) {
if (action.id == "org.freedesktop.NetworkManager.settings.modify.system" &&
subject.local) {
return polkit.Result.YES;
}
});
Then, restart systemd unit polkit.service
to apply the new rule:
# systemctl restart polkit.service
Allow Users in wheel
Group to Use Their Own Credentials for Authentication in GNOME
The wheel
user group is often used as the group for system
administrators on a Unix system. As a common idiom, utilities like sudo
are
configured to let users in the wheel
group execute commands with superuser
privileges and authenticate with their own password instead of the root
account’s password.
When GNOME needs to execute a task with superuser privileges, like mounting a
partition of an internal hard disk, it can ask for authentication in a GUI
dialog. However, without proper configuration, it requires credentials for the
root
account, which is unlike sudo
.
To mimic sudo
’s behavior of asking for the user’s own password, create a
*.rules
file under /etc/polkit-1/rules.d
, and add the following rule:
/* /etc/polkit-1/rules.d/49-wheel.rules */
// Allow users in the 'wheel' group to use their own password instead of the
// root password in authentication pop-ups of GNOME
polkit.addAdminRule(function (action, subject) {
return ["unix-group:wheel"];
});
After restarting the systemd unit polkit.service
, the user’s own credentials
will be requested for authentication instead, provided the user is in the
wheel
group:
Enable WebRTC Screen Sharing Based on PipeWire in Web Browsers
Enabling WebRTC-based screen sharing from web browsers on Wayland – which is
the default display server protocol used by GNOME – is a tricky thing many
users have asked about. The solution to this problem is fairly simple, which
is to ensure xdg-desktop-portal-gtk
is installed.
On Gentoo, sys-apps/xdg-desktop-portal-gtk
is guaranteed to be installed with
gnome-base/gnome-shell
because the latter package indirectly depends on the
former package. However, WebRTC screen sharing requires additional
configurations to be functional:
-
The
screencast
USE flag needs to be enabled at the global level, so packages can be compiled with PipeWire’s screencast portal support. -
The systemd socket for PipeWire –
pipewire.socket
– needs to be manually enabled because it is disabled by default.
The detailed steps are:
-
Enable the
screencast
USE flag at the global level. The Gentoo Handbook covers one way of doing this via modifying/etc/portage/make.conf
; alternatively, users can add the USE flag into/etc/portage/package.use
as follows:# /etc/portage/package.use # Enable screencast portal using PipeWire */* screencast
-
Rebuild existing packages with the new USE flag settings:
# emerge --ask --newuse --deep @world
-
Enable PipeWire’s systemd socket:
# systemctl --global enable pipewire.socket
-
Reboot the system.
According to ArchWiki, FireFox has WebRTC PipeWire support enabled by default, whereas on Chromium/Google Chrome, the following experimental flag for this feature needs to be enabled:
chrome://flags/#enable-webrtc-pipewire-capturer
To test whether screen sharing has been correctly configured, the screen capture test in this test page can be used. After selecting what to share from the dialog, the screen sharing content should be visible on the page, and an orange screen share icon should be in the top bar.
Limitations
- Screen shares from Google Chrome do not have sound.