Downgrade from 33 to 32

Is there a way to revert to a previous version of Fedora from the current version?

I have excitedly installed version 33 of fedora over my old version 32, but oh surprise! The connections I make through the VPN from work have completely failed.
I have tried to do a rollback using this command:

dnf system-upgrade download --releasever = 32 --allowerasing
And unfortunately I get this error:
Error: Transaction test error:
file / usr / lib / os-release from install of fedora-release-workstation-32-3.noarch conflicts with file from package fedora-release-identity-basic-33-1.noarch

Does anyone know how to go back to version 32 without having to reinstall the OS completely?

3 Likes

You can try to add --skip-broken to skip uninstallable packages.
Or remove the conflicting packages beforehand with dnf or rpm.

Note that although downgrade should be possible, it is not officially supported.
So you may want to create a separate thread about your VPN issues.

It’s probably going to be easier to debug what is wrong with your VPN, since it’s probably not too complex. You’re likely experiencing some name resolution issue caused by the switch to systemd-resolved. I’ve noticed three other complaints from three different people today and yesterday, so it’s not just you, but there are no bug reports yet.

Let’s start with:

$ resolvectl query example.com

To make sure that fails. (Of course, replace example.com with the domain you are actually trying to resolve.) Then:

$ resolvectl dns
$ resolvectl domain

Post the output for all of these commands (you can replace any non-public domain names if you wish). Hopefully something will appear obviously wrong there. For example, mine says:

$ resolvectl domain
Global:
Link 2 (enp4s0): lan
Link 3 (enp6s0):
Link 4 (wlp5s0):
Link 5 (tun0): ~.
Link 6 (virbr0):
Link 7 (virbr0-nic):
Link 8 (tun1): redhat.com

This means: send all DNS requests for resources on redhat.com to the DNS server associated with tun1, DNS requests for resources on lan to the DNS server associated with enp4s0, and all other DNS to the DNS server associated with tun0. Then I also have:

$ resolvectl dns
Global:
Link 2 (enp4s0): 192.168.1.1
Link 3 (enp6s0):
Link 4 (wlp5s0):
Link 5 (tun0): 10.8.0.1
Link 6 (virbr0):
Link 7 (virbr0-nic):
Link 8 (tun1): 10.11.5.19 10.5.30.160

So, in my case, systemd will direct a request to resolve redhat.com would be sent to 10.11.5.19 or 10.5.30.160 (the DNS servers for my work VPN), while a request for example.com or anything that doesn’t end in redhat.com or lan would go to 10.8.0.1 (the DNS server of my public VPN).

This all should work out-of-the-box, but somehow something has gone wrong in your case. Our quest will be to figure out why. You might need to use dig to test individual DNS servers:

$ dig @8.8.8.8 example.com

This sends a request to resolve example.com to Google’s DNS server. You can try sending that to the servers listed by resolvectl query to see what happens. Replace 8.8.8.8 with the address of the DNS server that you want to test.

Finally, there was a bug in the version of NetworkManager that shipped with F33 that could cause exactly this problem for a small minority of users who connect to misconfigured VPN servers. However, I doubt that affects you, because you upgraded from F32, so you should have the most recent NetworkManager update already. But just to be certain, please run rpm -qi NetworkManager and verify that you have version 1.26.4 (you probably do). If your NetworkManager is older than that (unlikely) then an upgrade is warranted.

4 Likes

Also it seems that some users who upgraded from old versions of Fedora wound up with a strange configuration of /etc/resolv.conf . It is supposed to look like this:

$ ls -l /etc | grep resolv
lrwxrwxrwx. 1 root root        39 Sep  9 14:13 resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

If your resolv.conf is instead a symlink to /var/run/NetworkManager/resolv.conf, that would be a Fedora bug. (If it’s anything else, then something really weird has happened.) You can safely delete and recreate it pointing to ../run/systemd/resolve/stub-resolv.conf.

2 Likes

systemd-resolved is a complete fail at this point for me. But, the good news is it is easy to revert. If you do not wish to use systemd-resolved, then manual intervention will be required to disable it:

Disable and stop systemd-resolved.service.
Delete /etc/resolv.conf
Restart the NetworkManager service. NetworkManager will then create a traditional /etc/resolv.conf. (If you are not using NetworkManager, you may create your own /etc/resolv.conf and configure it to your liking.)
3 Likes

Disabling systemd-resolved is not a recommended solution.
You’d best create a separate thread to discuss your issue in detail.

3 Likes

VPN is not the only problem. ZFS on Linux currently supports only kernels up to 5.6.x. It’s still possible to download Fedora 32 kernel 5.6.6, but Fedora 33 requires kernel version 5.8.

I also upgraded to Fedora 33 and must now downgrade to Fedora 32 - because ZFS is essential for me. Thankfully, this was not on one of my computers which use ZFS as the root filesystem: then I would be really stuffed now. However, the computer where this has happened is now unusable - unless I either sort this out or reinstall everything from scratch.

Advice on how to get around the problem pblmx has asked about would be very much appreciated.

Adding --skip-broken does not work: the transaction still fails and it’s impossible to proceed.

@mcatanzaro I had a very similar issue. Disabling systemd-resolved helped me. I created a bug report here. Let’s sort it out. :slightly_smiling_face:

1 Like

I had this problem before, but without the VPN network. I resolved with remove that conflict package.
In my problem show message

/usr/lib/os-release from install of fedora-release-32-4.noarch conflicts with file from package fedora-release-identity-basic-33-2.noarch

and finally i remove fedora-release-identity-basic-33-2 with command
# rpm -e fedora-release-identity-basic-33-2 --nodeps