On freshly installed Fedora via netinst, I have ended up with a system without any network connectivity due to missing WiFi firmware. Trying to remedy the situation, I have downloaded the required package on the USB stick and trying to install it, I have faced this errors: ~~~ $ sudo dnf install /run/media/vondruch/8715-3993/iwlwifi-mvm-firmware-20230625-151.fc39.noarch.rpm Věříme, že jste od správce místního systému obdrželi obvyklé školení. Obvykle se jedná o tyto tři věci: 1. Respektujte soukromí druhých. 2. Přemýšlejte, než začnete psát. 3. S velkými právy přichází velká zodpovědnost. Z bezpečnostních důvodů zadávané heslo nebude zobrazeno. [sudo] heslo pro vondruch: Updating and loading repositories: Fedora rawhide openh264 (From Cisco) - x86_64 ???% | 0.0 B/s | 0.0 B | 00m00s >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink? >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink? >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink? >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink? >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink? >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink? >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink? >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink? >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink? >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink? >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink? >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink? >>> Librepo error: Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject Fedora - Rawhide - Developmental packages for the next Fedora release ???% | 0.0 B/s | 0.0 B | 00m00s >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_ >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_ >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_ >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_ >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_ >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_ >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_ >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_ >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_ >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_ >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_ >>> Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] - https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_ >>> Librepo error: Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org]Failed to download metadata (metalink: "https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64") for repository "rawhide" ~~~ This is annoying, because it does not even attempt to do what was requested, while it has all the required information. I had to disable all the repos to move forward, but I don't think this should be necessary: ~~~ $ sudo dnf install --disablerepo=* /run/media/vondruch/8715-3993/iwlwifi-mvm-firmware-20230625-151.fc39.noarch.rpm Updating and loading repositories: Repositories loaded. Package Arch Version Repository Size Installing: iwlwifi-mvm-firmware noarch 20230625-151.fc39 @commandline 41.9 MiB Transaction Summary: Installing: 1 packages Total size of inbound packages is 40 MiB. Need to download 0 B. After this operation 42 MiB will be used (install 42 MiB, remove 0 B). Is this ok [y/N]: ~~~ Reproducible: Always Steps to Reproduce: 1. Fresh system without any network connection 2. Install package with all dependencies from command line 3. Actual Results: Package is not even attempted to be installed without metadata Expected Results: While metadata are not available, the package installation should be tried
Later, I have realized that on my older system, I used to have `skip_if_unavailable=True` in my dnf.conf, which would probably help with this. Nevertheless, I am not sure why this is actually not enabled by default. IMHO, missing repository might end up in not available package or broken dependencies, but I can't see why it should be fatal error.
Hi, in general, dnf must load repository metadata even when installing a local package in case the package has dependencies that are available in the repositories. And dnf fails if it fails to load the metadata of a repository with `skip_if_unavailable=false`. The default is false, because it's safer from a security standpoint. The only change in dnf5 is that we no longer ship configuration override to Fedora, but there is a plan to add drop-in configuration directory for other packages to provide the override, if the distribution desires it. There is still a discussion around this, see bug 2216205. I'm closing this as a duplicate. *** This bug has been marked as a duplicate of bug 2216205 ***
(In reply to Pavla Kratochvilova from comment #2) > Hi, in general, dnf must load repository metadata even when installing a > local package in case the package has dependencies that are available in the > repositories. With all due respect, I don't think this is sensitive behavior. I have asked DNF to explicitly install "/run/media/vondruch/8715-3993/iwlwifi-mvm-firmware-20230625-151.fc39.noarch.rpm". But instead DNF looking into that package and continuing from there, DNF ignores my request and cares about some metadata. That is not right and that is not user friendly. If there are some required dependencies and DNF cannot get them, DNF knows what to do. Any amount of additional repositories/metadata cannot ensure that the dependencies will be provided. More often then not, if I want to install something from command line, I am ready and I have to also install all the necessary dependencies specifying them on command line. > And dnf fails if it fails to load the metadata of a repository > with `skip_if_unavailable=false`. > > The default is false, because it's safer from a security standpoint. If you want to argue about security, then I am afraid that downloading some data from the internet instead of using the data provided on command line is hardly more secure.
> With all due respect, I don't think this is sensitive behavior. I have asked DNF to explicitly install "/run/media/vondruch/8715-3993/iwlwifi-mvm-firmware-20230625-151.fc39.noarch.rpm". But instead DNF looking into that package and continuing from there, DNF ignores my request and cares about some metadata. That is not right and that is not user friendly. If there are some required dependencies and DNF cannot get them, DNF knows what to do. If dnf first considered only the command line packages, and then loaded the metadata only if it failed to resolve dependencies, it would mean unnecessary duplicit resolvement, more complicated behavior and it couldn't take reverse dependencies into account. > Any amount of additional repositories/metadata cannot ensure that the dependencies will be provided. More often then not, if I want to install something from command line, I am ready and I have to also install all the necessary dependencies specifying them on command line. > If you want to argue about security, then I am afraid that downloading some data from the internet instead of using the data provided on command line is hardly more secure. I understand this is your use case. If you want to have complete control over the operation and don't want to care about repositories at all, there is also an option to use rpm in this case.
(In reply to Pavla Kratochvilova from comment #4) > > With all due respect, I don't think this is sensitive behavior. I have asked DNF to explicitly install "/run/media/vondruch/8715-3993/iwlwifi-mvm-firmware-20230625-151.fc39.noarch.rpm". But instead DNF looking into that package and continuing from there, DNF ignores my request and cares about some metadata. That is not right and that is not user friendly. If there are some required dependencies and DNF cannot get them, DNF knows what to do. > > If dnf first considered only the command line packages, and then loaded the > metadata only if it failed to resolve dependencies, it would mean > unnecessary duplicit resolvement, It would not be such a big deal, would it be? I guess that resolving dependencies of one or a few packages specified on the command line can't hurt. > more complicated behavior and it couldn't > take reverse dependencies into account. > > > Any amount of additional repositories/metadata cannot ensure that the dependencies will be provided. More often then not, if I want to install something from command line, I am ready and I have to also install all the necessary dependencies specifying them on command line. > > If you want to argue about security, then I am afraid that downloading some data from the internet instead of using the data provided on command line is hardly more secure. > > I understand this is your use case. If you want to have complete control > over the operation and don't want to care about repositories at all, there > is also an option to use rpm in this case. Please consider my situation. This was not about what I want. I wanted to have functional system but it was not. I tried to recover it but DNF was not helpful at all. Instead you send me towards RPM, which in long run cannot be beneficial, because then DNF does not know about such package.
DNF knows which packages are local. How about if the list of local packages is not empty and there are no other package specs that might match with any remote packages, throw the local packages into a transaction prior loading repos. If it succeedes, we have what we wanted. If it fails, load repos and retry. The only disadvantage is that weak deps from remote repos wouldn't get installed. It's definitely worth trying. We don't want anyone using RPM directly, maybe with the exception of fixing an utterly broken installation.