Fedora 33 beta: Current issues

Desktop Silverblue
#1

Let’s keep track of the issues currently affecting Fedora 33 beta with Silverblue. (Some of these will most likely affect Fedora 33 non-Silverblue too.)

Additionally, every one of these issues should have a bug somewhere. If it’s not filed yet, let’s make sure to get it filed and make it known.

  1. Toolbox: cannot find name for group ID 1000

    • Issue: https://github.com/containers/toolbox/issues/523
    • It’s fixed upstream, but still affecting Silverblue 33; we need a new version of toolbox
    • Workaround: Add YOURNAME:x:1000 (with your log in) to /etc/group inside the toolbox.
    • Appears fixed in Silverblue 33.20201011.n.0 now

  2. Toolbox: Apps that use X11 do not work in toolboxes (when in Wayland)

  3. Flatpak: Some apps do not work in X11, but do work in Wayland

  4. Input issues: In X11, mouse and touchpad settings are not respected, including natural scrolling detection

    • I haven’t found or filed an issue for this one yet. I need to test it more and make sure it’s acting differently on Wayland versus X11.
    • Workaround: Go to mouse & touchpad settings and toggle the settings.
    • Due to the workaround, I think it might be a GNOME settings bug, but it could also be related to libinput. Additionally, it might be fallout from general X11 & Wayland wonkiness that’s also currently affecting Flatpak and Toolbox.

  5. Toolbox: $HOSTNAME is not in a toolbox container.

  6. Toolbox: created toolbox fails to start: open /proc/sys/net/ipv4/ping_group_range: Permission denied: OCI runtime permission denied error

If you come across more issues, please post here. If you can or cannot replicate the above list, also please comment.

Please include your version of Silverblue when commenting please (found with rpm-ostree status — it’s the one with the dot). For reference, mine is 33.20200929.n.0 (2020-09-29T08:06:48Z), base commit: 215677333515cc11110cf016a4cbb021eb929b552f5ed25bb6d403c9f19c1a4a

3 Likes
#2

My suggestion? If you’re using F33 right now, run Wayland and do the workarounds in issues 1 & 2 in your toolbox container(s).

If you need to (or want) to use X instead of Wayland for any reason, stick to F32 for now… Unless you want to help test the beta, figure out fixes, and are OK with the breakage listed above (issue 3 & 4).

#3

I also have this issue, HOSTNAME is not set on toolbox, I been able to reproduce it after clearing all toolbox/podman related configs on a clean new toolbox but it seems I am the only one affected.

#4

I saw that bug, but I haven’t been able to recreate that on my local machine.

However, after you posted here, I checked Silverblue in my testing VM… and it has the problem (I just checked by running echo $HOSTNAME in the default toolbox). I normally don’t use toolbox there, but on my main system itself.

Here’s the output from rpm-ostree status:

● ostree://fedora:fedora/33/x86_64/silverblue
                   Version: 33.20200923.n.0 (2020-09-23T08:04:00Z)
                BaseCommit: 6942fe3f6c881635d61bbe3c6235feba3c998099f309b369ea4ddfe67abcc698
              GPGSignature: Valid signature by 97A1AE57C3A2372CCA3A4ABA6C13026D12C944D0
           LayeredPackages: fedora-workstation-repositories gitk
                    Pinned: yes

Then I upgraded to the latest:

● ostree://fedora:fedora/33/x86_64/silverblue
                   Version: 33.20200929.n.0 (2020-09-29T08:06:48Z)
                BaseCommit: 215677333515cc11110cf016a4cbb021eb929b552f5ed25bb6d403c9f19c1a4a
              GPGSignature: Valid signature by 97A1AE57C3A2372CCA3A4ABA6C13026D12C944D0
           LayeredPackages: fedora-workstation-repositories gitk

Version:      2.1.0-dev
API Version:  1
Go Version:   go1.15
Built:        Tue Aug 25 14:48:48 2020
OS/Arch:      linux/amd64

Same problem.

I tried a podman system reset and it still doesn’t have a hostname. (I’m not feeling adventurous enough to try this on my main workstation.)

I’ve added it to the list above.

#5

I guess that when I get some free time i will run a podman system reset but I depend on the toolbox now and I have like 5000 packages on it.

#6

Do you know if a person who migrates to Fedora 33 Beta and doesn’t do these workarounds will have these quirks fixed if the final version fixes them … or they will need to do manually because the early migration implies that a lot of these files will not be touched by an upgrade to the stable final version?

#7

I wouldn’t recommend doing a podman system reset if you depend on your toolbox. Please wait for a fix. Meanwhile, I’d suggest setting $HOSTNAME manually in your startup file, such as .bashrc. (In my dev toolbox, it’s automatically set to toolbox.)

#8

Ideally, we’d have all these issues sorted out ASAP, fixed well before release. That’s what the beta is for, right? It’s also why I decided to highlight them in a list of big issues that affect us here on the forum, along with workarounds and links to issues.

We have to let people know that these are all pretty huge issues for Silverblue users.

