-
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
Rebasing Silverblue from Rawhide to 38 or 37 is consistently failing #420
Comments
Hmm. This also fails if I change the rebase target to 37: |
The first failure of this kind was at 2023-02-15 18:26, which suggests the new rpm-ostree in Rawhide can't be the cause as it was built later than that. |
It's unlikely this is related to rpm-ostree; the failure is at the ostree layer. It should be reproducible with just
The same problem for me doesn't reproduce in a If I was a betting man, I'd bet on libcurl. But I have to context switch to other things at the moment. |
(Of note though: with the container-native flow, we no longer use libcurl for OS updates; instead it's skopeo and hence the golang http stack which does HTTP) |
Can you pick me a horse for the 4:55? :P There was indeed a new curl in Rawhide (only) right around when this started breaking: Wed Feb 15 13:34:29 2023 curl-7.88.0-1.fc39 tagged into f39 by bodhi [still active] (the few hours between would be accounted for by some backup in openQA and the fact this test takes quite a long time - it has to wait through the whole ostree/ostree-installer build process). There's another build today with a change listed as "- http2: set drain on stream end", so I'll see if that fixes it, and if not, I'll maybe file a bug there. |
It looks like it does 🎉 |
Describe the bug
Running
rpm-ostree rebase fedora/38/x86_64/silverblue
in an openQA test that tests rebasing is consistently failing with errors indicating some kind of corrupted object, or something along those lines.To Reproduce
Please describe the steps needed to reproduce the bug:
rpm-ostree rebase fedora/38/x86_64/silverblue
Expected behavior
It fails. The errors vary but are all of a kind that suggest the data is somehow corrupted, e.g. "Invalid compressed data", "Unexpected EOF", "Corrupted file object"...
Screenshots
CC @nirik since this may be a releng problem.
The text was updated successfully, but these errors were encountered: