Improve support for using bootc-image-builder under virtualisation (cross-arch).

[phr34k]

I've tried various setups and configurations but in pretty much every setup, bootc-image-builder seems to give me trouble in one way or another and a humble request would be if there's a chance the software could be made compatible so that it could run a virtual machine or preferably on wsl (windows subsystem for linux).

Here's some examples:

On WSL building the containers using podman for cross architecture (i.e. amd64 host -> aarch64 container) works fine, but running bootc-image-builder both ext4 and xfs rootfs are giving errors. For xfs the error is cannot set blocksize 512 on block device /dev/loop0: Inappropriate ioctl for device. For ext4 the error is Function not implemented (os error 38). If I understood correctly, both error seem to imply that WSL kernel features doesn't really meet the what is needed for an image build, although I'm not sure, or some kind of qemu syscall isn't suspported.

On a newly installed virtual machine with nested virtualization it seems to come a little bit further but it errors on, I've tried re-configuring podman increasing various limits and increasing the locks in general and it didn't make a differences.

Installing to filesystem: Creating imgstorage
: Initializing images: Subprocess failed: ExitStatus(unix_wait_status(32000))
Error: failed to open 2048 locks in /libpod_lock: numerical result out of range
Traceback (most recent call last):
File "/run/osbuild/bin/org.osbuild.bootc.install-to-filesystem", line 89, in <module>
    r = main(args["options"], args["inputs"], args["paths"])
  File "/run/osbuild/bin/org.osbuild.bootc.install-to-filesystem", line 82, in main
    subprocess.run(pargs, env=env, check=True)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/subprocess.py", line 578, in run
    raise CalledProcessError(retcode, process.args,
                             output=stdout, stderr=stderr)

I've also been recommended to use image-build-cli as an alternative but that project also doesn't seem to run, i have access to a single workstation with plenty of memory to run vm's or dockers but am having a hard time finding an configuration that works to convert an aarch64 oci container to a bootc image that i can actually flash on my target device.

[supakeen]

So going through this; the first errors you report (when using (bootc-)image-builder with --arch) are qemu-user-static, which we use for the experimental cross architecture builds, not implementing the syscalls or syscall arguments that are required for the userland in the container. This happens often, especially when dealing with Fedora where userland is often quite up to date and kernels are very new. There's nothing that can be done about it, it will happen at times and qemu-user-static will (hopefully) catch up. You'll see it more often in (bootc-)image-builder as we do a lot of stuff with filesystems.

There's a combined problem here that you're running under WSL which indeed likely is also missing (some of) the filesystems involved.

The last bug, when running fully virtualized I think is actually a bootc (or podman) bug.

---

In summary: cross-architecture builds are experimental in (bootc-)image-builder. We've also not tested (bootc-)image-builder to run under WSL. The combination is unlikely to work (and it seems to not work).

The last bug is actually interesting but it seems to be in bootc itself.

[phr34k]

@supakeen that's what I already suspected after your initial explanation. I understand that the kernels have a tendency of using new syscalls, and well emulated support for these lags behind so it's a moving target.

That being said, please correct if I'm wrong, but the only thing that the last stage of bootc-image-builder is supposed to do is prepare a file system, the boot partitions, and extract files for the boot partition, and convert the remainder of the oci image into a libostree commit. Disregarding the current status quo, I think most of these steps could actually be done in a arch agnostic way, I mean, projects like rpi-gen, debos i can make aarch64 images on amd64 without such complications.

Couldn't there be an option to simply let bootc-image-builder bootstrapping be less depended on emulation, I mean surely, this aspect just seems to make the entire project more fragile than is actually necessary. Could we in concept not just pass in a second image with and amd64 version of bootc and whatever is needed to bootstrap the boot partition instead of forcing qemu.

I was hoping that image-builder-cli avoids the emulation, on Ubuntu VM I ended up doing a install from source for image-builder-cli together with ostree and ended up with the same 2048 after repeatedly hitting an error trying to run. I also double checked against Fedora 44 VM (oci image is also Fedora 44 based) pulling image-builder-cli from dnf and it also fails.