Right now, Silverblue is a bit too buggy for people to use it and not check this forum — especially the betas. This forum is vital. Official releases are a lot better, but still not perfect. This is why I think we need testing for successful boots, toolbox, podman, and flatpak, and block bad composes if these tests don’t pass. (And/or switch over to doing what Fedora CoreOS is doing with different release channels.) Basically, this discussion: https://discussion.fedoraproject.org/t/block-failing-composes/

#10

What I mean is this scenario:
if I’m using Beta to help squeeze bugs and the bugs that are being perceived at this Beta stage are fixed before the final release.
OK, but people like me - that are using the Beta and update to the final release next month - may get stuck with bugs because of some files/configurations/links not being updated?
Or I can have peace of mind, use the Beta, relate bugs, and after the final release, I update and get a system so stable as others that jump after the final release?

#11

I’m not on F33 beta yet but do plan to test soon. There is something not working right for me currently in F32 SB though.

For some reason if I change the color profile of my monitor in Settings, it is not persistent across reboots. Now in all honesty it’s probably for the better that I’m forced to use the defaults instead of play around, but it is something I would expect to work if it is presented.

I suppose it would need a new ostree commit since the color related files seem to reside in /usr and /lib64.

#12

Issue 2 is fixed by https://github.com/containers/toolbox/pull/570 :confetti_ball: :tada:.

1 Like
#13
  1. dropping firefox, nautilus, disks from base image (flatpak version to change default)
  2. adwaita-dark not work in fedora flatpak apps
  3. libvirt to default in kickstart
#14
  1. Is not a bug, and while the flathub version works it can’t be included by default. The fedora one would be a total downgrade for the moment, as far as I know you can’t use codecs on it. The nautilus situation is even worse, that app would have to run with zero sandbox anyways.
  2. Should have been fixed a while ago when they included the dark theme on their f32 runtime. Please open an issue at the issue-tracker github repo if it is not the case for the f33 runtime, when I mentioned it last time it got fixed that same week.
  3. I know some of those words
#15
  1. not flathub, fedora regisrtry flatpak
  2. ok
  3. set gnome-boxes in default, without rpm-ostree install gnome-boxes for crash system
#16

Just installed F33 Silverblue on a 2017 Entroware Orion laptop and the backlight’s default brightness is reset on every reboot. I tend to set the brightness to maximum and on reboot, it looks to have set it back to ~25%.

This happens when the device is charging and discharging.

Thanks!

#17

I’m not sure that’s per se a Silverblue 33 issue, but I just tried rebasing my Silverblue 32 install to 33 and it failed with error: Packages not found: fedora-toolbox.

 kekun@maridia  ~  rpm-ostree rebase fedora:fedora/33/x86_64/silverblue
1 metadata, 0 content objects fetched; 592 B transferred in 1 seconds; 0 octet content written
Checking out tree e5e98fd... done
Inactive requests:
  nano (already provided by nano-5.2-1.fc33.x86_64)
Enabled rpm-md repositories: updates fedora fedora-cisco-openh264
rpm-md repo 'updates' (cached); generated: 2018-02-20T19:18:14Z
rpm-md repo 'fedora' (cached); generated: 2020-10-03T05:04:14Z
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2020-08-25T19:10:34Z
Importing rpm-md... done
error: Packages not found: fedora-toolbox

Fore reference, my install has no changes besides the following layered packages: baobab fedora-workstation-repositories gdb gnome-tweaks jekyll meson redhat-rpm-config sassc tilix zsh

Any idea what could be done about this? E.g. where I should report the issue, or how I could fix my install maybe.

#18

the package fedora-toolbox is not in the f33 repository, it might be a dependency of some of your layered pacakges. You could try to reset to the base image and then rebase. Then layer them again, it might be the case that it was a renamed package.

#19

When uninstalling some overlaid packages, I got shown:

Inactive requests:
  nano (already provided by nano-4.9.3-1.fc32.x86_64)
  fedora-toolbox (already provided by toolbox-0.0.95-1.fc32.x86_64)

So at some point in the past (this is an old Silverblue install) I likely overlaid it. Showing such unfulfilable requests in rpm-ostree status may help in such cases. Thanks. :slight_smile:

#20

In Fedora Silverblue 33, running with regular GNOME desktop on X11, I experience some lag with the screen update of a flatpak application - for example after moving a point or resizing an object in Inkscape, the result of the operation is not updated until I click the right button or clicking up in the menu. This problem is not present in F32 Silverblue.

This problem has been experienced with flatpak Inkscape from both Flathub and Fedora repositories, and it’s been present through the ostree updates for some weeks now - so it’s not limited to the exact ostree version posted below.

I don’t have proper graphics driver support, so I am only able to run it on X11.

Inkscape v1.0.1
ostree://fedora:fedora/33/x86_64/silverblue
Version: 33.20201021.n.0 (2020-10-21T07:53:54Z)
BaseCommit: 7828821ac0591824fb867c6df6760d089b04ec9200fe1df091974bb21ba2e22b

I looked at https://github.com/flatpak/flatpak/issues/3880, and it fits the description that something is not working with flatpak on X11, but on the other hand it seemed to be limited to not working at all - and that is not the case here. This is more of a quirkiness.

If this is not the place to write this, please point me to a better location,

thanks. And looking forward to F33 coming out of beta :smiley:

#21