action #99126
closedos-autoinst CI GHA fails with weird C++ error?
Description
Observation¶
E.g. in https://github.com/os-autoinst/os-autoinst/pull/1780/checks?check_run_id=3689856996 from https://github.com/os-autoinst/os-autoinst/pull/1780 but also https://github.com/os-autoinst/os-autoinst/pull/1781/checks?check_run_id=3690403474 from https://github.com/os-autoinst/os-autoinst/pull/1781
terminate called after throwing an instance of 'std::system_error'
what(): Operation not permitted
terminate called after throwing an instance of 'std::system_error'
what(): Operation not permitted
./tools/install-new-deps.sh: line 21: 14 Aborted sudo zypper --no-refresh install -y -C "${DEPS[@]}"
Problem¶
Trying podman run --pull=always --rm -it --entrypoint '' registry.opensuse.org/devel/openqa/containers/os-autoinst_dev /bin/bash -c /bin/true locally works fine. So I doubt the current container image is broken.
Updated by coolo over 2 years ago
Let me guess - Tumbleweed containers? https://s.kulow.org/glibc
Updated by okurz over 2 years ago
any ideas for what to do as workaround? Move the container to Leap 15.2?
Locally I had no problem to use the os-autoinst_dev container, build os-autoinst and run it with podman run --rm -it --entrypoint registry.opensuse.org/devel/openqa/containers/os-autoinst_dev /bin/bash and within there
git clone https://github.com/os-autoinst/os-autoinst.git
zypper in os-autoinst-devel
cd os-autoinst/
make
prove -I.
./isotovideo casedir=t/data/tests qemu_no_kvm=1
Updated by mkittler over 2 years ago
I suspect the glibc update on TW as well. It might work locally but not in the CI because TW and possibly even Leap have already been upgraded to be able to host a TW container but the CI system hasn't. Besides, I might have read on the Factory mailing list thread that podman is not affected (which you apparently using).
I guess we could either somehow stick to the previous snapshot or move the container to Leap 15.2.
Updated by mkittler over 2 years ago
- Status changed from New to In Progress
PR for switching to Leap 15.3: https://github.com/os-autoinst/os-autoinst/pull/1782
Not sure whether we can use podman in the CI context (which could be another workaround).
Updated by livdywan over 2 years ago
We discussed this in the weekly. Let's move to Leap. And we probably should stay on Leap to avoid going back and forth, considering this happened before.
Updated by livdywan over 2 years ago
- Related to action #98769: Unresolvables in devel:openQA Leap 15.3 size:S added
Updated by mkittler over 2 years ago
I've created a 2nd PR to actually use the Leap 15.3-based container (which needed to use a different OBS repository): https://github.com/os-autoinst/os-autoinst/pull/1784
I also had to fix one of the linked Python packages so the dependencies are correct when building for Leap 15.3: https://github.com/os-autoinst/os-autoinst/pull/1784#issuecomment-926619839
Not sure whether that's the best way to do it but at lest it seems to work.
Updated by mkittler over 2 years ago
- Status changed from In Progress to Resolved
The CI works again (e.g. https://github.com/os-autoinst/os-autoinst/pull/1781) using a Leap 15.3 based image. I've also created https://github.com/os-autoinst/os-autoinst/pull/1785 but don't consider merging it part of this urgent ticket (if we want to merge it at all).
Updated by okurz over 2 years ago
cdywan wrote:
And we probably should stay on Leap to avoid going back and forth, considering this happened before.
"Staying on Leap" is also not static because this means we need to switch to newer Leap versions from time to time.
Updated by livdywan over 2 years ago
okurz wrote:
cdywan wrote:
And we probably should stay on Leap to avoid going back and forth, considering this happened before.
"Staying on Leap" is also not static because this means we need to switch to newer Leap versions from time to time.
Thank you for stating the obvious :-D The point is, Leap has releases and we can upgrade in our own time without it breaking out of nowhere.