Re: Changes to GitLab runners configuration
On Tue, Mar 3, 2020 at 1:36 PM Bartłomiej Piotrowski wrote: > I've poked around yesterday and it's apparently not as trivial to run > buildah unprivileged in a container as it was the last time I tried. I > don't see better way than tagging jobs privileged at the moment. Thanks, tagging the job as privileged has fixed the errors that I was seeing: https://gitlab.gnome.org/GNOME/tracker-oci-images/-/merge_requests/15 Sam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Changes to GitLab runners configuration
On Mon, Mar 2, 2020 at 9:41 pm, Philip Chimento via desktop-devel-list wrote: Also, has anyone successfully gotten a CI job that uses lsan or asan to work in the unprivileged setup? (See my previous question about CAP_SYS_PTRACE.) Hm, looks like my glib-networking CI is broken due to this. I hadn't noticed yet ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Changes to GitLab runners configuration
On 28/02/2020 15.17, Michael Catanzaro wrote: > Please revert the runner changes until you have time to fix this. Our CI > has been basically unusable all week and that blocks flatpak pushes. All issues with user namespaces on gcc* runners should be resolved by now. It slipped my mind to set it persistently in sysctl.conf and runners were rebooted right after I left for vacation. On 03/03/2020 06.41, Philip Chimento via desktop-devel-list wrote: > I have little knowledge of this problem space so I don't even know whereto > start to debug this. Is this the same privileges problem as "bwrap: Creating > new namespace failed" described earlier in the thread, or is it something > different? (...) > Also, has anyone successfully gotten a CI job that uses lsan or asan to > work in the unprivileged setup? (See my previous question about > CAP_SYS_PTRACE.) I've poked around yesterday and it's apparently not as trivial to run buildah unprivileged in a container as it was the last time I tried. I don't see better way than tagging jobs privileged at the moment. I can apply a custom seccomp profile if that helps, but someone has to write it. Bart ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Changes to GitLab runners configuration
On Tue, Mar 3, 2020 at 6:42 AM Philip Chimento via desktop-devel-list wrote: > Does anyone have any advice on what to do with this? I followed Sam's helpful > hint about Tracker's CI images working to [1], copied the things that looked > like they might be relevant from there into my own gitlab-ci file [2], at > first got some errors that I knew basically how to deal with, but now I am > stuck at a bunch of error messages that look to me like gibberish but end > with "operation not permitted" [3]. I have little knowledge of this problem > space so I don't even know where to start to debug this. Is this the same > privileges problem as "bwrap: Creating new namespace failed" described > earlier in the thread, or is it something different? ... > [3] https://gitlab.gnome.org/ptomato/gjs/-/jobs/616717 It looks as though this problem is also affecting the tracker-oci-images build: Error during unshare(CLONE_NEWUSER): Operation not permitted From: https://gitlab.gnome.org/GNOME/tracker-oci-images/-/jobs/616919 And librsvg-oci-images build (which I copied for the Tracker repo :) Error during unshare(CLONE_NEWUSER): Invalid argument User namespaces are not enabled in /proc/sys/user/max_user_namespaces. From: https://gitlab.gnome.org/GNOME/librsvg-oci-images/-/jobs/614821 Sam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
