Today I saw that running terminal sudo dnf update
It update some, but example google chrome that is installed from fedora third-party Repo only way to update and see updates is gnome app store
That is probably because you use a Flatpak version?
If you want to check this apps in terminal you need to use the flatpak command.
1 Like
Rpm version not flatpak since I can use and lini all extensions to desktop apps too installed sudo dnf install google-chrome-stable not as flatpak unless fedora third-party Repo give only flatpak bow
Not true. Enable the 3rd party repo that is available but not enabled on fedora then google-chrome-stable can be installed directly as an rpm.
Third party repos are active otherwise I couldn’t install chrome or steam and Nvidia drivers
But if you watch in the Software app under the “Software Repositories” point, you can switch them off separately. This might be necessary while you do an update and you get an error about dependencies where are not satisfied.
Please check!
And also … if you check sudo dnf repolist you get the active one.
While pressing tab before enter you see all of them, also de deactivated ones.
You can also use sudo dnf repolist --enabled / --desabled to see what you see in software.
1 Like
phatle@workstation:~$ sudo dnf repolist --enabled
repo id repo name
1password 1Password Stable Channel
copr:copr.fedorainfracloud.org:phracek:PyCharm Copr repo for PyCharm owned by phracek
fedora Fedora 40 - x86_64
fedora-cisco-openh264 Fedora 40 openh264 (From Cisco) - x86_64
google-chrome google-chrome
nordvpn NordVPN YUM repository - x86_64
nordvpn-noarch NordVPN YUM repository - noarch
rpmfusion-nonfree-nvidia-driver RPM Fusion for Fedora 40 - Nonfree - NVIDIA Driver
rpmfusion-nonfree-steam RPM Fusion for Fedora 40 - Nonfree - Steam
updates Fedora 40 - x86_64 - Updates
phatle@workstation:~$ sudo dnf repolist --disabled
repo id repo name
fedora-cisco-openh264-debuginfo Fedora 40 openh264 (From Cisco) - x86_64 - Debug
fedora-cisco-openh264-source Fedora 40 openh264 (From Cisco) - x86_64 - Source
fedora-debuginfo Fedora 40 - x86_64 - Debug
fedora-source Fedora 40 - Source
rpmfusion-nonfree-nvidia-driver-debuginfo RPM Fusion for Fedora 40 - Nonfree - NVIDIA Driver Debug
rpmfusion-nonfree-nvidia-driver-source RPM Fusion for Fedora 40 - Nonfree - NVIDIA Driver Source
rpmfusion-nonfree-steam-debuginfo RPM Fusion for Fedora 40 - Nonfree - Steam Debug
rpmfusion-nonfree-steam-source RPM Fusion for Fedora 40 - Nonfree - Steam Source
updates-debuginfo Fedora 40 - x86_64 - Updates - Debug
updates-source Fedora 40 - Updates Source
updates-testing Fedora 40 - x86_64 - Test Updates
updates-testing-debuginfo Fedora 40 - x86_64 - Test Updates Debug
updates-testing-source Fedora 40 - Test Updates Source
sudo dnf search google-chrome
Last metadata expiration check: 0:59:40 ago on qua 08 mai 2024 10:07:11.
================================================================= Name Matched: google-chrome ==================================================================
google-chrome-beta.x86_64 : Google Chrome (beta)
google-chrome-stable.x86_64 : Google Chrome
google-chrome-unstable.x86_64 : Google Chrome (unstable)
Are you using the stable version?
To see if there is a new stable version available you need to use:
sudo dnf info google-chrome-stable
# if there is a new version it shows both with different colors.
The version makes part of the package name … so searching in DNF needs this info too.
1 Like
yes stable and today morning runned terminal updates got updates but chrome update was pending on gnome app store side thats why i started to ask i have had now 3 updates from google stable from third party repo only from gnome app store not on terminal even i run --refresh when running update command
It is quite difficult to understand your mega sentence with no punctuation. Please take also time to check for that. New lines help also to see better what you mean.
You can also confirm the current stable version by checking here (note that there is a date code in the URL): Chrome Releases: Stable Channel Update for Desktop
The version shown on that website and the version I’m getting when using dnf appear to match for me.
[/root]# rpm -q google-chrome-stable
google-chrome-stable-124.0.6367.155-1.x86_64
[/root]# cat /etc/yum.repos.d/google-chrome.repo
[google-chrome]
name=google-chrome
baseurl=https://dl.google.com/linux/chrome/rpm/stable/x86_64
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://dl.google.com/linux/linux_signing_key.pub
enabled=1
enabled_metadata=1
[/root]# dnf repoquery --repo=google-chrome --nvr google-chrome-stable
Last metadata expiration check: 0:09:55 ago on Wed 08 May 2024 04:11:20 PM UTC.
google-chrome-stable-124.0.6367.155-1
Is this not the case for you?
Maybe you need to update the repo meta data?
You could try:
sudo dnf update --refresh
1 Like
I guess that is what he does… But as I mentioned … format the text a bit would help, to understand what exactly the OP means. For me there is a lot to guess on the OP’s last text.
One-liner I use to update packages and flatpaks with GNOME Terminal; it’s part of a command I bind to a keyboard shortcut and has extra stuff but it’s mainly 3 commands:
gnome-terminal --command "sudo sh -c 'dnf clean 'all' && dnf distro-sync -y && sync && flatpak update && sync && read -n '1' -s -r -p 'Done' && sleep '2''"
I do a dnf clean all to make sure there’s no repo data, and the distro-sync gets fresh repo data and updates (or rarely downgrades) packages based on whatever the enabled repos has at that moment; no ambiguity 
1 Like
still same things running sudo dnf update --refresh
phatle@workstation:~$ sudo dnf update --refresh
Place your right index finger on the fingerprint reader
1Password Stable Channel 6.9 kB/s | 3.0 kB 00:00
Copr repo for PyCharm owned by phracek 1.7 kB/s | 1.8 kB 00:01
Fedora 40 - x86_64 20 kB/s | 23 kB 00:01
Fedora 40 openh264 (From Cisco) - x86_64 1.2 kB/s | 989 B 00:00
Fedora 40 - x86_64 - Updates 22 kB/s | 23 kB 00:01
Fedora 40 - x86_64 - Updates 630 kB/s | 1.8 MB 00:02
google-chrome 7.1 kB/s | 1.3 kB 00:00
NordVPN YUM repository - x86_64 5.8 kB/s | 2.5 kB 00:00
NordVPN YUM repository - noarch 5.8 kB/s | 2.5 kB 00:00
RPM Fusion for Fedora 40 - Nonfree - NVIDIA Dri 7.6 kB/s | 6.5 kB 00:00
RPM Fusion for Fedora 40 - Nonfree - Steam 7.6 kB/s | 6.2 kB 00:00
Dependencies resolved.
Nothing to do.
Complete!
but on gnome software has system updates and flatpaks yes i know flatpaks is difrent method
This is a race condition that happens due to using different mirrors and separate metadata caches for PackageKit and DNF.
GNOME Software relies on the cache created by PackageKit, while running DNF in the terminal creates a separate cache unrelated to PackageKit.
When refreshing DNF metadata, a mirror is selected pseudo-randomly, and sometimes the selected mirror is behind the one used by PackageKit.
If you refresh DNF metadata a few more times, there’s a chance it will pick a more recent mirror, otherwise you should wait a couple of hours and then try again.
2 Likes
even how manny times i hit refresh on dnf update nope something is wierd it shouldent be this complicated or just run all in gnome software again
i guess freedesktop platform is not flatpak and dnf cant update that or find it only gnome software can since i run each time i boot up laptop first dnf updates and then software side and today multiple updates not on dnf only on software only dnf update today i got google chrome stable update
Added updates
The mirror selection process is not actually random as the metalink server returns a list of mirrors with specific preference for each mirror which makes DNF prefer some mirrors over others.
Apparently the preference is calculated based on long-term statistics and may not represent the current sync status of the mirrors.
Depending on the synchronization time and the time of the last update, it may take hours for a specific mirror to fully synchronize.
Refreshing the DNF metadata can help in certain cases:
- There can be multiple mirrors of the same preference or multiple hosting servers of the same mirror with different sync status.
- The highly preferred mirror may become unreachable forcing DNF to switch to less preferred mirrors.
- The preferred mirror that was out of sync can become synchronized again.
- The metalink server can change the preference of the mirrors.
2 Likes
The RPM metadata uses the idea of eventual-consistency. Which means that it will all come good eventually. But at any point in time on any particular mirror it will not necessary be the very latest.
This is rarely an issue. If you update weekly, for example, you may find its a week later that an update turns up. But unless you know that you need that specific update it is very unlikely to be an issue for you.
1 Like