Switching to Fedora Silverblue

For the final 10 years or so, Arch Linux has been my
Linux distribution of alternative. The early years had been a bit tough, and the method
of transferring to systemd wasn’t with out its challenges both, although the expertise
has improved dramatically since then. Regardless of these enhancements, sure
points continued, akin to having to manually carry out replace associated steps each
every now and then, fixing damaged packages after an replace, updating packages in a
explicit order (e.g. archlinux-keyring requiring an replace earlier than you’ll be able to
replace different packages), and extra.

Arch being a rolling launch distribution additionally signifies that you are not imagined to
set up a brand new bundle with out first updating your current packages (at the least
for libraries). That’s, sudo pacman -S some-package might result in issues,
so it is advisable to make use of sudo pacman -Syu some-package as a substitute (see this
section
for extra particulars). It is not a deal breaker, however it’s yet one more factor to maintain
in thoughts.

Maybe essentially the most annoying half is that bundle updates aren’t examined all that
properly, if in any respect; or at the least it feels that approach. Linux kernel updates in
explicit had an inclination to trigger points on my laptop computer. I keep in mind one
explicit occasion the place a bug within the Intel drivers (or one thing within the kernel
itself, I can not fairly keep in mind) resulted in bizarre display screen flickering/artifacts,
requiring a rollback to a earlier kernel model. Pinning packages utilizing
IgnorePkg was the standard workaround, however it’s not an appropriate long-term answer
as up to date packages might not work with older variations of the packages you are
ignoring/pinning.

Lengthy story quick, over time I realised I care extra for a dependable and simple
(or simpler) to make use of distribution, as a substitute of a distribution that provides you
most management.

That is the place Fedora is available in, and particularly
Fedora Silverblue. Fedora has been
round for years, and I have been protecting my eyes on it for some time. Some time again
I constructed a tiny pc to run some residence automation software program, and I made a decision to
use Fedora Server for it. This gave me the
probability to strive Fedora with out it getting in the best way.

I ended up having fun with this sufficient that I made a decision to maneuver my Linux installations to
Fedora. As I primarily work on my desktop (nonetheless operating Arch Linux on the time of
writing), I made a decision emigrate my laptop computer first. I made a decision to go together with Silverblue
as I like the thought of an immutable desktop and the flexibility to roll again updates
with out forsaking a grimy state.

Step one was to perform a little research into potential points I would encounter.
By means of this I discovered a couple of potential points/challenges to take care of:

• Fedora ships a mirror of Flathub as a substitute of utilizing Flathub straight. You’ll be able to
  and doubtless ought to disable this. I discovered and used this Reddit
  post
  as a reference to take action.
• Fedora ships with
  systemd-oomd, and apparently
  this tends to trigger extra issues than it solves
  (see here
  and here).
  I ended up disabling it utilizing
  sudo systemctl cease systemd-oomd && sudo systemctl disable systemd-oomd && sudo systemctl masks systemd-oomd.
• Apparently TRIM support isn’t handled properly when using full disk
  encryption
  on Silverblue. The answer is so as to add rd.luks.choices=discard to your kernel
  arguments.
• A number of packages I wanted aren’t accessible within the official repositories or
  copr, extra on that later.
• I learn one thing about Flatpak (and thus the Firefox Flatpak) not supporting
  U2F, that means I would not
  be capable of use my YubiKey with Firefox. This turned out to work simply effective.

Having decided these points had workarounds that I may dwell with, I
proceeded with the set up course of. The set up course of itself was
straightforward and ran with none points, mentioned beneath in no explicit order.

After the set up completed I utilized the required workarounds/fixes for
the above points, akin to disabling systemd-oomd. Sadly, that is the place
I bumped into some new and sudden issues, although not all are unique to
Silverblue.

For my desktop I exploit a cut up keyboard that makes use of the Colemak
Mod-DH ortholinear structure. On my laptop computer
I exploit the identical structure, by way of mixture of a customized
xkb keyboard
structure and remapping the keycaps on my keyboard:

Whereas the xkb undertaking contains help for the Colemak Mod-DH structure, it solely
helps the variant the place the bottom-left keys are XCDVZ, whereas the
ortholinear model makes use of ZXCDV. I do not fairly keep in mind why the ZXCDV model
is not included, however I recall the reason is alongside the traces of “the XCDVZ
structure is healthier for staggered keyboards”. I assume I am the one individual wanting
to make use of the identical structure all over the place? Both approach, my answer was to create a
customized structure and be finished with it.

For the Arch set up I simply created the required information (based mostly on this
article)
in the best place. I then carried out the required magical incantations (which I
after all could not keep in mind) to get this working all over the place.

For Silverblue I began off with the identical setup, inserting the information in
~/.config/xkb as a substitute of inserting them in /usr/share/X11/xkb. Whereas GNOME
picked up the information simply effective, I could not get this to work for the LUKS unlock
display screen or when utilizing a console/TTY began utilizing Alt and a operate key. I
additionally wasn’t in a position to get GDM to make use of the structure. Inserting the information in /usr/share
wasn’t an possibility both, because it’s read-only on Silverblue.

Getting this to work took a whole night, and required a couple of distinct steps.
First, I construct an RPM
package
to maneuver these information into the best place in /usr/share. I then used
rpm-ostree to layer the
package onto the bottom
picture.

To get the console working I set KEYMAP in /and so forth/vconsole.conf to
colemak_dh_ortho. The default initramfs of Silverblue ignores adjustments to this
file, so to get this working I needed to run rpm-ostree initramfs --enable. This
permits regenerating of the initramfs each time you create a brand new rpm-ostree
deployment, guaranteeing the required information are a part of the initramfs. The draw back
is that instructions akin to rpm-ostree set up and rpm-ostree replace take fairly
a bit longer to complete. I additionally added vconsole.keymap=colemak_dh_ortho to my
kernel arguments for good measure, however I am undecided that is crucial.

The ultimate piece of the puzzle was to get GDM working, which for some motive simply
refused to make use of this structure. I am nonetheless undecided what precisely solved it, however I
suppose it was operating gsettings set org.gnome.libgnomekbd.keyboard layouts '["colemak_dh_ortho","us"]'
adopted by one other reboot.

And all that took was properly over six hours.

GNOME software program is the first approach of putting in software program by way of a GUI on
Fedora. I bumped into two points with it, although each will not be that large of a deal.

First, it is fairly clunky to make use of with regards to uninstalling software program: once you
take away a program, the listing of put in applications is refreshed a couple of seconds
after the removing finishes, displaying a spinner whereas doing so. This made
eradicating a number of applications a ache, because the spinner would usually present up simply
as I used to be about to click on on the “take away” button of the following program I wished to
take away.

The second downside is that GNOME Software program leaks reminiscence like a sieve, and after
a number of hours of utilizing my laptop computer (I wasn’t even utilizing GNOME Software program throughout that
time) I discovered it had eaten up near 1 GiB of reminiscence.

grug uninterested in software program leak reminiscence. grug need attain
for membership, however grug keep in mind simpler simply take away GNOME software program and use terminal,
so grug run rpm-ostree take away gnome-software gnome-software-rpm-ostree. Reminiscence
leak not value grug’s time and power.

rpm-ostree and dnf are sluggish

DNF being sluggish is well-known within the Fedora neighborhood. Whereas DNF5 is meant to
enhance this, I am going to consider it after I see it. For me the method of putting in
and eradicating packages is quick sufficient, however refreshing mirror/bundle metadata is
frustratingly sluggish.

What I did not anticipate is for rpm-ostree to even be as sluggish as a snail. Whilst you
can stage updates within the background and can do most of your bundle associated
work in a container, you continue to should work together with rpm-ostree each now and
then. Coming from Arch Linux the place pacman is tremendous quick, the expertise leaves
so much to be desired. As an example, for this text I ran rpm-ostree replace
and it took simply over two minutes to improve a mere two packages. After all I am
conscious rpm-ostree does extra than simply upgrading two packages, however I am not
satisfied this cannot be finished any sooner.

A number of packages I wanted had been lacking: Lua language
server,
Stylua, the Supply Code Professional fonts
with help for Nerd Fonts, neovim-gtk,
and an up-to-date ruby-install.

