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.
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.8.11-300.fc33 is in Silverblue 33.20200929.n.0 (2020-09-29T08:06:48Z) seems fine though?
Appears fixed; cannot reproduce
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
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).
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.
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.
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?
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.)
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/
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?
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.
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.
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.
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.
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.
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.
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.
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.