-
Notifications
You must be signed in to change notification settings - Fork 3
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
Any operation on basic system (except for rebase) blocked by: error: Checkout: [package]: Is a directory #342
Comments
When I tried to remove all layered packages with |
Edit: I mis-read. I see the error in the last message. |
Might be an rpm-ostree bug or a bug in the nss-tools package. |
Thanks. I found out about #322 only after filing this one. I'll give a try to workarounds mentioned there and either close this or (hopefully) add more diagnostic data (well to that end, hitting this on every active rpm-ostree operation and thus rpm-ostree ending all of them with non-zero code isn't exactly helfpul either) |
@travier so I managed to update to Also,
EDIT: Ouch, this one hurts. :/ VMs are important part of my daily workflow, let's see how will fare usability of containerized boxes compared to plain libvirt to me...
|
I have all of that installed on F36 right now so this might be an F37 only issue. |
Can you try with the latest rpm-ostree from https://koji.fedoraproject.org/koji/search?terms=rpm-ostree-2022.13-1.fc37&type=build&match=glob ? |
If this does not fix things, can you file an rpm-ostree bug? Thanks! |
I tried in a fresh rawhide VM rebased to 37 and couldn't reproduce, then I realized I used default settings (btrfs) while system where the issue exhibits is on xfs, so I'm installing a new VM with xfs. Anyway I start suspecting some sort of errors somewhere in storage stack. (just wondering if there is some easy way to save the mutations descriptions + /etc custom content somewhere, reinstall the immutable base and reapply back my saved stuff...) |
So the primary issue was indeed fs (xfs) corruption. Getting FS to clean state including manual delete of one duplicated entry (had to flip coin which one...) transforms error of
It seems that for these cases, it'd be great if ostree could redeploy immutable parts of
Trying workaround with rebase, cleanup and rebase back... |
In rebased system then after
Rebasing back to 37 |
Here we go:
So bug is indeed Before I had idea of |
Thanks for the investigation. Can you file an rpm-ostree bug upstream? |
I'm thinking about several RFEs. Could you give me feedback on what of it is actually feasible within
|
|
Well it's inspired by my need to do manually some action beyond what
I'm pretty sure I wouldn't be able to pull it off, I'm glad I actually managed to diagnose the primary issue here. :) The idea is inspired e.g. by oVirt who do backups of their critical ovirt-engine machines this way - they create tarballs with critical parts of |
Given the level of investigation you did here, I think you should give it a try! :) |
|
This issue tracker is intended only for Silverblue specific issues. We would like to ask you to try to reproduce the issue on a relevant Fedora Workstation release. If you will be able to reproduce there, then please report it in Red Hat Bugzilla (see How to file a bug) or in upstream (preferred for GNOME projects) and not in this issue tracker.
Describe the bug
Any minor update or adjustment in layered packages is blocked for me for last weeks both in silverblue 36 and silverblue 37 with error below
To Reproduce
Please describe the steps needed to reproduce the bug:
ipa-client
in layered packages (which presumably pulls nss* stuff)Expected behavior
update passes
Screenshots
If applicable, add screenshots to help explain your problem.
OS version:
Additional context
This effectively pins system to a single given version. Do you want a minor update of 36? Rebase to 37, delete current deployment of 36, rebase to current deployment of 36. Or vice versa.
The text was updated successfully, but these errors were encountered: