Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #272488

Re: QEMU: Run a container of a different architecture

From Steve Keller <keller.steve@gmx.de>
Newsgroups linux.debian.user
Subject Re: QEMU: Run a container of a different architecture
Date 2024-08-23 16:30 +0200
Message-ID <JeDsB-72Qd-3@gated-at.bofh.it> (permalink)
References <JdVhT-6Ak1-7@gated-at.bofh.it> <JejNf-6PJA-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


"Tim Woodall" <debianuser@woodall.me.uk> writes:

> Don't know about systemd-nspawn but I do something like this using
> unshare, binfmt-support and qemu-user-static.
>
> I don't have to do anything at all other than create the file system
> with the emulated architecture and then chroot into it with those
> packages installed.

Thanks, the hint to qemu-user-static solved the issue very easily.
Nothing to install inside the container or other things to setup.  I
just installed qemu-user-static, which removed qemu-user-binfmt
because qemu-user-static brings its own binfmt support.

After installing I could simply run systemd-nspawn -D deb-arm64 and it
worked immediately, where deb-arm64 is the directory to which I have
installed the Debian/arm64 system using debootstrap.

I think systemd-nspawn does something very similar to what you do with
unshare and chroot.

> Perhaps systemd-nspawn would similarly work with those packages
> installed.

Yes, out of the box.  I find this a litte bit surprising since

    # head -n2 /proc/sys/fs/binfmt_misc/qemu-aarch64
    enabled
    interpreter /usr/libexec/qemu-binfmt/aarch64-binfmt-P
    # ls -l /usr/libexec/qemu-binfmt/aarch64-binfmt-P
    lrwxrwxrwx 1 root root 29 May  9 07:44 /usr/libexec/qemu-binfmt/aarch64-binfmt-P -> ../../bin/qemu-aarch64-static

these paths are not visible in the chroot environment or the mount
namespace, respectively.  That means the kernel probably does the
interpreter lookup earlier, not at execution time in the chrooted
environment.  Besides that, qemu-aarch64-static doesn't need any other
files from the host environment.  In contrast, qemu-aarch64 which I had
used instead, needs libraries which it cannot find in the chrooted
environment and therefore fails.

Nevertheless, it would be nice to be able to run qemu-aarch64
dynamically linked which finds its libs in the host environment but
runs the command in the current inherited environment.  But I guess
that's impossible.

Steve

Back to linux.debian.user | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

QEMU: Run a container of a different architecture Steve Keller <keller.steve@gmx.de> - 2024-08-21 17:20 +0200
  Re: QEMU: Run a container of a different architecture Markus Schönhaber <debian-user@list-post.mks-mail.de> - 2024-08-21 19:10 +0200
    Re: QEMU: Run a container of a different architecture Steve Keller <keller.steve@gmx.de> - 2024-08-21 22:30 +0200
  Re: QEMU: Run a container of a different architecture Tim Woodall <debianuser@woodall.me.uk> - 2024-08-22 19:30 +0200
    Re: QEMU: Run a container of a different architecture Steve Keller <keller.steve@gmx.de> - 2024-08-23 16:30 +0200

csiph-web