<baude>
walters: on your comment, so ... pop into a cosa shell, then execute the command?
<walters>
Yep
<walters>
May also try “perf trace”, or in general any tool or technique one would use to debug a stuck process
<walters>
Could also try bumping the log level for kola for example
<baude>
walters: i attached the strace fwiw
<baude>
i also noticed runvm-console.txt had two Synchronous Exceptions in it. That normal ?
<baude>
and fwiw, seems like on more generic aarch64, this all works fine. so this is maybe a apple silicon qemu thing ?
<dustymabe>
baude: maybe :)
<baude>
i assume you folks use something like an aws aarch64 node for this
<dustymabe>
correct
<dustymabe>
bare metal node
<dustymabe>
in AWS
<baude>
i am also willing to set up a tmate if anyone wants to take a peek
<dustymabe>
assuming there is a bug I doubt the issue is actually in COSA itself.. more likely that it's in qemu, which means our screenshare would probably be of limited value without someone with qemu expertise online
<dustymabe>
baude: if you run libguestfs-test-tool inside the COSA container it might give some clues
<baude>
i suspect we might need to add something to the qemu command actually (maybe?)
<baude>
anyone know offhand where that command is assembled in case I want to fool with it ?
<baude>
actually dustymabe ... i see that the qemu in the cosa image is quite old ... is there a way I could use f38 inside the image?
<baude>
and i know quite a bit of stuff went into qemu for apple silicon right around the 7.0x time period which is the version being used ... but in f38, it is 7.2
<walters>
sure, could rebuild the container with f38 userspace, or try just pulling in newer qemu
<dustymabe>
what am I supposed to focus on in that paste?
<jlebon>
baude: what error related to the alias are you seeing? the recent tweak is transparent to the rest of cosa, so latest cosa should work fine with the old alias
<baude>
i was seeing an issue with incorrect ownership of sudo as well as ld errors
<spresti[m]>
dustymabe: Just saw it, was offline for longer then expected after lunch
<dustymabe>
np
<spresti[m]>
For refrence is that extra step always true every fedora bump?
<dustymabe>
spresti[m]: no, just this one :)
<dustymabe>
this is the major version rebase
<dustymabe>
so it will be 6 months before we have to change the number from 38 to 39
<spresti[m]>
So when we have a major bump I.E f38 to f39 in 6 months the fcos release needs to cherrypick for stable only. (as it naturally flows into testing?)
<spresti[m]>
s/cherrypick/cherry-pick/
<dustymabe>
no.. this is one thing that never gets synced so for every branch we cherry-pick
<dustymabe>
but it doesn't happen that often so it's not too painful (or at least it hasn't been)
bgilbert has joined #fedora-coreos
<spresti[m]>
I went ahead and cherry-picked the manifest change into the stable rebase pr and it's diff check is failing with the warning of an unexpected change?
<bgilbert>
dustymabe: re bootupd RAID: oof
<bgilbert>
spresti[m]: unexpected change is expected. that CI test isn't blocking; it's just trying to flag anything in the diff that needs manual review
<spresti[m]>
Ah ok sweet thank you :)
<bgilbert>
usually we add a comment explaining why any flagged changes are okay
<bgilbert>
dustymabe: the "Merge without waiting" checkbox is for repo admins only
<bgilbert>
dustymabe: if we want to make the promotion diff check overridable by non-admins, we'd need to move it into a separate CI job from GH's perspective
<dustymabe>
+1 - I think it's fine like it is
<dustymabe>
we don't often have a need for the exceptions