This is likely due to No updates since 39.20231205.0 · Issue #516 · fedora-silverblue/issue-tracker · GitHub
2 Likes
you can use this command to check if a new image is available:
ostree remote summary fedora | grep -A3 "fedora/39/x86_64/silverblue"
Do we have a timeline on when Silverblue updates will start moving again?
happened here too, fresh install of silverblue 39.
ostree remote summary fedora | grep -A3 "fedora/39/x86_64/kinoite"
outputs:
* fedora/39/x86_64/kinoite
Latest Commit (77,2 kB):
694f995d4b7ca42e87b393ff3058949dad660e5f2d692338dacaaceab06cd754
Version (ostree.commit.version): 39.20231205.0
(Same for Kinoite 38 and Silverblue 38 and 39).
Also no uptades when I rpm-ostree upgrade --check
1 metadata, 0 content objects fetched; 592 B transferred in 3 seconds; 0 bayt content written
Note: --check and --preview may be unreliable. See https://github.com/coreos/rpm-ostree/issues/1579
No updates available.
Seems like a repo issue. Let’s wait and the magicians do their work 
New base image is now available.
❯ ostree remote summary fedora | rg -A3 "fedora/39/x86_64/silverblue"
* fedora/39/x86_64/silverblue
Latest Commit (61.1 kB):
69c25b9951d821ba85a3fdca4ecf2afeb4317b28ce94d70034a23e31bbd97b3a
Version (ostree.commit.version): 39.20231215.1
Unfortunately, my update process ran into a dependency resolution issue:
❯ rpm-ostree update
⠤ Receiving objects; 99% (8162/8217) 16.9 MB/s 439.8 MB 1547 metadata, 6772 content objects fetched; 438168 KiB transferred in 28 seconds; 898.0 MB content written
Receiving objects; 99% (8162/8217) 16.9 MB/s 439.8 MB... done
Checking out tree 90ccf05... done
Inactive requests:
bluez-obexd (already provided by bluez-obexd-5.70-5.fc39.x86_64)
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora rpmfusion-free-updates rpmfusion-free rpmfusion-nonfree-updates rpmfusion-nonfree updates-archive
Updating metadata for 'fedora-cisco-openh264'... done
Updating metadata for 'updates'... done
Updating metadata for 'fedora'... done
Updating metadata for 'rpmfusion-free-updates'... done
Updating metadata for 'rpmfusion-free'... done
Updating metadata for 'rpmfusion-nonfree-updates'... done
Updating metadata for 'rpmfusion-nonfree'... done
Updating metadata for 'updates-archive'... done
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264'; generated: 2023-03-14T10:57:01Z solvables: 4
rpm-md repo 'updates'; generated: 2023-12-15T01:21:36Z solvables: 16032
rpm-md repo 'fedora'; generated: 2023-11-01T00:12:39Z solvables: 70825
rpm-md repo 'rpmfusion-free-updates'; generated: 2023-12-15T07:43:38Z solvables: 104
rpm-md repo 'rpmfusion-free'; generated: 2023-11-04T16:49:08Z solvables: 445
rpm-md repo 'rpmfusion-nonfree-updates'; generated: 2023-12-15T07:59:03Z solvables: 55
rpm-md repo 'rpmfusion-nonfree'; generated: 2023-11-04T17:26:32Z solvables: 208
rpm-md repo 'updates-archive'; generated: 2023-12-14T01:44:29Z solvables: 16818
Resolving dependencies... done
error: Could not depsolve transaction; 1 problem detected:
Problem: package mesa-vdpau-drivers-freeworld-23.2.1-2.fc39.i686 from rpmfusion-free requires mesa-filesystem(x86-32) = 23.2.1, but none of the providers can be installed
- conflicting requests
- mesa-filesystem-23.2.1-2.fc39.i686 from fedora does not belong to a distupgrade repository
- package mesa-vdpau-drivers-freeworld-23.2.1-2.fc39.x86_64 from rpmfusion-free requires mesa-filesystem(x86-64) = 23.2.1, but none of the providers can be installed
- cannot install both mesa-filesystem-23.2.1-2.fc39.x86_64 from fedora and mesa-filesystem-23.3.0-1.fc39.x86_64 from @System
It indicates a conflict between different versions of the mesa-filesystem package because mesa-filesystem-23.2.1-2.fc39.i686 from fedora does not belong to a distupgrade repository. However, according to the Fedora package database (mesa-filesystem-23.2.1-2.fc39 - Fedora Packages), this package is currently stable on Fedora 39, which is puzzling. I’ve never encountered this kind of issue before.
Any help is appreciated.
The update to mesa 23.3 was just now pushed to stable with this compose (20231215.1). RPM Fusion needs to push the corresponding mesa-freeworld update.
Why do you have that layered though? For the base image firefox?
1 Like
Thank you! I had indeed layered mesa-va-drivers-freeworld and mesa-vdpau-drivers-freeworld for Firefox. I removed these drivers and noticed an update to the mesa drivers:
mesa-dri-drivers 23.2.1-2.fc39 -> 23.3.0-1.fc39
mesa-filesystem 23.2.1-2.fc39 -> 23.3.0-1.fc39
mesa-libEGL 23.2.1-2.fc39 -> 23.3.0-1.fc39
mesa-libGL 23.2.1-2.fc39 -> 23.3.0-1.fc39
mesa-libgbm 23.2.1-2.fc39 -> 23.3.0-1.fc39
mesa-libglapi 23.2.1-2.fc39 -> 23.3.0-1.fc39
mesa-libxatracker 23.2.1-2.fc39 -> 23.3.0-1.fc39
mesa-vulkan-drivers 23.2.1-2.fc39 -> 23.3.0-1.fc39
I’ll now wait for the update from rpm fusion.