F41 Beta dnf: "update" updates 100+ but "distro-sync" downgrades?

Ask Fedora
,
1

I ran into this over 12 hours ago and figured it was a mirror thing, but it’s still happening as of an hour ago.

update:

sudo dnf clean all && sudo dnf update

Removed 26 files, 16 directories. 0 errors occurred.
Updating and loading repositories:
 RPM Fusion for Fedora 41 - Nonfree                                                             100% |  87.5 KiB/s |  84.0 KiB |  00m01s
 Fedora 41 - x86_64                                                                             100% |   4.0 MiB/s |  35.4 MiB |  00m09s
 RPM Fusion for Fedora 41 - Free                                                                100% | 138.8 KiB/s | 158.7 KiB |  00m01s
 Fedora 41 - x86_64 - Updates                                                                   100% |  58.1 KiB/s |  31.4 KiB |  00m01s
 RPM Fusion for Fedora 41 - Free - Test Updates                                                 100% |  19.4 KiB/s |  10.0 KiB |  00m01s
 RPM Fusion for Fedora 41 - Free tainted                                                        100% |  27.3 KiB/s |   8.4 KiB |  00m00s
 RPM Fusion for Fedora 41 - Nonfree tainted                                                     100% |  29.6 KiB/s |  11.3 KiB |  00m00s
 RPM Fusion for Fedora 41 - Nonfree - Test Updates                                              100% |  25.7 KiB/s |  11.4 KiB |  00m00s
 Fedora 41 openh264 (From Cisco) - x86_64                                                       100% |  10.5 KiB/s |   6.0 KiB |  00m01s
Repositories loaded.
Nothing to do.

distro-sync:

sudo dnf clean all && sudo dnf distro-sync
Removed 48 files, 27 directories. 0 errors occurred.
Updating and loading repositories:
 Fedora 41 - x86_64 - Updates                                                                   100% |  43.7 KiB/s |  31.4 KiB |  00m01s
 RPM Fusion for Fedora 41 - Nonfree                                                             100% | 103.6 KiB/s |  84.0 KiB |  00m01s
 Fedora 41 openh264 (From Cisco) - x86_64                                                       100% |   8.7 KiB/s |   6.0 KiB |  00m01s
 RPM Fusion for Fedora 41 - Free - Test Updates                                                 100% |  36.2 KiB/s |  10.0 KiB |  00m00s
 RPM Fusion for Fedora 41 - Nonfree tainted                                                     100% |  22.3 KiB/s |  11.3 KiB |  00m01s
 RPM Fusion for Fedora 41 - Nonfree - Test Updates                                              100% |  18.3 KiB/s |  12.2 KiB |  00m01s
 RPM Fusion for Fedora 41 - Free tainted                                                        100% |  30.7 KiB/s |   8.4 KiB |  00m00s
 Fedora 41 - x86_64                                                                             100% |   3.7 MiB/s |  35.4 MiB |  00m10s
 RPM Fusion for Fedora 41 - Free                                                                100% | 420.9 KiB/s | 158.7 KiB |  00m00s
Repositories loaded.
Package                                             Arch      Version                                    Repository                 Size
Downgrading:
 adobe-mappings-cmap                                noarch    20230622-4.fc41                            fedora                 14.4 MiB
   replacing adobe-mappings-cmap                    noarch    20231115-1.fc41                            updates-testing        15.2 MiB
 adobe-mappings-cmap-deprecated                     noarch    20230622-4.fc41                            fedora                582.1 KiB
   replacing adobe-mappings-cmap-deprecated         noarch    20231115-1.fc41                            updates-testing       582.1 KiB
 amd-gpu-firmware                                   noarch    20240909-1.fc41                            fedora                 21.1 MiB
   replacing amd-gpu-firmware                       noarch    20241017-1.fc41                            updates-testing        97.6 MiB
 amd-ucode-firmware                                 noarch    20240909-1.fc41                            fedora                241.7 KiB
   replacing amd-ucode-firmware                     noarch    20241017-1.fc41                            updates-testing       450.9 KiB
 anaconda                                           x86_64    41.33-1.fc41                               fedora                  0.0   B

[etc packages]

 vim-filesystem                                     noarch    2:9.1.737-1.fc41                           fedora                 40.0   B
   replacing vim-filesystem                         noarch    2:9.1.785-1.fc41                           updates-testing        40.0   B
 vim-minimal                                        x86_64    2:9.1.737-1.fc41                           fedora                  1.7 MiB
   replacing vim-minimal                            x86_64    2:9.1.785-1.fc41                           updates-testing         1.7 MiB

Transaction Summary:
 Replacing:        163 package
 Downgrading:      163 packages

Total size of inbound packages is 602 MiB. Need to download 602 MiB.
Is this ok [y/N]:

I’ve usually used distro-sync for years and seen something like this maybe twice before, but I want to understand what’s going on a bit better now.

I figured distro-sync to be safer to match packages to known-good versions from a list, vs update that’ll update as soon as something’s available (usually distro-sync wasn’t behind or only had a few minor packages off). In this case with F41 beta there’s a lot of packages that differ between distro-sync and update.

2

