Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all updates that are available? Is there a configuration that needs to be done to alleviate this that is not done in an "out of the box" install, or, is this telling me that we shouldn't be doing updates with dnf we should be using Discovery instead?
regards, Steve
On 2021-06-27 1:31 a.m., Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all updates that are available? Is there a configuration that needs to be done to alleviate this that is not done in an "out of the box" install, or, is this telling me that we shouldn't be doing updates with dnf we should be using Discovery instead?
What is "Discovery"?
On 27/06/2021 16:53, Samuel Sieb wrote:
On 2021-06-27 1:31 a.m., Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all updates that are available? Is there a configuration that needs to be done to alleviate this that is not done in an "out of the box" install, or, is this telling me that we shouldn't be doing updates with dnf we should be using Discovery instead?
What is "Discovery"?
It is actually "discover". But it is launched as plasma-discover. And is
Description : KDE and Plasma resources management GUI
a.k.a. "Software Center"
I never use it.
On 27/06/2021 16:31, Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all updates that are available? Is there a configuration that needs to be done to alleviate this that is not done in an "out of the box" install, or, is this telling me that we shouldn't be doing updates with dnf we should be using Discovery instead?
I've not looked at what goes on during the upgrade process. That is going from a previous release of Fedora to a later version of Fedora. I suspect that the upgrade process just compares what you have on your system with what packages are available in the fedora.repo (which doesn't change) and doesn't look at the fedora-updates.repo since looking in both places and keeping track of what package should be upgraded from which repo would be much more work. Especially in the case of where an update of some packages may change dependencies or pull in packages not used previously.
So, it would be a much simpler process to upgrade from the released repo and then do normal updates later.
Hey, at least it isn't like Windows. I have a Windows 10 VM that I rarely use. When I do use it, and updates are applied, it is a constant cycle of "Download updates, apply updates, reboot" and rinse/repeat
On 27/6/21 21:28, Ed Greshko wrote:
On 27/06/2021 16:31, Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all updates that are available? Is there a configuration that needs to be done to alleviate this that is not done in an "out of the box" install, or, is this telling me that we shouldn't be doing updates with dnf we should be using Discovery instead?
I've not looked at what goes on during the upgrade process. That is going from a previous release of Fedora to a later version of Fedora. I suspect that the upgrade process just compares what you have on your system with what packages are available in the fedora.repo (which doesn't change) and doesn't look at the fedora-updates.repo since looking in both places and keeping track of what package should be upgraded from which repo would be much more work. Especially in the case of where an update of some packages may change dependencies or pull in packages not used previously.
So, it would be a much simpler process to upgrade from the released repo and then do normal updates later.
I have always used dnf upgrade for normal updates. From what I've found dnf update and dnf upgrade do the same thing and apply updates/installs from all active repositories, or is there a difference between the two?
I only looked at discover because I was looking at trying to use a package that wasn't installed, and I was told to use Discover to install it (I don't remember which package is was and I couldn't find how to install it from Discover, so I finished up using flatpak).
regards, Steve
Hey, at least it isn't like Windows. I have a Windows 10 VM that I rarely use. When I do use it, and updates are applied, it is a constant cycle of "Download updates, apply updates, reboot" and rinse/repeat
On 27/06/2021 20:24, Stephen Morris wrote:
On 27/6/21 21:28, Ed Greshko wrote:
On 27/06/2021 16:31, Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all updates that are available? Is there a configuration that needs to be done to alleviate this that is not done in an "out of the box" install, or, is this telling me that we shouldn't be doing updates with dnf we should be using Discovery instead?
I've not looked at what goes on during the upgrade process. That is going from a previous release of Fedora to a later version of Fedora. I suspect that the upgrade process just compares what you have on your system with what packages are available in the fedora.repo (which doesn't change) and doesn't look at the fedora-updates.repo since looking in both places and keeping track of what package should be upgraded from which repo would be much more work. Especially in the case of where an update of some packages may change dependencies or pull in packages not used previously.
So, it would be a much simpler process to upgrade from the released repo and then do normal updates later.
I have always used dnf upgrade for normal updates. From what I've found dnf update and dnf upgrade do the same thing and apply updates/installs from all active repositories, or is there a difference between the two?
No, they do the same thing. I misunderstood your original post. Mostly because that upgrade/update are used interchangeably.
I thought you were speaking of "dnf system-upgrade"
I only looked at discover because I was looking at trying to use a package that wasn't installed, and I was told to use Discover to install it (I don't remember which package is was and I couldn't find how to install it from Discover, so I finished up using flatpak).
OK. Well in that case nothing can be speculated.
On 27/6/21 22:30, Ed Greshko wrote:
On 27/06/2021 20:24, Stephen Morris wrote:
On 27/6/21 21:28, Ed Greshko wrote:
On 27/06/2021 16:31, Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all updates that are available? Is there a configuration that needs to be done to alleviate this that is not done in an "out of the box" install, or, is this telling me that we shouldn't be doing updates with dnf we should be using Discovery instead?
I've not looked at what goes on during the upgrade process. That is going from a previous release of Fedora to a later version of Fedora. I suspect that the upgrade process just compares what you have on your system with what packages are available in the fedora.repo (which doesn't change) and doesn't look at the fedora-updates.repo since looking in both places and keeping track of what package should be upgraded from which repo would be much more work. Especially in the case of where an update of some packages may change dependencies or pull in packages not used previously.
So, it would be a much simpler process to upgrade from the released repo and then do normal updates later.
I have always used dnf upgrade for normal updates. From what I've found dnf update and dnf upgrade do the same thing and apply updates/installs from all active repositories, or is there a difference between the two?
No, they do the same thing. I misunderstood your original post. Mostly because that upgrade/update are used interchangeably.
I thought you were speaking of "dnf system-upgrade"
No problems, it's all good.
regards, Steve
I only looked at discover because I was looking at trying to use a package that wasn't installed, and I was told to use Discover to install it (I don't remember which package is was and I couldn't find how to install it from Discover, so I finished up using flatpak).
OK. Well in that case nothing can be speculated.
On 2021-06-27 4:28 a.m., Ed Greshko wrote:
On 27/06/2021 16:31, Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all updates that are available? Is there a configuration that needs to be done to alleviate this that is not done in an "out of the box" install, or, is this telling me that we shouldn't be doing updates with dnf we should be using Discovery instead?
I've not looked at what goes on during the upgrade process. That is going from a previous release of Fedora to a later version of Fedora. I suspect that the upgrade process just compares what you have on your system with what packages are available in the fedora.repo (which doesn't change) and doesn't look at the fedora-updates.repo since looking in both places and keeping track of what package should be upgraded from which repo would be much more work. Especially in the case of where an update of some packages may change dependencies or pull in packages not used previously.
system-update uses all the repos you have enabled, including the updates repo. After system-update, you should be fully up-to-date.
On 28/6/21 05:01, Samuel Sieb wrote:
On 2021-06-27 4:28 a.m., Ed Greshko wrote:
On 27/06/2021 16:31, Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all updates that are available? Is there a configuration that needs to be done to alleviate this that is not done in an "out of the box" install, or, is this telling me that we shouldn't be doing updates with dnf we should be using Discovery instead?
I've not looked at what goes on during the upgrade process. That is going from a previous release of Fedora to a later version of Fedora. I suspect that the upgrade process just compares what you have on your system with what packages are available in the fedora.repo (which doesn't change) and doesn't look at the fedora-updates.repo since looking in both places and keeping track of what package should be upgraded from which repo would be much more work. Especially in the case of where an update of some packages may change dependencies or pull in packages not used previously.
system-update uses all the repos you have enabled, including the updates repo. After system-update, you should be fully up-to-date.
What is system-update, is that functionality provided by another dnf plugin?
regards, Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 28/06/2021 07:06, Stephen Morris wrote:
On 28/6/21 05:01, Samuel Sieb wrote:
On 2021-06-27 4:28 a.m., Ed Greshko wrote:
On 27/06/2021 16:31, Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all updates that are available? Is there a configuration that needs to be done to alleviate this that is not done in an "out of the box" install, or, is this telling me that we shouldn't be doing updates with dnf we should be using Discovery instead?
I've not looked at what goes on during the upgrade process. That is going from a previous release of Fedora to a later version of Fedora. I suspect that the upgrade process just compares what you have on your system with what packages are available in the fedora.repo (which doesn't change) and doesn't look at the fedora-updates.repo since looking in both places and keeping track of what package should be upgraded from which repo would be much more work. Especially in the case of where an update of some packages may change dependencies or pull in packages not used previously.
system-update uses all the repos you have enabled, including the updates repo. After system-update, you should be fully up-to-date.
What is system-update, is that functionality provided by another dnf plugin?
That would be the command you'd use when upgrading to the next version Fedora when it becomes available.
Yes, it is a dnf plugin. "sudo dnf install dnf-plugin-system-upgrade"
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ may be helpful when time to upgrade.
On 28/6/21 09:43, Ed Greshko wrote:
On 28/06/2021 07:06, Stephen Morris wrote:
On 28/6/21 05:01, Samuel Sieb wrote:
On 2021-06-27 4:28 a.m., Ed Greshko wrote:
On 27/06/2021 16:31, Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all updates that are available? Is there a configuration that needs to be done to alleviate this that is not done in an "out of the box" install, or, is this telling me that we shouldn't be doing updates with dnf we should be using Discovery instead?
I've not looked at what goes on during the upgrade process. That is going from a previous release of Fedora to a later version of Fedora. I suspect that the upgrade process just compares what you have on your system with what packages are available in the fedora.repo (which doesn't change) and doesn't look at the fedora-updates.repo since looking in both places and keeping track of what package should be upgraded from which repo would be much more work. Especially in the case of where an update of some packages may change dependencies or pull in packages not used previously.
system-update uses all the repos you have enabled, including the updates repo. After system-update, you should be fully up-to-date.
What is system-update, is that functionality provided by another dnf plugin?
That would be the command you'd use when upgrading to the next version Fedora when it becomes available.
That's okay, I've used that before, I just thought Samuel might have been referring to something different, its all good.
regards, Steve
Yes, it is a dnf plugin. "sudo dnf install dnf-plugin-system-upgrade"
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ may be helpful when time to upgrade.
On Sun, 2021-06-27 at 18:31 +1000, Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all done to alleviate this that is not done in an "out of the box" install, should be using Discovery instead?
I think plasma-discover uses PackageKit. As has been noted several times here, mixing dnf and PK often leads to confusion. Better pick one and stick with it.
Personally, I erased PK and don't use plasma-discover, and I don't see these kinds of problem.
poc
On 27/06/2021 20:00, Patrick O'Callaghan wrote:
On Sun, 2021-06-27 at 18:31 +1000, Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all done to alleviate this that is not done in an "out of the box" install, should be using Discovery instead?
I think plasma-discover uses PackageKit. As has been noted several times here, mixing dnf and PK often leads to confusion. Better pick one and stick with it.
Personally, I erased PK and don't use plasma-discover, and I don't see these kinds of problem.
I probably misunderstood the OP. I haven't (yet) banished packageKit from my system.
I have not had a situation where an update was performed and immediately followed by a need for another update. I do my updates with "dnf --refresh update".
The only thing I've seen is when packageKit is telling me there are updates but when dnf runs it says no updates are available. I attribute that to packageKit using different mirrors than dnf.
On 27/6/21 22:23, Ed Greshko wrote:
On 27/06/2021 20:00, Patrick O'Callaghan wrote:
On Sun, 2021-06-27 at 18:31 +1000, Stephen Morris wrote:
Hi, I have just done a sudo dnf upgrade on F34 which I think upgraded 1311 packages. After the update finished I rebooted F34 and then ran discovery and it was still telling me there was 628 MB of F34 Platform updates to put on, which I did put on. Why is dnf not installing all done to alleviate this that is not done in an "out of the box" install, should be using Discovery instead?
I think plasma-discover uses PackageKit. As has been noted several times here, mixing dnf and PK often leads to confusion. Better pick one and stick with it.
Personally, I erased PK and don't use plasma-discover, and I don't see these kinds of problem.
I probably misunderstood the OP. I haven't (yet) banished packageKit from my system.
I have not had a situation where an update was performed and immediately followed by a need for another update. I do my updates with "dnf --refresh update".
The only thing I've seen is when packageKit is telling me there are updates but when dnf runs it says no updates are available. I attribute that to packageKit using different mirrors than dnf.
I hadn't realised Discover was using Packagekit. If it is using different mirrors to dnf and they indicate they have updates over and above what dnf has applied, does that mean dnf will catch up, or are they updates that dnf will never put on because it never sees them? While we are on the topic of updates with dnf, I have noticed that when dnf goes to a mirror to find an update, if it can't find the package it produces a 404 error, and keeps producing that error when it goes to the next mirror, etc. Is there any way to get dnf to only produce the 404 error if the required package can't be found in any mirror?
regards, Steve
On 27/06/2021 20:34, Stephen Morris wrote:
I hadn't realised Discover was using Packagekit. If it is using different mirrors to dnf and they indicate they have updates over and above what dnf has applied, does that mean dnf will catch up, or are they updates that dnf will never put on because it never sees them?
Oh, dnf will "catch up" as more mirrors are synced. You'll never have a case where an update is available via PK but never becomes available when using dnf.
While we are on the topic of updates with dnf, I have noticed that when dnf goes to a mirror to find an update, if it can't find the package it produces a 404 error, and keeps producing that error when it goes to the next mirror, etc. Is there any way to get dnf to only produce the 404 error if the required package can't be found in any mirror?
It gets the 404 error since it uses curl to download.
I see no way to avoid what you've seen. It happens only occasionally so I never thought about it.
On 27/06/2021 20:43, Ed Greshko wrote:
On 27/06/2021 20:34, Stephen Morris wrote:
I hadn't realised Discover was using Packagekit. If it is using different mirrors to dnf and they indicate they have updates over and above what dnf has applied, does that mean dnf will catch up, or are they updates that dnf will never put on because it never sees them?
Oh, dnf will "catch up" as more mirrors are synced. You'll never have a case where an update is available via PK but never becomes available when using dnf.
While we are on the topic of updates with dnf, I have noticed that when dnf goes to a mirror to find an update, if it can't find the package it produces a 404 error, and keeps producing that error when it goes to the next mirror, etc. Is there any way to get dnf to only produce the 404 error if the required package can't be found in any mirror?
It gets the 404 error since it uses curl to download.
I see no way to avoid what you've seen. It happens only occasionally so I never thought about it.
Hit send before I completed my thought.
I think it "wise" to do as poc has done. Get rid of packageKit and plasma-discover. Running 2 update utilities can lead to confusion.
On 27/06/2021 20:45, Ed Greshko wrote:
On 27/06/2021 20:43, Ed Greshko wrote:
On 27/06/2021 20:34, Stephen Morris wrote:
I hadn't realised Discover was using Packagekit. If it is using different mirrors to dnf and they indicate they have updates over and above what dnf has applied, does that mean dnf will catch up, or are they updates that dnf will never put on because it never sees them?
Oh, dnf will "catch up" as more mirrors are synced. You'll never have a case where an update is available via PK but never becomes available when using dnf.
While we are on the topic of updates with dnf, I have noticed that when dnf goes to a mirror to find an update, if it can't find the package it produces a 404 error, and keeps producing that error when it goes to the next mirror, etc. Is there any way to get dnf to only produce the 404 error if the required package can't be found in any mirror?
It gets the 404 error since it uses curl to download.
I see no way to avoid what you've seen. It happens only occasionally so I never thought about it.
Hit send before I completed my thought.
I think it "wise" to do as poc has done. Get rid of packageKit and plasma-discover. Running 2 update utilities can lead to confusion.
Again with the fast finger.
I always install dnfdragora-updater and use that for notifications of when package updates are available. But, I use dnf from the command line to do the actual update as I have an alias to do the update via dnf and that is easier than clicking on things and I like to see what is going on.
On 27/6/21 22:52, Ed Greshko wrote:
On 27/06/2021 20:45, Ed Greshko wrote:
On 27/06/2021 20:43, Ed Greshko wrote:
On 27/06/2021 20:34, Stephen Morris wrote:
I hadn't realised Discover was using Packagekit. If it is using different mirrors to dnf and they indicate they have updates over and above what dnf has applied, does that mean dnf will catch up, or are they updates that dnf will never put on because it never sees them?
Oh, dnf will "catch up" as more mirrors are synced. You'll never have a case where an update is available via PK but never becomes available when using dnf.
While we are on the topic of updates with dnf, I have noticed that when dnf goes to a mirror to find an update, if it can't find the package it produces a 404 error, and keeps producing that error when it goes to the next mirror, etc. Is there any way to get dnf to only produce the 404 error if the required package can't be found in any mirror?
It gets the 404 error since it uses curl to download.
I see no way to avoid what you've seen. It happens only occasionally so I never thought about it.
Hit send before I completed my thought.
I think it "wise" to do as poc has done. Get rid of packageKit and plasma-discover. Running 2 update utilities can lead to confusion.
Again with the fast finger.
I always install dnfdragora-updater and use that for notifications of when package updates are available. But, I use dnf from the command line to do the actual update as I have an alias to do the update via dnf and that is easier than clicking on things and I like to see what is going on.
I normally use dnf to apply updates and use dnfdragora to browse the repositories to see what is available and what might be useful to me. I haven't installed dnfdragora-updater (I had forgotten that was available) as yet, but I should as discover is notifying of updates. The only reason I went to Discover to check updates after putting on the updates that dnf provided, was I was once in a situation where I was trying to use a product that wasn't installed and I was given installation instructions to install it via Discover, but I couldn't find it in Discover nor dnf so I installed it via a flatpak (unfortunately I don't remember what the product was).
regards, Steve
On 27/6/21 22:43, Ed Greshko wrote:
On 27/06/2021 20:34, Stephen Morris wrote:
I hadn't realised Discover was using Packagekit. If it is using different mirrors to dnf and they indicate they have updates over and above what dnf has applied, does that mean dnf will catch up, or are they updates that dnf will never put on because it never sees them?
Oh, dnf will "catch up" as more mirrors are synced. You'll never have a case where an update is available via PK but never becomes available when using dnf.
Thanks Ed, I thought that was the case but I was just checking.
While we are on the topic of updates with dnf, I have noticed that when dnf goes to a mirror to find an update, if it can't find the package it produces a 404 error, and keeps producing that error when it goes to the next mirror, etc. Is there any way to get dnf to only produce the 404 error if the required package can't be found in any mirror?
It gets the 404 error since it uses curl to download.
I see no way to avoid what you've seen. It happens only occasionally so I never thought about it.
I thought that might be the case. Because I was updating a large number of packages I was seeing this message around a dozen times on various packages. I am assuming that if dnf gets to the situation where it can't find the package in any mirror, that it will suspend that update and any associated updates but continue on with the rest of the updates that are available and check again with the next update to see if it can then find the "missing" package?
regards, Steve
On 28/06/2021 07:12, Stephen Morris wrote:
On 27/6/21 22:43, Ed Greshko wrote:
On 27/06/2021 20:34, Stephen Morris wrote:
I hadn't realised Discover was using Packagekit. If it is using different mirrors to dnf and they indicate they have updates over and above what dnf has applied, does that mean dnf will catch up, or are they updates that dnf will never put on because it never sees them?
Oh, dnf will "catch up" as more mirrors are synced. You'll never have a case where an update is available via PK but never becomes available when using dnf.
Thanks Ed, I thought that was the case but I was just checking.
While we are on the topic of updates with dnf, I have noticed that when dnf goes to a mirror to find an update, if it can't find the package it produces a 404 error, and keeps producing that error when it goes to the next mirror, etc. Is there any way to get dnf to only produce the 404 error if the required package can't be found in any mirror?
It gets the 404 error since it uses curl to download.
I see no way to avoid what you've seen. It happens only occasionally so I never thought about it.
I thought that might be the case. Because I was updating a large number of packages I was seeing this message around a dozen times on various packages. I am assuming that if dnf gets to the situation where it can't find the package in any mirror, that it will suspend that update and any associated updates but continue on with the rest of the updates that are available and check again with the next update to see if it can then find the "missing" package?
It hasn't happened to me in a while, so I can't be certain.
I think (grain of salt) if none of the downloaded package updates depend on packages not downloaded it will update those.
Either way, it is harmless and will be sorted out in time.
On 2021-06-27 4:12 p.m., Stephen Morris wrote:
On 27/6/21 22:43, Ed Greshko wrote:
On 27/06/2021 20:34, Stephen Morris wrote:
While we are on the topic of updates with dnf, I have noticed that when dnf goes to a mirror to find an update, if it can't find the package it produces a 404 error, and keeps producing that error when it goes to the next mirror, etc. Is there any way to get dnf to only produce the 404 error if the required package can't be found in any mirror?
It gets the 404 error since it uses curl to download.
I see no way to avoid what you've seen. It happens only occasionally so I never thought about it.
I thought that might be the case. Because I was updating a large number of packages I was seeing this message around a dozen times on various packages. I am assuming that if dnf gets to the situation where it can't find the package in any mirror, that it will suspend that update and any associated updates but continue on with the rest of the updates that are available and check again with the next update to see if it can then find the "missing" package?
If dnf can't find a package on any mirror, it will immediately abort the entire transaction. Otherwise, it would have go through the whole dependency resolution process again.
On 28/6/21 10:12, Samuel Sieb wrote:
On 2021-06-27 4:12 p.m., Stephen Morris wrote:
On 27/6/21 22:43, Ed Greshko wrote:
On 27/06/2021 20:34, Stephen Morris wrote:
While we are on the topic of updates with dnf, I have noticed that when dnf goes to a mirror to find an update, if it can't find the package it produces a 404 error, and keeps producing that error when it goes to the next mirror, etc. Is there any way to get dnf to only produce the 404 error if the required package can't be found in any mirror?
It gets the 404 error since it uses curl to download.
I see no way to avoid what you've seen. It happens only occasionally so I never thought about it.
I thought that might be the case. Because I was updating a large number of packages I was seeing this message around a dozen times on various packages. I am assuming that if dnf gets to the situation where it can't find the package in any mirror, that it will suspend that update and any associated updates but continue on with the rest of the updates that are available and check again with the next update to see if it can then find the "missing" package?
If dnf can't find a package on any mirror, it will immediately abort the entire transaction. Otherwise, it would have go through the whole dependency resolution process again.
So does that then mean that we have to keep issuing the dnf upgrade statement until the issue is resolved, which may or may not be a quick fix depending on what the issue is?
regards, Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 2021-06-27 7:59 p.m., Stephen Morris wrote:
On 28/6/21 10:12, Samuel Sieb wrote:
On 2021-06-27 4:12 p.m., Stephen Morris wrote:
On 27/6/21 22:43, Ed Greshko wrote:
On 27/06/2021 20:34, Stephen Morris wrote:
While we are on the topic of updates with dnf, I have noticed that when dnf goes to a mirror to find an update, if it can't find the package it produces a 404 error, and keeps producing that error when it goes to the next mirror, etc. Is there any way to get dnf to only produce the 404 error if the required package can't be found in any mirror?
It gets the 404 error since it uses curl to download.
I see no way to avoid what you've seen. It happens only occasionally so I never thought about it.
I thought that might be the case. Because I was updating a large number of packages I was seeing this message around a dozen times on various packages. I am assuming that if dnf gets to the situation where it can't find the package in any mirror, that it will suspend that update and any associated updates but continue on with the rest of the updates that are available and check again with the next update to see if it can then find the "missing" package?
If dnf can't find a package on any mirror, it will immediately abort the entire transaction. Otherwise, it would have go through the whole dependency resolution process again.
So does that then mean that we have to keep issuing the dnf upgrade statement until the issue is resolved, which may or may not be a quick fix depending on what the issue is?
A 404 means that a sync is ongoing and not completed yet. It's extremely unlikely that a file will be missing on all mirrors unless you're very unlucky. :-) In any case, you shouldn't have to wait very long.
On 2021-06-27 5:34 a.m., Stephen Morris wrote:
On 27/6/21 22:23, Ed Greshko wrote:
I have not had a situation where an update was performed and immediately followed by a need for another update. I do my updates with "dnf --refresh update".
The only thing I've seen is when packageKit is telling me there are updates but when dnf runs it says no updates are available. I attribute that to packageKit using different mirrors than dnf.
I hadn't realised Discover was using Packagekit. If it is using different mirrors to dnf and they indicate they have updates over and above what dnf has applied, does that mean dnf will catch up, or are they updates that dnf will never put on because it never sees them?
It's not that they use different mirrors. The mirror manager provides somewhat randomized mirrors when asked, so at different times, you can end up looking at different mirrors. And it's possible, if you check during the syncing time, that different mirrors have different available updates.
On 28/6/21 04:59, Samuel Sieb wrote:
On 2021-06-27 5:34 a.m., Stephen Morris wrote:
On 27/6/21 22:23, Ed Greshko wrote:
I have not had a situation where an update was performed and immediately followed by a need for another update. I do my updates with "dnf --refresh update".
The only thing I've seen is when packageKit is telling me there are updates but when dnf runs it says no updates are available. I attribute that to packageKit using different mirrors than dnf.
I hadn't realised Discover was using Packagekit. If it is using different mirrors to dnf and they indicate they have updates over and above what dnf has applied, does that mean dnf will catch up, or are they updates that dnf will never put on because it never sees them?
It's not that they use different mirrors. The mirror manager provides somewhat randomized mirrors when asked, so at different times, you can end up looking at different mirrors. And it's possible, if you check during the syncing time, that different mirrors have different available updates.
I thought dnf had a list of mirrors and the first time dnf was run it used the first mirror in the list, and kept using that mirror until it got a 404 situation on a package whereby it would go to the next mirror and if the package was obtained from that mirror, it would continue using that mirror for all updates until that produced a 404 situation, in which case it would move to the next mirror and so on. I've been finding it nothing unusual for Discover monitoring process to tell me there were updates available, even after using dnf to put on all updates it can see, and go and issue a dnf upgrade and have dnf tell me there was nothing to do.
regards, Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 2021-06-27 4:27 p.m., Stephen Morris wrote:
On 28/6/21 04:59, Samuel Sieb wrote:
On 2021-06-27 5:34 a.m., Stephen Morris wrote:
On 27/6/21 22:23, Ed Greshko wrote:
I have not had a situation where an update was performed and immediately followed by a need for another update. I do my updates with "dnf --refresh update".
The only thing I've seen is when packageKit is telling me there are updates but when dnf runs it says no updates are available. I attribute that to packageKit using different mirrors than dnf.
I hadn't realised Discover was using Packagekit. If it is using different mirrors to dnf and they indicate they have updates over and above what dnf has applied, does that mean dnf will catch up, or are they updates that dnf will never put on because it never sees them?
It's not that they use different mirrors. The mirror manager provides somewhat randomized mirrors when asked, so at different times, you can end up looking at different mirrors. And it's possible, if you check during the syncing time, that different mirrors have different available updates.
I thought dnf had a list of mirrors and the first time dnf was run it used the first mirror in the list, and kept using that mirror until it got a 404 situation on a package whereby it would go to the next mirror and if the package was obtained from that mirror, it would continue using that mirror for all updates until that produced a 404 situation, in which case it would move to the next mirror and so on. I've been finding it nothing unusual for Discover monitoring process to tell me there were updates available, even after using dnf to put on all updates it can see, and go and issue a dnf upgrade and have dnf tell me there was nothing to do.
The default repo configuration is to use the mirror manager. So dnf asks the mirror manager for a list of mirrors and it starts with the first one. I'm not sure if it completely abandons a certain mirror on the first 404, but it does go to another one for at least that file. I don't understand why Discover will tell you that there are more updates available. dnf does cache the current state for a while, so you could try adding "--refresh" to the dnf command to force it to check. But Packagekit uses the same configuration as dnf and I think it even uses the same underlying libraries.
On 28/06/2021 08:11, Samuel Sieb wrote:
On 2021-06-27 4:27 p.m., Stephen Morris wrote:
On 28/6/21 04:59, Samuel Sieb wrote:
On 2021-06-27 5:34 a.m., Stephen Morris wrote:
On 27/6/21 22:23, Ed Greshko wrote:
I have not had a situation where an update was performed and immediately followed by a need for another update. I do my updates with "dnf --refresh update".
The only thing I've seen is when packageKit is telling me there are updates but when dnf runs it says no updates are available. I attribute that to packageKit using different mirrors than dnf.
I hadn't realised Discover was using Packagekit. If it is using different mirrors to dnf and they indicate they have updates over and above what dnf has applied, does that mean dnf will catch up, or are they updates that dnf will never put on because it never sees them?
It's not that they use different mirrors. The mirror manager provides somewhat randomized mirrors when asked, so at different times, you can end up looking at different mirrors. And it's possible, if you check during the syncing time, that different mirrors have different available updates.
I thought dnf had a list of mirrors and the first time dnf was run it used the first mirror in the list, and kept using that mirror until it got a 404 situation on a package whereby it would go to the next mirror and if the package was obtained from that mirror, it would continue using that mirror for all updates until that produced a 404 situation, in which case it would move to the next mirror and so on. I've been finding it nothing unusual for Discover monitoring process to tell me there were updates available, even after using dnf to put on all updates it can see, and go and issue a dnf upgrade and have dnf tell me there was nothing to do.
The default repo configuration is to use the mirror manager. So dnf asks the mirror manager for a list of mirrors and it starts with the first one. I'm not sure if it completely abandons a certain mirror on the first 404, but it does go to another one for at least that file. I don't understand why Discover will tell you that there are more updates available. dnf does cache the current state for a while, so you could try adding "--refresh" to the dnf command to force it to check. But Packagekit uses the same configuration as dnf and I think it even uses the same underlying libraries.
As I mentioned somewhere, I still have both packageKit and dnfdragora installed.
There are times when the packageKit updates icon appears on my systray telling me a number of updates are available.
But, when I run "dnf --refresh upgrade" I am told "Nothing to do".
I just try again later in the day.
On 28/6/21 10:18, Ed Greshko wrote:
On 28/06/2021 08:11, Samuel Sieb wrote:
On 2021-06-27 4:27 p.m., Stephen Morris wrote:
On 28/6/21 04:59, Samuel Sieb wrote:
On 2021-06-27 5:34 a.m., Stephen Morris wrote:
On 27/6/21 22:23, Ed Greshko wrote:
I have not had a situation where an update was performed and immediately followed by a need for another update. I do my updates with "dnf --refresh update".
The only thing I've seen is when packageKit is telling me there are updates but when dnf runs it says no updates are available. I attribute that to packageKit using different mirrors than dnf.
I hadn't realised Discover was using Packagekit. If it is using different mirrors to dnf and they indicate they have updates over and above what dnf has applied, does that mean dnf will catch up, or are they updates that dnf will never put on because it never sees them?
It's not that they use different mirrors. The mirror manager provides somewhat randomized mirrors when asked, so at different times, you can end up looking at different mirrors. And it's possible, if you check during the syncing time, that different mirrors have different available updates.
I thought dnf had a list of mirrors and the first time dnf was run it used the first mirror in the list, and kept using that mirror until it got a 404 situation on a package whereby it would go to the next mirror and if the package was obtained from that mirror, it would continue using that mirror for all updates until that produced a 404 situation, in which case it would move to the next mirror and so on. I've been finding it nothing unusual for Discover monitoring process to tell me there were updates available, even after using dnf to put on all updates it can see, and go and issue a dnf upgrade and have dnf tell me there was nothing to do.
The default repo configuration is to use the mirror manager. So dnf asks the mirror manager for a list of mirrors and it starts with the first one. I'm not sure if it completely abandons a certain mirror on the first 404, but it does go to another one for at least that file. I don't understand why Discover will tell you that there are more updates available. dnf does cache the current state for a while, so you could try adding "--refresh" to the dnf command to force it to check. But Packagekit uses the same configuration as dnf and I think it even uses the same underlying libraries.
As I mentioned somewhere, I still have both packageKit and dnfdragora installed.
There are times when the packageKit updates icon appears on my systray telling me a number of updates are available.
But, when I run "dnf --refresh upgrade" I am told "Nothing to do".
I just try again later in the day.
I usually ignore the "nothing to do" situation as well and just issue the command again the next time I'm ready to put on updates again. It is a bit disconcerting though when Discover reports there being, in my case 638MB of Fedora System Updates as opposed to application updates, right from the first boot of F34 after a fresh install, and that calculation of how many updates are available never changes irrespective of how many updates are applied by dnf and how often. I've had F34 installed in the vm for probably around 6 months, and Discover has never stopped reporting 638MB of System Updates until I actually put them on.
regards, Steve
On 2021-06-27 8:09 p.m., Stephen Morris wrote:
I usually ignore the "nothing to do" situation as well and just issue the command again the next time I'm ready to put on updates again. It is a bit disconcerting though when Discover reports there being, in my case 638MB of Fedora System Updates as opposed to application updates, right from the first boot of F34 after a fresh install, and that calculation of how many updates are available never changes irrespective of how many updates are applied by dnf and how often. I've had F34 installed in the vm for probably around 6 months, and Discover has never stopped reporting 638MB of System Updates until I actually put them on.
That is very strange and doesn't make sense. If you're doing a workstation install, then yes, there will be a large amount of updates to do because it starts with a fixed image and doesn't use updates. But dnf should do them and it would be interesting to see what updates Discover thinks should be done.
On 28/6/21 10:18, Ed Greshko wrote: I usually ignore the "nothing to do" situation as well and just issue the command again the next time I'm ready to put on updates again. It is a bit disconcerting though when Discover reports there being, in my case 638MB of Fedora System Updates as opposed to application updates, right from the first boot of F34 after a fresh install, and that calculation of how many updates are available never changes irrespective of how many updates are applied by dnf and how often. I've had F34 installed in the vm for probably around 6 months, and Discover has never stopped reporting 638MB of System Updates until I actually put them on.
regards, Steve
what happens when you do in an terminal: sudo flatpak update and afterwards in your "software center" (discovery ?) a refresh/new search for updates
???
I've seen similar about "~600 MB platform update" which stuck somehow on F34/F33 (?) the above fixed it
On 29/6/21 07:37, old sixpack13 wrote:
On 28/6/21 10:18, Ed Greshko wrote: I usually ignore the "nothing to do" situation as well and just issue the command again the next time I'm ready to put on updates again. It is a bit disconcerting though when Discover reports there being, in my case 638MB of Fedora System Updates as opposed to application updates, right from the first boot of F34 after a fresh install, and that calculation of how many updates are available never changes irrespective of how many updates are applied by dnf and how often. I've had F34 installed in the vm for probably around 6 months, and Discover has never stopped reporting 638MB of System Updates until I actually put them on.
regards, Steve
what happens when you do in an terminal: sudo flatpak update and afterwards in your "software center" (discovery ?) a refresh/new search for updates
???
I've seen similar about "~600 MB platform update" which stuck somehow on F34/F33 (?) the above fixed it
I ran sudo flatpak update in the terminal and opened discover after the update finished and Discover said it had 129 updates to be applied. I check dnf and it said it had 124 package updates and 4 installs, which I applied. After rebooting Discover still said it had 34 updates to put on, which are below.
regards, Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 1/7/21 19:55, Stephen Morris wrote:
On 29/6/21 07:37, old sixpack13 wrote:
On 28/6/21 10:18, Ed Greshko wrote: I usually ignore the "nothing to do" situation as well and just issue the command again the next time I'm ready to put on updates again. It is a bit disconcerting though when Discover reports there being, in my case 638MB of Fedora System Updates as opposed to application updates, right from the first boot of F34 after a fresh install, and that calculation of how many updates are available never changes irrespective of how many updates are applied by dnf and how often. I've had F34 installed in the vm for probably around 6 months, and Discover has never stopped reporting 638MB of System Updates until I actually put them on.
regards, Steve
what happens when you do in an terminal: sudo flatpak update and afterwards in your "software center" (discovery ?) a refresh/new search for updates
???
I've seen similar about "~600 MB platform update" which stuck somehow on F34/F33 (?) the above fixed it
I ran sudo flatpak update in the terminal and opened discover after the update finished and Discover said it had 129 updates to be applied. I check dnf and it said it had 124 package updates and 4 installs, which I applied. After rebooting Discover still said it had 34 updates to put on, which are below.
Sorry, it looks like I forgot to add the screenshot, I'll try it again the next time I'm doing an update.
regards, Steve
regards, Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 5/7/21 21:51, Stephen Morris wrote:
On 1/7/21 19:55, Stephen Morris wrote:
On 29/6/21 07:37, old sixpack13 wrote:
On 28/6/21 10:18, Ed Greshko wrote: I usually ignore the "nothing to do" situation as well and just issue the command again the next time I'm ready to put on updates again. It is a bit disconcerting though when Discover reports there being, in my case 638MB of Fedora System Updates as opposed to application updates, right from the first boot of F34 after a fresh install, and that calculation of how many updates are available never changes irrespective of how many updates are applied by dnf and how often. I've had F34 installed in the vm for probably around 6 months, and Discover has never stopped reporting 638MB of System Updates until I actually put them on.
regards, Steve
what happens when you do in an terminal: sudo flatpak update and afterwards in your "software center" (discovery ?) a refresh/new search for updates
???
I've seen similar about "~600 MB platform update" which stuck somehow on F34/F33 (?) the above fixed it
I ran sudo flatpak update in the terminal and opened discover after the update finished and Discover said it had 129 updates to be applied. I check dnf and it said it had 124 package updates and 4 installs, which I applied. After rebooting Discover still said it had 34 updates to put on, which are below.
Sorry, it looks like I forgot to add the screenshot, I'll try it again the next time I'm doing an update.
I ran a sudo flatpak update again and ran Discover and it said there were 38 updates, and sudo dnf upgrade said there were 38 updates. When I put on all the updates with dnf and rebooted the vm, Discover said everything was up-to-date. I guess I'll just have to keep an eye on it and see what happens.
regards, Steve
regards, Steve
regards, Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
PackageKit uses libdnf. libdnf is the core library for dnf,PackageKit and rpm-ostree.
You should generally get the same results using either dnf or PackageKit.
-- Chris Murphy
在 2021-06-27星期日的 18:31 +1000，Stephen Morris写道：
there was 628 MB of F34 Platform updates to put on
It can be something from flatpak, which is not managed by dnf.
-
Chris Murphy -
Ed Greshko -
old sixpack13 -
Patrick O'Callaghan -
Qiyu Yan -
Samuel Sieb -
Stephen Morris