-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repositories that fail to connect block all rpm-ostree operations #1602
Comments
can you post the |
Yes: [csoriano@localhost ~]$ cat /etc/yum.repos.d/rcm-tools-fedora.repo |
This gets to a truly fundamental difference between rpm-ostree and yum/dnf (as well as apt and most other systems): rpm-ostree is at heart an image system, and intentionally carries forward only explicitly specified state. That explicit state is things like the In contrast, yum/apt etc default to treating all of your currently installed packages as state to preserve. (Both have a concept of "user installed" packages bolted on top though) For yum, implementing For us...when a |
I have a related issue, which might be relevant as well: I had the same problem and tried to deactivate that unavailable repo by setting
|
I'm building F33 FCOS now (finally). When I got booted up into the system I tried to layer a package and I get an error:
The
Alternatively the transaction fails if it can't find a package it needs because a repo isn't available. Of course my suggestion here gets a little more complicated when you have a repo setup like we have in Fedora with a |
The error itself I'm seeing is because DNS apparently isn't working inside my |
Short term you can just set I think fundamentally The problem particularly for rpm-ostree is that we have Your case is really the easy one, where you don't have any packages from that repo installed. |
Our machine don't have Internet access and don't have any layered package. |
@cheese Please provide the output of |
I found out I have some layered packages in the booted deploy. I ran |
Host system details
Expected vs actual behavior
I have some repositories installed by Dropbox and RHEL rhpkg that sometimes they fail to connect to their servers. These repositories block any other operation by rpm-ostree.
Ideally these repositories would be skipped if they fail to connect to their remote, as dnf does.
Steps to reproduce it
...
Would you like to work on the issue?
Not really, but thanks if you do :)
The text was updated successfully, but these errors were encountered: