Support OpenRC distros

[kasperk81]

Distros like Alpine Linux (on baremetal or a full VM), binfmt is provided by openrc package.

Is it possible to support such distros to get qus?

[umarcor]

This is the generic solution for registering an interpreter: https://github.com/umarcor/qemu/blob/series-qemu-binfmt-conf/scripts/qemu-binfmt-conf.sh#L304

qemu_generate_register > /proc/sys/fs/binfmt_misc/register

What would be the alternative on an Alpine Linux host?

Note that, compared to upstream (https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh) we don't modify how the interpreters are registered, but just which of them. Therefore, the main question is how does this work on Alpine with the default qemu?

[kasperk81]

I have /proc/sys/fs/binfmt_misc/ but directory is empty. Also the qemu-system-aarch64, for example, runs arm64 ELF on x86_64 host.

[umarcor]

Also the qemu-system-aarch64, for example, runs arm64 ELF on x86_64 host.

Yes. Running any foreign binary by prepending qemu-static or using qemu-system does always work. Registering the interpreter is only required if you expect to call a foreign binary directly. See https://dbhi.github.io/qus/#context-docker-and-qemu.

There seems to be no reference to binfmt in the Alpine Linux wiki. Hence, I suggest to ask through some of their community channels. Once you know how to register the interpreter locally, we can handle that here.

[kasperk81]

Systems using openrc init (alpine, gentoo etc.) has a binfmt service running in baremetal (or VM) installation.

There is no difference how services are registered, the only difference is how we start/restart/stop the services in systemd vs. openrc distros. OpenRC way to register the format and call rc-service binfmt restart.

Few references:

Here is the openrc binfmt service definition, as you can see it comes from openrc base package. It calls into this script, which pushes to /proc/sys/fs/binfmt_misc/register.

Here is the qemu specific wrapper script registering the formats the same way as yours. It is available as a separate package.

[umarcor]

@kasperk81 if that is the case, dbhi/qus should work for your use cases, as is. What is the problem you are having? Are the static binaries registered by qus not usable on baremetal Alpine? In other words, did you try using qus already or did you ask before?

[kasperk81]

@umarcor, sorry for the confusion. I was thinking about porting qus to Alpine Linux ports, e.g. https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/testing/aqemu/APKBUILD. I tried to build the repo locally on alpine but the support was missing.

$ git clone https://github.com/dbhi/qus
$ cd qus
$ ./run.sh -b
...
./run.sh: line 176: dpkg: command not found
tar: unrecognized option: wildcards
BusyBox v1.33.1 () multi-call binary.

Usage: tar c|x|t [-ZzJjahmvokO]....

However, for my purpose, it looks like qemu-openrcpackage fills the qus gap for at least for what I was trying to achieve: https://github.com/alpinelinux/alpine-chroot-install/pull/29/files#diff-9de996ddfe203d19ad9007d3f4509f300037b59c137c512b25492fb598d325a1R262 (port alpine chroot script to run on alpine host itself, and RHEL-likes).

If you think it is worth porting qus still provide advantage over Alpine and other musl/busybox/openrc distros, please help with the port (error above). Otherwise, feel free to close this one out as I am unblocked by qemu-openrc.

[umarcor]

No worries, mate! We are both learning from this dialogue.

Overall, the point is that the only feature/advantage of qus is distributing qemu-static binaries through containers.

Hence, if you want to use containers on your workstation/laptop/CI/SBC and you need those containers to belong to a foreign architecture, it does make sense to use qus because you already have a container engine installed. Say executing an amd64 container on a Raspberry Pi, or conversely executing an aarch64 container on GitHub Actions. Compared to other approaches, qus allows you to run a single liner which will run a temporary container, register the interpreters and exit. No need to "install" anything on the host. From there on, you can use foreign binaries either locally or when building/running containers.

That is, qus is an alternative to installing the qemu/qemu-static system packages (through apt, dnf, yum, whatever). It does not provide any other feature which you cannot achieve by downloading/installing qemu-static yourself and running the script for registering the interpreters. Very precisely, we don't build QEMU in our CI. The qemu-static binaries we distribute are retrieved from Debian and Fedora servers. That's where QEMU is built and the static binaries are generated. Here, we create containers, we put some of those binaries inside, and we add a couple of shell scripts for allowing the registration of one or multpiple interpreters.

Therefore, I don't think there is a point in porting qus (this repo/project) to be an Alpine package per se. If you install docker/podman on Alpine, you can already use qus. Alternatively, you can use the qemu system package. You might want to use register.sh and qemu-binfmt-conf.sh, but I don't know if it's worth packaging that.

[kasperk81]

Thanks for the explanation. I thought qemu-user-static depends on qemu when user installs it. Now I understood that it is not the case; i.e. it is truly static in nature. :)

The qemu-openrc package in Alpine Linux depends on qemu. The qemu-user-static on ubuntu only depnds on binfmt. Thanks again, for pointing out this difference.

I think it should be possible to port qemu-user-static to Alpine by compiling qemu-static binary as part of its build script and making the register/qemu-binfmt-conf scripts busybox-complaiint? As I understood it, those scripts alone would not bring much value on top of what qemu-openrc scripts (https://github.com/jirutka/qemu-openrc) already provide. The container use-cases where qus is helpful on Debian/Fedora are also applicable to Alpine.