After updating last night, VMs using my fedora-35 template on R4.0 are getting “temporary” dns errors. Reverting VMs to fedora-34 is my workaround for today and I’ll probably remove and reinstall fedora-35 then update again to see if it resolves (little pun there).
Anyone else run into this issue after the last fedora-35 update?
B
updating all fedora 35 minimal template yesterday no issue in 4.1
Hmm that thread’s root cause seems to be related to a custom fstab config?
My f35 template is close to vanilla with the exception of enabling some of the optional repos in the repo config.
B
I just noticed complaints about dns in a day or two. I have no issues with fedors-35 on 4.1
Reinstalled fedora-35 and performed initial update. No network issues.
I’ll next try turning on the optional repos and see if that gives a different outcome.
Found it:
If one enables the fedora-updates-testing repo in f35 and then performs an update, dns breaks under R4.0.
I have not dug any deeper but if I
I had to guess, I’d bet it’s related to the systemd-resolved-249.11-1.fc35.x86_64 update which calls out the following specifically during the update:
‘/etc/resolve.conf’ → ‘…/run/systemd/resolve/stub-resolve.conf’
If that is or is related to the cause, it might be a call out to something that needs fixing for f36 too.
B
Followed by
Yes, ludovic, it’s following commands in — for me: Qubes 4.1 — fedora-35 template (latest post on Github Qubes issues by crat0z, 3:47 PM UTC):
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo rm /etc/resolv.conf
sudo touch /etc/resolv.conf
The #7429 issue is now closed and the core-agent-linux v4.1.34 package in the 4.1 fc35 stable yum repository.
So if you get this issue, do an update of your fedora-35 template:
qubes-core-agent:
----------
new:
4.1.34-1.fc35
old:
4.1.33-1.fc35
You will get again the naming resolution.