I always thought update was the safer thing that did a full transaction test and took care of “obsoletes” type transactions (when the names of the packages change). I normally use update. I’ve always thought of distro-sync as being a “dumber” algorithm that just reads your list of installed packages and updates them one-by-one if a newer version is found. I think that is why distro-sync can work in situations were the normal update command cannot compose a valid transaction (typically in a situation where an update transaction was killed half-way through and the system is half-updated). But I don’t know.

3

distro-sync also downgrade it finds that the latest version in the repository is older than the current installed version. The system-upgrade is basically doing distro-sync after switching the repository to the new release. Sometimes the new release is behind the current release for some packages.

3 Likes
4

There is active work to find and fix the unintended downgrades.
There is a thread on fedora devel mailing list about this.
Some packages are queued up for a 0 day update after f41 is released.

5

It seems that the updates-testing repo, which is enabled during the pre-release phase, got disabled. Maybe with one of the latest updates? Unintentionally?

With the updates-testing repo being disabled, the downgrading proposal of the distro-sync subcommand makes sense.

$ dnf repolist
repo id                                        repo name                                     
copr:copr.fedorainfracloud.org:phracek:PyCharm Copr repo for PyCharm owned by phracek        
fedora                                         Fedora 41 - x86_64                            
fedora-cisco-openh264                          Fedora 41 openh264 (From Cisco) - x86_64      
google-chrome                                  google-chrome                                 
rpmfusion-nonfree-nvidia-driver                RPM Fusion for Fedora 41 - Nonfree - NVIDIA Dr
rpmfusion-nonfree-steam                        RPM Fusion for Fedora 41 - Nonfree - Steam    
updates                                        Fedora 41 - x86_64 - Updates
1 Like
6

Interesting; I noticed that os-release also seemingly dropped mentioning prerelease; so it seems like F41 beta at this point should be distro-sync’d for what’s now expected to be F41’s release?

7

Er, it looks like update updates stuff, distro-sync downgrades and puts F41 back to Prerelease, and distro-sync immediately after that wants to update stuff again?

  • F41 beta install
  • distro-sync
  • Prerelease → not Prerelease
  • update
  • (nothing to install)
  • distro-sync
  • not Prerelease → back to Prerelease
  • distro-sync
  • Prerelease → not Prerelease

It seems like distro-sync can loop between updating and downgrading packages and seems to remove the Test Updates repo when it “updates” the OS to not-Prerelease.

I’m still not quite sure what’s going on, but it seems like update works consistently.

8

AFAIK, after Final Freeze, only packages from updates-testing marked as blocker bugs or freeze exception bugs will go to stable before release, and the rest (the ones marked as stable actually) will go to updates and act as zero-day updates right after release.

However, I would have expected that updates-testing repo would be disabled only after moving stable builds to updates. Looking at the number of proposed packages for downgrade by distro-sync, this might not have taken place yet though.

9

It was disabled 2 days ago, this normally occurs at or around the final freeze.
https://src.fedoraproject.org/rpms/fedora-repos/c/e9eab25676a9e28b9f9e3a18867663ee9fd3c3b9?branch=f41

2 Likes
10

Interesting thing is, though, that with the latest update, an F41 Beta user has not only got the packages fedora-release-identity-workstation, fedora-release-workstation, fedora-repos updated (in preparation of the release), but also a bunch of other packages which might not make it into the final release (and some maybe not even as zero day updates), if I understand correctly.

11

Previously distro-sync downgraded 406 packages (including fedora repos etc)
Now distro-sync only downgrades 352 packages.

Also I got the kernel upgrade and it’s no longer prerelease.
So now it’s fine.

They have also released .iso rc 1.3

12

After updates-testing repo got disabled I just re-enabled it, and seemingly both distro-sync and update do the same thing now (no updates with either after clean).

sudo dnf config-manager 'setopt' 'updates-testing'.'enabled'='1'

sudo dnf repolist

fedora                                                Fedora 41 - x86_64                                                
fedora-cisco-openh264                                 Fedora 41 openh264 (From Cisco) - x86_64                          
rpmfusion-free                                        RPM Fusion for Fedora 41 - Free                                   
rpmfusion-free-tainted                                RPM Fusion for Fedora 41 - Free tainted                           
rpmfusion-free-updates-testing                        RPM Fusion for Fedora 41 - Free - Test Updates                    
rpmfusion-nonfree                                     RPM Fusion for Fedora 41 - Nonfree                                
rpmfusion-nonfree-tainted                             RPM Fusion for Fedora 41 - Nonfree tainted                        
rpmfusion-nonfree-updates-testing                     RPM Fusion for Fedora 41 - Nonfree - Test Updates                 
updates                                               Fedora 41 - x86_64 - Updates                                      
updates-testing                                       Fedora 41 - x86_64 - Test Updates

It seems like to avoid this in the future, if updates-testing gets disabled before a new official release version/date/Go ISO, re-enable it.

Is there any chance of updates-testing getting disabled again? As I understand this is only a thing during pre-release versions when the testing repo gets intentionally disabled, implying RC and final/RTM ISOs will keep updates-testing enabled after that point if the user enabled it? Or will it happen again between this point and when F41 officially releases?

13

No, if you enable it manually it will stay enabled.

If there’s an upgrade to fedora-repos, it will save the new fedora-updates-testing.repo files as fedora-updates-testing.repo.rpmnew. The package manager won’t overwrite your repo files unless you rename the .repo.rpmnew files to just .repo. There’s an utility called rpmconf to handle these cases.

4 Likes