Desirous to do the best factor I made a decision to learn up on creating RPM packages and
organising a copr repository; one thing I needed to do for my keyboard structure
anyway. The expertise was deeply irritating: documentation on RPM packages is
scattered throughout totally different web sites, some new and a few historical. These web sites
additionally handle to someway current you a ton of textual content, however not truly clarify
something helpful in any respect.

As an example how irritating this course of is: by way of studying some tutorials I
got here throughout the RPM %bundle macro, however discovering out what it did was close to
not possible. For those who seek for “RPM bundle macro” on Google, the primary end result
points to this
page that
does not point out the macro in any respect. The second
result
does not point out it both. The truth is, not one of the outcomes appear to say this
macro, and trying to find “RPM %bundle macro” does not work both because the % is
ignored. In some unspecified time in the future I discovered this
page which
briefly mentions what it does, however to try this I needed to:

1. Go to https://rpm.org/index.html
2. Click on on “Documentation” and find yourself at https://rpm.org/documentation.html
3. Click on on “RPM Reference Handbook” and find yourself at
   https://rpm-software-management.github.io/rpm/manual/
4. Click on on “Spec Syntax” and find yourself at
   https://rpm-software-management.github.io/rpm/manual/spec.html
5. Seek for %bundle on the web page

Whereas this may increasingly appear to be a weirdly particular problem to say, I bumped into points
like this continually whereas attempting to determine what the idiomatic/trendy approach
is of constructing an RPM.

After all it will get worse. What would make sense is having only one instrument to construct
a bundle, and possibly a separate instrument to add it to copr and begin a construct.
After all there is not only one instrument: that is Linux the place individuals disagree on
nearly all the pieces.

Constructing RPM packages includes two low-level applications: spectool and
rpmbuild. spectool is used for simply itemizing and downloading sources from an
RPM .spec file, which describes easy methods to construct a bundle. After all in typical
Linux style it solely downloads exterior sources, so if you happen to listing a neighborhood file as
a supply (e.g. an icon to put in), you will want to maneuver them into the best
place your self. rpmbuild solely issues itself with constructing a bundle, and
straight up ignores any sources listed in your spec file.

After all individuals utilizing these instruments realised this is not good and determined to repair
it by unifying the 2 into one program that everyone makes use of. Proper? No, of
course not, that will make an excessive amount of sense.

First we’ve got rpkg-util which builds
upon the 2 talked about instruments and provides some templating capabilities. It is the
default construct technique for copr when constructing from a VCS repository, so that you’d
suppose it is the solution to construct a bundle. However after all it is now not maintained
per their README, and current packages on copr it appears it is not
used so much. Oh and it additionally spits out essentially the most ineffective error messages I’ve ever
seen, akin to this:

$ rpkg native --spec ~/path/to/spec/exterior/of/the/present/dir
git_dir_version failed with worth 1

Then there’s tito, which
tries to do a complete bunch of issues associated to packaging and releasing, however
someway does not truly make the method simpler. It is default output is
extremely verbose and makes debugging construct errors close to not possible, it doesn’t
handle patch files,
and its documentation is sorely missing. Much like rpkg-util I additionally wasn’t ready
to seek out any large initiatives that use it, though tito has been round for over
a decade.

For the report, I perceive how one finally ends up with a state of affairs like this, and I
don’t have anything in opposition to the individuals engaged on these instruments, however having gone by way of
this course of I feel I now perceive why RPM packages are much less generally
accessible in comparison with these for different distributions.

As for my very own packages, I resorted to utilizing spectool and rpmbuild straight
by way of a Makefile. For instance, for lua-language-server I exploit the next
Makefile:

SPEC := lua-language-server.spec
TOP := ${PWD}/construct

