Retrieving: libfido2-udev-1.14.0-50.1.noarch.rpm .................................................................................................................................................................................................................[not found]
File './noarch/libfido2-udev-1.14.0-50.1.noarch.rpm' not found on medium 'https://download.opensuse.org/repositories/security/openSUSE_Tumbleweed/'
Abort, retry, ignore? [a/r/i/...? shows all options] (a): r
Retrieving: libfido2-udev-1.14.0-50.1.noarch.rpm .................................................................................................................................................................................................................[not found]
File './noarch/libfido2-udev-1.14.0-50.1.noarch.rpm' not found on medium 'https://download.opensuse.org/repositories/security/openSUSE_Tumbleweed/'
for two days. Any ideas of how to solve this with such limited information? I don’t want to break the package dependency if possible.
Please, please, always include the line with the prompt and the command used, ALL output and the new prompt line. Only so can people see what exactly you did (“I’m trying to update” is no exact description) and got. No one here can read minds. No one wants to read only your conclusions. They want to see what you saw and draw their own conclusions.
@hcvv, sudo zypper dup --no-allow-downgrade && flatpak update -y && flatpak uninstall --unused && sudo snap refresh && systemctl reboot although it never got far enough to trigger anything except zypper dup.
I can’t easily provide the output, because even GitLab Snippets wouldn’t provide enough space to hold the output — https://pastebin.com/ reports:
You have exceeded the maximum size of 512 kilobytes per Paste.
…whereas this Discourse instance just returns:
422 error
@malcolmlewis, I don’t quite understand. This is a dependency of something — I haven’t added a repository deliberately and then deliberately installed that package. Isn’t that a TW repository?
Those are the only “official” and technically supported repositories for Tumbleweed, with the possible exception of Packman, or the NVIDIA Repos.
If you’ve enabled any other repositories, then it’s expected that you know what you’re doing, and are able to fix issues if they occur. People might help, out of the kindness of their hearts, or their own personal curiosity and enjoyment of solving problems, but they’re under no obligation.
@rokejulianlockhart as pointed out by @sfalken you have the Development repository “security” added, they are NOT the standard Tumbleweed repositories…
@rokejulianlockhart it’s very clear in your original post what the issues is… again, adding development repos understand what you are doing…
You installed at some point packages from the security repo (as per the output showing this). Likely it doesn’t exist there any more (or fails to build etc).
It exists in the standard Tumbleweed repos, so switch to that, the no allow downgrade is probably the issue, this is strange option to use as there are times when packages do get rolled back and downgraded, or the version number is lower (which is likely in this case). If you add verbosity -vvv also don’t run all the other things, do that as a separate command…
This problem occures when the repo is added inappropriate without the “auto-refresh” flag. So that means, enable auto refresh for the security repo and do a zypper ref.
Zypper tries to install libfido2-udev-1.14.0-50.1 which is no longer available at the security repo, as the new package version is already libfido2-udev-1.14.0-50.4
(because you don’t have auto-refresh enabled zypper doesn’t know about the new version at the repo…)
But better follow Malcolms advice to completely remove the security repo and install the package from official openSUSE repos…
And as pointed out by Malcolm, the option --no-allow-downgrade is asking for trouble when doing a dup with several thousands of packages…
@malcolmlewis, I’ll stop using --no-allow-downgrade if that’s the safer option. I wasn’t aware that allowing a package to downgrade might ever be the safer option, much less that it was a normal thing, and that I shouldn’t attempt to prevent it without a specific reason to be wary of a specific downgrade.
Having used Windows and AOSP for much of my life, MSIX and APK (respectively) package downgrades are literally prevented by the OS. I hope that makes this make sense.
Thanks, @hui. Do you know how to enable this flag? Additionally, do you recommend that I enable it on all repositories I have added and add in the future, or is there a normal reason to have it disabled for certain repositories? If you’re unwilling to explain, I would be glad to be directed to where I can understand this feature.
Regardless, I try to add packages using the most automated process possible (opi, or having the package automatically add it itself upon installation, for instance) so obviously someone has misconfigured it in their installer or installation instructions, right? If so, I’ll try to ascertain where to report it to.
@rokejulianlockhart DON’T use opi for Tumbleweed, as a Tumbleweed user see the recent discussion on the Factory Mailing List… Including use of Packman…
That is not the most automated way… only use the standard repositories, oss, non-oss and update, there should be no need for anything more.
@Sauerland, unfortunately, because I’ve now modified the list, it has changed. However, the script output has saved the original version, albeit in a mostly unparseable manner:
Luckily, the repository URIs are visible unobstructed, so the important information remains visible. Apologies for the format. By the way, I had used zypper lr -u instead.