A question: will the non-netinstaller ISO work? Does it include this file?
I understand your frustration but you have to understand this was purely a coincidence that you ran into this issue within the past few hours.
This is extremely fresh
Your point stands though, This shouldnât stall the entire installation.
1 Like
I used full ISO here and it installed fine⌠just the first manual update afterwards fails.
You can ignore the failing rpm package, for the time being, with the --exclude command I shared above.
1 Like
There is a workaround for this issue, you can just disable that particular repo and the update/install will work fine. I have a feeling this will be rectified in due course at which time we can all re-enable the repo or add another one that will act as itâs mirror. And there are mirrors, but they look like they are all pointing to the same cluster⌠lol. Definitely speaks volumes to having a fallback server for cases like this, I guess
You can run this in your terminal to bypass the issue:
sudo dnf-3 config-manager --set-disabled fedora-cisco-openh264
1 Like
Thanks, I have worked around it already by installing Fedora without any Desktop environment and installing the package manually. Itâs just funny because I was going to show people Fedora this week at work. Weâre using Debian since forever, which I always found extremely stable, with official network mirrors even in my own city. But Iâm challenging my own views and also wanted to challenge other people at work on why we still use Debian (the only drawback is that sometimes Debian uses old versions which requires more administrative work). If the full installer ISO doesnât hold this package, I guess the problem will still show upâŚ
Windows 11 is a nightmare, this is the time linux distros should focus on getting stability and usability for the desktop market⌠
1 Like
to be fair, I have installed Fedora many times in the past and this is the first time it has ever caused any issues. Iâve even had more issues with Ubuntu than Fedora historically, which people donât believe when I tell them usually, for itâs reputation for stability and supports anything out of the box.
Just goes to show that everyone has their own story to tell about this stuff I guess
3 Likes
I have installed fedora about half a year ago and had an issue where flatpaks would just crash for no reason(didnât look much into it just jumped back to opensuse, I know not very wise of me), I have installed it again today and this happened hahah.
1 Like
somewhat semi-related⌠I was about to install proprietary/non-fee âRPM Fusionâ drivers and the NVidia driver⌠Is there a common/proper way to install all commonly used codecs/drivers/software that e.g. typically also come along by default with Ubuntu and the likes? and⌠will these h264 codecs/plugins and browser then also get (or need to be) updated to work with these changes?
It starts to feel a bit cumbersome to do this all manually ⌠and I do get the whole concept of licenses and the desire to start with open-source as a base, but itâs kind of hard nowadays to get a modern PC working properly out of the box with mere open-source driversâŚ
Is there some tool/project/script that adds all the non-free/proprietary stuff to a fresh Fedora install?
(gotta hand it to Windows⌠itâs runs really well on a lottttt of systems⌠and to be fair⌠ever since 10, I have been using it (together with WSL or linux VMs) pretty reliably⌠)
I had this problem while installing chromium so unfortunately couldnât disable the repo.
As @doineann said the trailing slash seems to be the issue so my workaround was manually downloading the package and then installing via the rpm:
wget -P /tmp http://ciscobinary.openh264.org/openh264-2.4.1-2.fc41.x86_64.rpm
sudo dnf install /tmp/openh264-2.4.1-2.fc41.x86_64.rpm
Note the lack of a trailing slash in the url.
After that the install worked fine, this was for 41 (Container Image).
3 Likes
Just wondering⌠will this work well for later updates with the dnf package manager, when it gets fixed and the urls work again? or will a manual install mean that the package becomes âdetachedâ from dnf updates?
(I am kind new to Fedora and dnf⌠used it way back in the days of rpm and redhats in 90âs/00âs⌠so itâs all a bit new and different than the âusualâ Ubuntus for me)
Interesting that this worked for you. When I tried to this, it threw me the same error in the original post. I may have to check my syntax and the exact file that I grabbed with wget. Thanks for this suggestion!
Thatâs actually a good question. It could work either way. Does it search the repos for all existing packages and checks for updates, or does dnf record a packageâs origin at the time of install and check against itâs source? In the case of some random rpm, it wouldnât support updates, would it?
1 Like
I am no dnf/Fedora expert, but I can imagine that a manually installed rpm package (even when it is exactly the correct one, might still be âmarkedâ as a manual install and requires some special dnf command to be âmarked for updatesâ again.
Had problems like this with package managers in the past after manual updatesâŚ
Maybe there is someone here with more more knowledge who can elaborate on this?
I see that your original post is after âmozilla-openh264â which wasnât one of my dependancies but also seems to be failing. Try this:
wget -P /tmp http://ciscobinary.openh264.org/openh264-2.4.1-2.fc41.x86_64.rpm http://ciscobinary.openh264.org/mozilla-openh264-2.4.1-2.fc41.x86_64.rpm
dnf install /tmp/openh264-2.4.1-2.fc41.x86_64.rpm /tmp/mozilla-openh264-2.4.1-2.fc41.x86_64.rpm
and then try running your update.
@doineann I was thinking just as a temporary fix, however Iâm installing this stuff in containers Iâm probably going to remove quite soon so itâs a bit different.
dnf info openh264 lists the repository as @commandline so I imagine dnf would have some trouble finding updates but I could be wrong.
Looks like it is currently being fixed link
2 Likes
Thanks! exactly what I wondered/thought already⌠New things learned today!
So do I guess the correct and âproperâ way to do a manual install like @matt888 mentions, is to also set these âmarkedâ states correctly before and afterwards, and in the same way as originally done by the maintainers? I would already be confused as to what commands to use in this case.
as my intention is not to work temporarily with Fedora in a container, but have it as a main daily driver on my PC, I would prefer to do âfixesâ in a more âfuture proofâ way 
Hi, I am from Brazil and I faced the same problem, but this suggestion worked very well for me, thanks.
1 Like
The issue was on the server side and itâs fixed now.
No need for workarounds anymoreâŚ
6 Likes
The repo, @commandline in this case, is info only and never used to find a newer rpm.
Ok interesting, so dnf will search for a package against any loaded repo and will store where the package was installed from for info only?
In terms of the above discussion this implies that as long as dnf has a correct package name then it will be able to search against loaded repos even if it was installed from a local rpm file?
I just did a little test by installing an old package and this looks to be the case:
wget -P /tmp https://fedora.mirror.digitalpacific.com.au/linux/releases/41/Everything/x86_64/os/Packages/o/openjpeg-2.5.2-4.fc41.x86_64.rpm
dnf install /tmp/openjpeg-2.5.2-4.fc41.x86_64.rpm
dnf info openjpeg # lists the newer package as available
dnf update # updates to the newer package
1 Like
Yes
Yes
You see this with the fedora-updates repos vs. the fedora repos for example.
1 Like