Kai Lüke

How about adding an `alias` entry for each tool to run the latest Docker container?

There is an existing issue for this which also covers bpftrace: https://github.com/kinvolk/Flatcar/issues/198

This here is a working alias for execsnoop: ``` alias iovisor-execsnoop="docker run --rm -it -v /lib/modules:/lib/modules -v /sys/kernel/debug:/sys/kernel/debug -v /sys/fs/cgroup:/sys/fs/cgroup -v /sys/fs/bpf:/sys/fs/bpf --privileged --net host --pid host quay.io/iovisor/bcc /usr/share/bcc/tools/execsnoop" ```...

Aliases for some bcc tools were added in https://github.com/flatcar-linux/coreos-overlay/pull/1278 - for sysstat it's either waiting for a proper image or using the alpine workaround I pasted above

As first step we can try to generate the same vagrant images as we do for amd64 (definitions in `scripts/build_library/vm_image_util.sh` and `coreos-overlay/coreos-base/oem-vagrant/oem-vagrant-0.0.3.ebuild` where currently only `amd64` is set in `KEYWORDS`)....

I hit this again with the kvm group, this is a regression, maybe we can work around it by creating the group from ignition using the same ID but it...

Adding the group in Ignition doesn't work because it already exists… I think we should prioritize this if there is no easy workaround. Original error `[failed] creating or modifying user...

As @tormath1 found out, `useradd` looks for the group manually in `/etc/groups` instead of only looking up the known groups. I think in our case this even makes sense because...

Related, the CI report could be improved by using https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/ Edit: With https://github.com/flatcar-linux/Flatcar/issues/794 done we could also use the image diff logic to report any possibly unwanted image differences.

We can restrict the OEM ID to the current one or the one passed as CLI flag