#1

TLDR; something is blocking some (but not all) flatpak connections to the internet, I dont know how to diagnose.

Since a couple of weeks ago I have been experiencing this problem and it is a strange one. I am not sure if it is silverblue, flatpak or the apps.

Platform: Fedora SIlverblue 34 (pre-release)

In flatpaked web browsers (edge, Firefox from Flathub) I cannot access certain urls such as https://www.bbc.co.uk and others seem to be missing some stylesheets (I havent checked but I suspect from CDN’s).

I get a server not found error.

For the normal firefox that is part of silverblue, the same urls work.

I have no proxy and AFAIK no non default settings that would involve connections.

How do I even go about trying to figure out where the problem lies?

EDIT - just checked flatpaked ungoogled-chromium and beta chrome, both display bbc.co.uk but with incomplete style sheets.

#2

Yeah, a few of us on the Cockpit team who are using the Firefox flatpak on F34 beta Silverblue noticed the same issue. It looks like it’s related to the split-dns of Fedora?

That’s why some sites don’t work, and others have broken CSS (due to having CSS and/or JS hosted from another site).

A workaround, for the time being, is to enable DoH (DNS over HTTPS) in Firefox. Hopefully they fix this soon, as I don’t want to use Cloludflare, but my own pi-hole DNS server at home.

#3

Note: It’s most obvious in Firefox in a Flatpak, but I’m also seeing the same issue with the Epiphany Technology Preview as a Flatpak too. (The difference is that Firefox has the DoH workaround, so it’s possible to keep using it by changing the DNS server it uses.)

Some sites like GitHub.com work, but others, such as Amazon.de / Amazon.com do not. Consistently.

I’ve been looking for already-open issues in all sorts of bug trackers, but haven’t found one yet. I did see Owen’s comment at Fix nss-resolve to properly fallback in a Flatpak sandbox by owtaylor · Pull Request #85 · systemd/systemd-stable · GitHub where systemd prior to 247 use one method and 247 and after (including the 248~rc2 version Fedora 34 beta has) uses varlink.

Perhaps varlink’s the difference why apps in a Flatpak don’t always work with the new systemd-resolved? Just a guess.

#4

I filed this upstream with Flatpak @ Flatpak apps sometimes fail at DNS on Fedora 34 beta / systemd 248~rc2 · Issue #4162 · flatpak/flatpak · GitHub as it seems only Flatpaks are affected, even if it might be systemd related.

(Not sure where the bug is, but it’s not in Firefox, as Epiphany is also affected, so it must be in Flatpak or systemd-resolved or how they talk to each other).

Note: This isn’t Silverblue-specific. I upgraded my personal laptop to F34 beta too, and (unlike my work laptop) it’s not (yet) running Silverblue (due to a Silverblue installation bug).

#5

I was able to solve that by running:

sudo cp -aT /usr/etc/NetworkManager/NetworkManager.conf /etc/NetworkManager/NetworkManager.conf

#6

Thanks for filing the upstream bug, I will keep an eye out on any updates here and there.

#7

There have been some fixes that resolve most of the issues @ https://bodhi.fedoraproject.org/updates/FEDORA-2021-ead59f24eb

But it’s not 100%.

A workaround for everything is to become root (sudo -s) and:

cd /etc
mv resolv.conf resolv.conf-old
ln -s ../run/NetworkManager/resolv.conf
systemctl restart NetworkManager.service

This moves the old symlink from systemd’s @ ../run/systemd/resolve/stub-resolv.conf to networkmanager’s @ ../run/NetworkManager/resolv.conf and then restarts your network to make it active.

Be sure to do the symbolic link relatively like this, else it may otherwise break toolbox/podman containers.

To reset to normal, remove the resolve.conf file and move the resolve.conf-old back to resolve.conf… then restart network again.

#9

For me it seems 100% solved with this systemd update:

$ rpm -q systemd
systemd-248~rc2-3.fc34.x86_64
#10

I’m still having issues with systemd-248~rc2-3.fc34.x86_64 here on my F34 beta Workstation laptop and F34 beta Silverblue laptop, as are my coworkers.

It’s certainly a lot better, but a few problems still exist.

#11

Same here. Yesterday I spoke too soon.

I’m following bug 1933433.

1 Like