I upgraded my system today and containers are completely broken. Podman (and thus also toolbx) are both broken and cannot run any containers.
When I try, I get
Error: fork/exec /usr/bin/conmon: permission denied, which leads me to believe it's an SELinux related issue. Sure enough, running
sudo setenforce 0 allows containers to work... but I don't want to have to disable SELinux so I can run toolbx and podman containers... nor should anyone using Fedora 35.
It looks related to https://github.com/containers/container-selinux/issues/170 — but that claimes it was fixed in 2.177.0, whereas this package upgrade seemed to cause the issue here. I've commented on the issue (even thought it's closed; it's the same issue, but with a different version).
This update breaks various apps, including darktable and Leafpad.
A fix has been applied in Pango: https://gitlab.gnome.org/GNOME/pango/-/merge_requests/533
...and a release has been made in Pango 1.50.1: https://gitlab.gnome.org/GNOME/pango/-/tags/1.50.1
Hopefully the new version will appear soon in Fedora.
On Fedora 35:
$ sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ec38b7db52
$ toolbox create 34 -r 34 Creating container 34: | Created container: 34 Enter with: toolbox enter 34
$ toolbox run -c 34 grep PRETTY /etc/os-release PRETTY_NAME="Fedora 34 (Container Image)"
It works here; thanks for the fix!
This update broke wireless on my Thinkpad T14s, which uses an "Intel Corporation Comet Lake PCH-LP CNVi" (AC 9560).
Since an AC 9560 isn't an AX2xx and the firmware was updated in "Update Intel Bluetooth firmware AX211/AX210/AX201/AX200/9560/9260/8265", I guess this is a different issue than what others are seeing.
Rebasing from Silverblue 35 testing to the normal Silverblue 35 beta fixed it (by downgrading the package to non-testing).
This update broke initial connections of Bluetooth headphones with A2DP profiles.
Existing connections from 5.58 or earlier keep working on 5.59 (as evidenced on my personal laptop), but a reinstall of Silverblue on my work laptop made the headphones not work (as it started with 5.59). Other people are having this issue on Fedora and Arch too.
There is an upstream bug at https://github.com/bluez/bluez/issues/157 And there is a patch that fixes this in Bluez git @ https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=0388794dc5fdb73a4ea88bcf148de0a12b4364d4
Sadly, there's no new release of Bluez yet. The only solution at the moment is either downgrading to 5.58, applying the patch and recompiling, or building from git.
These Bugzilla reports are probably also related: https://bugzilla.redhat.com/show_bug.cgi?id=1976795 https://bugzilla.redhat.com/show_bug.cgi?id=1977102 (They're not about headphones specifically, but about bluetooth audio devices that only support A2DP, which do not have a HSP fallback like my Sony XM3 headphones do.)
This version works well!
Previous versions all had issues with my Bluetooth headphones (now even with LDAC and other codec available), switching between outputs, manually switching in GNOME Settings, and flakiness issues.
This version fixes all the issues I was previously having. Everything "just works" as expected now, including having working audio when joining meetings.
This is on bare metal, using Silverblue (with some overrides for PipeWire specifically) with the Fedora 34 beta; daily usage for work. Also tested on bare metal on normal Fedora 34 beta Workstation edition (with the same Bluetooth headphones and USB DAC).
I think I spoke too soon.
I'm now having consistent errors trying to update flatpaks with the new systemd. Ones from Flathub intermittently work, but those from gnome-nightly never do (on the new systemd). It's not just flatpak either, as if I ping the host, it sometimes can reach the network and sometimes cannot. This happens for flatpak, ping, mtr, traceroute.
The older non-caching systemd is fine, however. I rebooted between Silverblue deployments that had the two different versions of systemd several times and it was a consistent problem with this version, but not the other.
Works well here.
Initial lookups are pretty fast, but repeated lookups are super-fast, around 10 - 30 ms, so lookups and caching are both working now.
ls /etc/resolv.conf -l lrwxrwxrwx. 1 root root 39 Mar 18 09:39 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
Current Fedora 34 Beta Silverblue compose (34.20210317.n.0), with a few overrides from bodhi, including systemd.
● ostree://fedora:fedora/34/x86_64/silverblue Version: 34.20210317.n.0 (2021-03-17T08:09:50Z) BaseCommit: 91e84624b4395547a8e3e9f14f334185244d16d69a542cc9c904ced7239aadcd GPGSignature: Valid signature by 8C5BA6990BDB26E19F2A1A801161AE6945719A39 ReplacedBasePackages: pipewire-alsa pipewire-libs pipewire-utils pipewire-jack-audio-connection-kit pipewire-pulseaudio pipewire-gstreamer pipewire 0.3.22-5.fc34 -> 0.3.23-2.fc34, webkit2gtk3 webkit2gtk3-jsc 2.31.1-4.fc34 -> 2.31.91-1.fc34, systemd-udev systemd systemd-networkd systemd-libs systemd-rpm-macros systemd-oomd-defaults systemd-pam 248~rc2-6.fc34 -> 248~rc2-8.fc34
I've been using this for a few hours today. Everything's working well.
Window opens: Yes Processes photos: Yes OpenCL: Yes Lua support: Yes
Thanks for this quick update! The bugfixes this brings are quite nice (especially with the channel mixer).
Works well here! Thanks!
compile options: bit depth is 64 bit normal build SSE2 optimized codepath enabled OpenMP support enabled OpenCL support enabled Lua support enabled, API version 6.1.0 Colord support enabled gPhoto2 support enabled GraphicsMagick support enabled ImageMagick support disabled OpenEXR support enabled
Nice to see everything enabled, including Lua.
I've just upgraded my Silverblue F33 system and did some overrides for
skopeo-1.2.0-10.fc33.x86_64.rpm and then rebooted. Everything's working well here.
I tested out the USB auto-suspend patch in a custom kernel for a few days, which fixed the the problems I was having on my XPS13 with an Atheros WiFi & Bluetooth chip.
After upgrading and testing this kernel build for a few hours (including suspend/resumes), it seems to work perfectly as well.
I still hit the error on both my work and personal laptop, also after exec'ing like you suggest.
This is from my personal laptop:
exec zsh -l /home/garrett/.zgen/robbyrussell/oh-my-zsh-master/lib/theme-and-appearance.zsh:2: colors: function definition file not found /home/garrett/.zgen/robbyrussell/oh-my-zsh-master/oh-my-zsh.sh:77: compinit: function definition file not found zsh: compdef: command not found... ...
I'm pretty sure it also persists even after a reboot. I'll reboot my laptop and try again after posting this.
(Oh, I guess I have two FAS accounts by accident. I thought it was a bit odd that it wouldn't log me into this one and said my name was 'garrettl' and not 'garrett'. Anyway...)
I'm having the same exact issue as mprahi is having, but after upgrading to F27 (pre-beta), which also has the upgraded firmware. While it is Fedora 27 (pre-release) now on my laptop, the current version of linux-firmware is 20170828-76.gitb78acc9, same as this (at least according to the URL).
I've confirmed that a previous version of the firmware for my XPS 13 (9360) QCA6174 by building linux-firmware-20170622-75.gita3a26af2 from a src.rpm (
rpmbuild --rebuild linux-firmware-20170622-75.gita3a26af2.fc26.src.rpm), installing it, and rebooting. Things have been stable for over an hour now on the older firmware, whereas the connection would silently stop working after 5 - 10 minutes with this firmware.
This version of linux-firmware of is basically a huge regression and major deal-breaker for anyone using a recent XPS 13 (which is quite a popular laptop to run Linux on now — approximately half the laptops at GUADEC were XPS 13s, for some idea of how big this issue is).
I upgraded early yesterday, and there hasn't been a single crash since! As I am on Wayland, gnome-shell crashing is a huge deal (as it takes everything else down with it).
This version is at least as good (as it works) and does seem to be much better than the previous (released) version, as it appears to fix the bug. As it's been a complete day without a single crash (as opposed to multiple crashes in a day with the previous version), I can pretty confidently say this fixes the problem.
BTW: Here's the bug where taps to not register: https://bugzilla.redhat.com/show_bug.cgi?id=1414935
(Regression in libinput 1.6, including this build — please note that it worked perfectly fine in 1.5)
Touchpad speed has been drastically improved over previous build (1.5.901-1), but is still too slow, even on maximum setting.
Also, it seems to randomly not register approximately 1/2 of my tap-"clicks".
I agree with Elad — while this is an improvement over the previous build, version 1.5.3 was still much better.
This is on a Dell XPS 9360 (Kaby Lake) with HiDPI running Fedora 25.