put together:
	rm -rf construct
	spectool --define "_topdir ${TOP}" -gR ${SPEC}
	cp -p sources/* construct/SOURCES/

srpm: put together
	rpmbuild --define "_topdir ${TOP}" -bs ${SPEC}

rpm: put together
	rpmbuild --define "_topdir ${TOP}" -bb ${SPEC}

clear:
	rm -rf construct

.PHONY: srpm put together rpm

The --define flags are there so the RPM information and directories find yourself in
./construct as a substitute of in your house listing. This manner you’ll be able to construct a number of
packages with out their supply information probably conflicting.

To publish a brand new bundle I then replace the .spec file by hand (e.g. adjusting
the model), run make srpm, adopted by
copr construct lua-language-server path/to/the/constructed/srpm. It is not too dangerous, however
it is nonetheless worse than simply operating makepkg -s on Arch Linux. For those who’re wanting
into constructing a bundle for Fedora, I might recommend doing one thing just like the
above and simply keep away from rpkg-util and tito solely until you’re sure you
want these instruments.

Earlier than putting in Silverblue I made a backup of my
TLP configuration. Whereas Fedora ships
with
power-profiles-daemon,
I’ve learn a bit of an excessive amount of about it not doing way more than simply throttling
your CPU, so I made a decision to stay with TLP. In any case, TLP works effective so why
trouble changing it. I put in TLP, changed the default
/and so forth/tlp.conf configuration file with my very own, and reset its possession to
root:root. Once I tried to start out TLP utilizing sudo systemctl begin tlp, it
failed. After all after I ran it manually it labored simply effective.

After some time I discovered this was a SELinux downside, most likely resulting from sure
SELinux settings/permissions getting misplaced after I changed the default file. To
repair this I ran sudo fixfiles restore /and so forth/tlp.conf, after which TLP began up
with out problem.

Whereas SELinux does log when there are errors (assuming you even do not forget that it
does and the place they’re saved), the logs themselves aren’t useful. For instance:

sort=AVC msg=audit(1677382357.686:651): avc:  denied  { learn } for
pid=16822 comm="tlp-readconfs" identify="tlp.conf" dev="dm-0" ino=533021
scontext=system_u:system_r:tlp_t:s0
tcontext=system_u:object_r:dosfs_t:s0 tclass=file permissive=0

Whereas this log line features a ton of data, it does nothing to assist me
perceive what I have to do to repair the precise downside.

See Also

‘Nobody else is saving it’: the battle to guard a historic music assortment | Music

Whereas utilizing the Firefox Flatpak, I observed the textual content was a bit of fuzzy and arduous
to learn. Upon nearer inspection I observed it was making use of subpixel
rendering, though this
is turned off system-wide (appropriately). I discovered this is because of Flatpak
not permitting entry to $XDG_CONFIG_HOME/fontconfig, which appears to end in
Firefox (incorrectly) guessing what to do.

The answer is to make use of Flatseal to provide
Firefox entry to the xdg-config/fontconfig:ro filesystem subset, then
restart Firefox.

I am utilizing Distrobox as a substitute of
Toolbox, although this problem may additionally
apply to Toolbox: when operating sure instructions within the container, I used to be getting
a “Did not set locale, defaulting to C.UTF-8” error. Per this
issue the repair is to run sudo
dnf set up glibc-langpack-en in your container, altering the bundle identify
in keeping with the language you’re utilizing.

What went properly, and a few ideas

There might have been extra points I bumped into, however these are those I can
keep in mind. Most of those are particular to my setup although. For instance, if you happen to use
a QWERTY keyboard then getting began is simpler. The price of determining how
to construct an RPM bundle is a one-time value, and would not apply to most customers of
Silverblue. The truth is, I believe most customers would solely run into the Firefox font
downside, the Distrobox locale errors (assuming they’re utilizing Distrobox within the
first place), and the slowness of rpm-ostree and DNF.

Other than these points, I am having fun with Silverblue up to now. I additionally like how the
immutable nature of Silverblue forces you to rethink sure workflows or
selections, akin to constructing a correct (reusable) bundle as a substitute of simply dumping
some information in /usr or /and so forth, or utilizing containers extra actively. Not having to
fear about updates breaking your system (or at the least not as simply as on Arch
Linux) is after all additionally nice.

So far as ideas and tips go, there are a couple of that I can suggest.

Since you’ll be utilizing containers when utilizing Silverblue (at the least when utilizing
the terminal), I like to recommend placing the identify of the present container in your
shell immediate. I exploit Fish and have my immediate configured
as follows:

operate fish_prompt
    if [ $PWD = $HOME ]
        set listing '~'
    else
        set listing (basename $PWD)
    finish

    if check -n "$CONTAINER_ID"
        echo -n "[$CONTAINER_ID] "
    finish

    set_color $fish_color_cwd
    echo -n $listing
    set_color regular
    echo -n " $ "
finish

Outdoors a container this leads to a immediate like this:

And inside a container:

[fedora] Downloads $ input-here

Distrobox can create .desktop information to your containers, making it simpler to
begin/enter them. For those who open a brand new tab in that terminal it is going to open the tab in
the default shell, not within the container; at the least when utilizing GNOME terminal. To
work round this I adjusted the generated .desktop file to as a substitute begin GNOME
terminal with a devoted profile like so:

[Desktop Entry]
Identify=Fedora
GenericName=Terminal coming into Fedora
Remark=Terminal coming into Fedora
Class=Distrobox;System;Utility"
Exec=gnome-terminal --profile Fedora -- /usr/bin/distrobox enter --no-workdir fedora
Icon=/var/residence/yorickpeterse/.native/share/icons/distrobox/fedora.svg
Key phrases=distrobox;
NoDisplay=false
Terminal=false
TryExec=/usr/bin/distrobox
Sort=Software

Right here --profile Fedora specifies the GNOME terminal profile to make use of.
The --no-workdir possibility ensures the brand new terminal course of at all times begins within the
container’s residence listing.

The GNOME terminal profile in flip is configured as follows:

• Command → “Customized command” is ready to distrobox enter --name fedora -- fish
• Command → “Protect working listing” is ready to “At all times”

This manner opening new tabs leads to them coming into the container, whereas
preserving the working listing of the earlier tab.

This is not crucial if you happen to solely intend to make use of a single container, however if you happen to
use a number of containers it is a should: when making a container utilizing Distrobox,
the --home flag is used to specify a customized residence listing. This manner the
container will not pollute your precise residence listing, and two totally different containers
utilizing the identical information in your house listing will not battle. For instance:

mkdir $HOME/properties
distrobox create --name fedora --image fedora:newest --home $HOME/properties/fedora

This creates a brand new container known as “fedora” with its residence listing set to
~/properties/fedora.

Contained in the container you continue to have entry to the true residence listing. As all my
initiatives are in ~/Tasks (in my actual residence listing), I created a symbolic
hyperlink to this folder from the container’s residence listing (operating this contained in the
container):

ln -s /var/residence/yorickpeterse/Tasks $HOME/Tasks

This manner contained in the container’s residence listing I can simply run cd Tasks,
as a substitute of cd ../../Tasks.

I am undecided how properly this works if you happen to nonetheless have GNOME Software program put in (or
if it is even crucial), however I’ve rpm-ostree set as much as routinely stage
updates. That is finished in two steps:

1. Add AutomaticUpdatePolicy=stage to /and so forth/rpm-ostreed.conf underneath the
   [Daemon] part.
2. Run sudo systemctl reload rpm-ostreed adopted by sudo systemctl allow
--now rpm-ostreed-automatic.timer.

You’ll be able to then confirm if it is enabled by operating rpm-ostree standing. If enabled
it is best to see a message on the high alongside the traces of:

AutomaticUpdates: stage; rpm-ostreed-automatic.timer: final run 24h in the past

GTK3 purposes look totally different from GTK4 purposes, which is annoying. We
can repair this by utilizing the adw-gtk3
undertaking as follows:

1. Run sudo wget -P /and so forth/yum.repos.d/ https://copr.fedorainfracloud.org/coprs/nickavem/adw-gtk3/repo/fedora-37/nickavem-adw-gtk3-fedora-37.repo.
2. Run rpm-ostree set up gnome-tweaks adw-gtk3 --apply-live.
3. Open Tweaks and go to “Look”, then underneath “Legacy Purposes” select
   “Adw-gtk3”. If the theme is not listed there strive rebooting first.

To conclude, I like Silverblue, regardless of the problems I bumped into. Within the coming
weeks I am going to additionally transfer my desktop over to Silverblue, and in some unspecified time in the future within the
future I am going to additionally transfer my Home windows gaming desktop to Silverblue. Most of my points
are particular to my setup and doubtless will not apply to most customers, although I
would not suggest Silverblue to these not conversant in a terminal simply but; at
least not till GNOME Software program is much less clunky and stops hogging reminiscence.