Trying out the pre-relese of Fedora 38 a bit early, with Silverblue

Fedora 38 was branched from rawhide almost a month ago. If you’re on Silverblue, you might also want to be adventurous and dive into the new features the upcoming GNOME will offer. With the exception of one “little” bug (details later), I’ve found it to be overall great so far.

To rebase, you’d run this command:

rpm-ostree rebase fedora:fedora/38/x86_64/silverblue

So the one rather big problem that’s been affecting me is a bug in Mutter (GNOME’s window manager) that causes focus selection issues. It’s been filed upstream… several times:

The problem seems to stem from this commit: x11: Do not move X11 input focus during grabs (a68b8e95) · Commits · GNOME / mutter · GitLab.

Since it’s been filed so often (see above… there are some closed duplicates not listed too), I imagine it’ll be fixed rather soon. Hopefully we’ll see a fix committed, with a release and package build in F38 ASAP.

Meanwhile, with Silverblue, you can “fearlessly” get the latest and greatest from what will be Fedora 38 and also downgrade Mutter (and all the packages that inter-depend on it) with rpm-ostree override.

To override the problematic version of Mutter, you’d run this:

rpm-ostree override replace

(The first bodhi URL is Mutter; the rest are ones I found that you also need to override to successfully make the Mutter override work. You can also override with RPMs too… but I find it’s easier to give bodhi URLs and let rpm-ostree figure out what to do.)

This will cause your overrides to look like the following in rpm-ostree:

           LocalOverrides: gnome-shell 44~beta-2.fc38 -> 43.1-4.fc38 gnome-shell-extension-background-logo 44~beta-1.fc38 -> 43.0-1.fc38
                           gnome-shell-extension-launch-new-instance gnome-shell-extension-places-menu gnome-shell-extension-apps-menu gnome-shell-extension-common gnome-classic-session gnome-shell-extension-window-list 44~beta-1.fc38 -> 43.1-2.fc38
                           mutter 44~beta-2.fc38 -> 43.2-2.fc38

The one downside of this, is that it does downgrade GNOME Shell as well, so you won’t have some of the newer features (notably the details part of the quick switches). But not having that is better than having the focus bug… trust me on this. :wink:

When a new version of Mutter that fixes this bug lands in Silverblue’s Fedora 38 branch, then we’ll be able to remove the overrides with a reset:

rpm-ostree override reset -a

The best way to go back to stable Fedora is to roll back to your previous deployment, if you haven’t made an additional deployment (including upgrade) since. You can do this by running:

sudo rpm-ostree rollback

If you have made a deployment since, you can use deploy to switch to a specific deployment with rpm-ostree deploy followed by a hash (long string) that you see in the output of rpm-ostree status.

Alternatively, you could rebase back to Fedora 37, by running:

rpm-ostree rebase fedora:fedora/37/x86_64/silverblue

Anyway, thanks to Silverblue, we can try out pre-releases and then rebase to stable if there’s some issue. (Which is exactly what I did before taking a couple minutes to figure out the overrides.)

Hopefully this helps someone else too! :+1:

Additionally: The bodhi override method (and resetting) is how you’d test out new packages individually that are in testing but not yet in stable, unless you rebase to testing, such as with rpm-ostree rebase fedora:fedora/37/x86_64/testing/silverblue (to try all testing packages out together at once).


Oh, of course, before doing any of this, you might want to pin what’s working first with:

sudo ostree admin pin 0

If you forgot to pin the running system and ran some commands before pinning, then you’d run the same command, but with 1 instead:

sudo ostree admin pin 1

Pinning a deployment means that it won’t be removed when ostree decides to clean up deployments to free up disk space. And this means you will be able to boot into it (or redeploy as the main one) until you decide to unpin it and let ostree free up the space it takes again.

You’d unpin with something like:

sudo ostree admin pin -u 1

You can figure out which is which by counting the deployments listed with rpm-ostree status and counting from 0 (which is the first one listed). Status also shows you if a deployment is pinned.

Also, don’t pin too many, as each deployment you pin will take up some space. Just pin the ones you want to roll back to or rebase to. If you want to keep stable, f38, rawhide, Kinoite, a container-based image, or anything else around as a pin, it makes fetching updates after rebasing a lot quicker too, as it’ll only have to download the changes between what’s on disk and what’s on the remote, instead of having to redownload from scratch after it was removed (if it wasn’t pinned).


I really wish Siliverblue (or Fedora ostree variants) can be made to dual boot with non-ostree Fedora by the installer automatically.

1 Like

Yeah, I reported problems trying to install with dual boot way back in 2018 @ — but it was closed in Fedora EOL support round. :person_shrugging:

I haven’t tried again since, as I didn’t want the hassle of trying to set up my laptop yet again just to test this out. So I’ve been using Silverblue just on my work laptop and now my “new” (as of last year) desktop.

I’d also love for my laptop to be able to run Silverblue as well, but I don’t want to nuke everything on it to switch it over.

There seems to be a partial fix that was merged @ Fix EFI bootloader install (#1575957) by bam80 · Pull Request #2329 · rhinstaller/anaconda · GitHub.

There’s also a less-old bug that I think is possibly the same thing (non-default partitioning erroring out when installing Silverblue) @ 1845095 – Installation of Fedora 32 Silverblue fails with error code 32

I’m hoping that the Anaconda re-implementation happens to fix this issue. It’s supposed to take into account existing OSes and do the right thing. (I’ve personally brought this up several times and made mockups and explained how it should work over the course of several meetings with the team. I didn’t talk about Silverblue specifically, however, but the same idea would apply. They’ve focused on the delete-and-install case so far in the new installer and haven’t yet gotten to the repartitioning UI yet.)

But back to the topic at hand: It’s frustrating that it’s been years later and it might not be fully fixed yet. (There’s no indication, except for a partial fix.) I guess it’s hard to fix and not many people know how to fix it.

People have mentioned workarounds in the bug report, so I guess we could install it if we’re aware of that, know what we’re doing, and willing to try reinstalling (and possibly making the laptop not boot with the current installed OSes).

1 Like

I am doing this to dual-boot

  1. Partition Disk as:
    sda1 600MB /boot/efi (for sb)
    sda2 1GB /boot (for sb)
    sda3 27GB btrfs
    -subvol sbroot
    -subvol sbhome
    sda4 1GB unmounted
    sda5 600MB umounted
  2. Install SB
    sda1 /boot/efi
    sda2 /boot
    sbroot /
    sbhome /home
  3. Install Workstation
    sda5 /boot/efi
    sda4 /boot
    create new subvols
  • fwroot /
  • fwhome /home
  1. After both installation done, using efibootmgr to select next boot target, change default target, etc. Also can use BIOS boot manager to select which to boot.

I guess we have to wait for the mutter 44 rc version for this fix, would be good if it was backported insteas of requiring downgrading mutter and shell to 43 though.

Yes, agreed, I have been trying to live with this bug for a few days and it’s maddening, specially if you are used to changing windows lots of times via the Overview.

1 Like

Just a heads up that there is a new update for that bug here:

First reset the previous overrides from the initial post:

rpm-ostree override reset gnome-shell gnome-shell-extension-background-logo gnome-shell-extension-launch-new-instance gnome-shell-extension-places-menu gnome-shell-extension-apps-menu gnome-shell-extension-common gnome-classic-session gnome-shell-extension-window-list mutter gnome-shell-extension-drive-menu-43.1-2.fc38.noarch

Then install the newer mutter override:

rpm-ostree override replace
1 Like