Project

General

Profile

action #99126

os-autoinst CI GHA fails with weird C++ error?

Added by okurz 9 months ago. Updated 9 months ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
Organisational
Target version:
Start date:
2021-09-23
Due date:
% Done:

0%

Estimated time:
Difficulty:

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.


Related issues

Related to openQA Project - action #98769: Unresolvables in devel:openQA Leap 15.3 size:SResolved2021-09-16

History

#1 Updated by coolo 9 months ago

Let me guess - Tumbleweed containers? https://s.kulow.org/glibc

#2 Updated by okurz 9 months ago

yeah, thx. Looks like exactly that

#3 Updated by okurz 9 months 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

#4 Updated by mkittler 9 months 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.

#5 Updated by mkittler 9 months ago

  • Assignee set to mkittler

#6 Updated by mkittler 9 months 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).

#7 Updated by cdywan 9 months 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.

#8 Updated by cdywan 9 months ago

  • Related to action #98769: Unresolvables in devel:openQA Leap 15.3 size:S added

#9 Updated by mkittler 9 months 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.

#10 Updated by mkittler 9 months 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).

#11 Updated by okurz 9 months 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.

#12 Updated by cdywan 9 months 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.

Also available in: Atom PDF