From: ap4y <ap4y@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: New package: crun-0.15
Date: Wed, 30 Sep 2020 06:36:22 +0200 [thread overview]
Message-ID: <20200930043622.pxQ7oPwjFd4AZItOZkCkFWvqZhEr3Oab5AYxnsIEb9Y@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-25140@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
New comment by ap4y on void-packages repository
https://github.com/void-linux/void-packages/pull/25140#issuecomment-701151296
Comment:
Thanks a lot for the review @CameronNemo, really appreciate it. I wasn't aware of the issues with virtual packages and couldn't find related information in the manual or issues. I'm curious where a can read more about those before going with my original idea and rev bumping `podman` and `runc`.
I also had a chance to test a pure cgroupv2 mode (i.e. unified) and had some issues with rootless mode in `runc`, `crun` runs seems to be getting the same error but it's ignored. Haven't fully investigated this one.
```
ap4y » podman --runtime runc run --rm -ti alpine sh
Error: container_linux.go:370: starting container process caused: process_linux.go:326: applying cgroup configuration for process caused: mkdir /sys/fs/cgroup/libpod_parent: permission denied: OCI runtime permission denied error
ap4y » podman --runtime crun --log-level info run --rm -ti alpine sh
INFO[0000] podman filtering at log level info
WARN[0000] Error initializing configured OCI runtime kata: no valid executable found for OCI runtime kata: invalid argument
INFO[0000] Setting parallel job count to 37
WARN[0000] Failed to add conmon to cgroupfs sandbox cgroup: error creating cgroup path /libpod_parent/conmon: write /sys/fs/cgroup/cgroup.subtree_control: open /sys/fs/cgroup/cgroup.subtree_control: permission denied
INFO[0000] Got Conmon PID as 6067
/ #
ap4y » podman info
host:
arch: amd64
buildahVersion: 1.16.1
cgroupVersion: v2
```
Since `crun` looks like a bit more stable option for cgroupv2 I think using `ignorepkg` might be a bit clunky solution.
next prev parent reply other threads:[~2020-09-30 4:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-28 1:59 [PR PATCH] " ap4y
2020-09-28 2:58 ` [PR PATCH] [Updated] " ap4y
2020-09-28 3:00 ` ap4y
2020-09-28 3:00 ` ericonr
2020-09-28 3:17 ` ap4y
2020-09-28 3:20 ` ap4y
2020-09-28 3:48 ` [PR PATCH] [Updated] " ap4y
2020-09-28 4:36 ` CameronNemo
2020-09-28 4:42 ` CameronNemo
2020-09-28 4:43 ` CameronNemo
2020-09-28 8:00 ` ap4y
2020-09-29 20:30 ` [PR REVIEW] " CameronNemo
2020-09-29 20:32 ` CameronNemo
2020-09-29 20:32 ` CameronNemo
2020-09-30 4:36 ` ap4y [this message]
2020-09-30 5:16 ` CameronNemo
2020-09-30 7:31 ` ap4y
2020-09-30 7:31 ` [PR PATCH] [Closed]: " ap4y
2020-09-30 16:22 ` CameronNemo
2020-09-30 16:24 ` CameronNemo
2020-09-30 21:49 ` ap4y
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200930043622.pxQ7oPwjFd4AZItOZkCkFWvqZhEr3Oab5AYxnsIEb9Y@z \
--to=ap4y@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).