GNU bug report logs -
#36117
qemu-binfmt with non-native chroot
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#36117: qemu-binfmt with non-native chroot
which was filed against the guix package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 36117 <at> debbugs.gnu.org.
--
36117: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36117
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Hi,
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> Hello again,
>
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
> [...]
>
>>> ;; Platforms that QEMU can emulate.
>>> -(define-record-type <qemu-platform>
>>> - (qemu-platform name family magic mask)
>>> +(define-record-type* <qemu-platform>
>>
>> Since this is for internal consumption, I’m in favor of keeping plain
>> ‘define-record-type’. Also, I don’t think the “F” flag belongs here,
>> it’s mostly orthogonal.
>
> Even though it's still internal for now, the intent here was to allow
> the advanced users (those who would use (@@ ...) to access what they
> need) to configure the qemu-platform objects should they have special
> needs for it.
>
> I also don't think the flags belong to a qemu-platform object, but the
> same can be said for the magic field. The most elegant thing would be
> to have a binfmt_misc service which we would then extend for QEMU, but
> that's more work and the use cases appear to be rare outside of QEMU (I
> can only think of WINE). If you feel strongly about it I can revert
> those hunks and hard-coded the F flag.
>
>>> (define qemu-binfmt-service-type
>>> ;; TODO: Make a separate binfmt_misc service out of this?
>>> (service-type (name 'qemu-binfmt)
>>> @@ -800,9 +833,7 @@ given QEMU package."
>>> (const
>>> (list %binary-format-file-system)))
>>> (service-extension shepherd-root-service-type
>>> - qemu-binfmt-shepherd-services)
>>> - (service-extension guix-service-type
>>> - qemu-binfmt-guix-chroot)))
>>> + qemu-binfmt-shepherd-services)))
>>
>> As discussed on IRC, the downside of this approach is increased disk and
>> memory footprint (those big binaries have to be loaded in memory).
>
> The 'big' binaries are not that bigger than what we already have. For a
> typical one:
>
> $ du -h {/gnu/store/7w04gv6m92n40dainn4s6xr3l20r90xw-qemu-5.1.0,\
> /gnu/store/wqh2dyskzkl4vjn6harclyl317h4vfaf-qemu-5.1.0-static}/bin/qemu-arm
>
> 4.6M /gnu/store/7w04gv6m92n40dainn4s6xr3l20r90xw-qemu-5.1.0/bin/qemu-arm
> 6.4M /gnu/store/wqh2dyskzkl4vjn6harclyl317h4vfaf-qemu-5.1.0-static/bin/qemu-arm
>
> Only the registered QEMU architectures would be preloaded; so if you
> enable 5, the increase it at worst ~ 30 MiB. Nothing too worrying on
> machines that should be quite capable for transparent emulation
> purposes, in my opinion.
>
>> One possibility would be to add an option to choose between this and the
>> current approach, but maybe it’s not worth the maintenance trouble.
>
> I would rather K.I.S.S., with this only case that works everywhere and
> thus doesn't surprise anyone.
>
>> Thanks for fixing this issue!
>
> Thanks for the review!
>
> Maxim
I went ahead and pushed this change to master alongside the update to
QEMU 5.2.0.
If there are improvements/changes to be made, we can pick it up from
there!
Closing,
Maxim
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
I've been trying to use qemu-binfmt-service-type to build a non-native
chroot of a Debian system on Guix... because, well... because!
In Debian, this works with the qemu-user-static package, where the
binfmt sets these flags:
$ cat /proc/sys/fs/binfmt_misc/qemu-aarch64
enabled
interpreter /usr/bin/qemu-aarch64-static
flags: OCF
offset 0
magic 7f454c460201010000000000000000000200b700
mask ffffffffffffff00fffffffffffffffffeffffff
In particular, the F flag allows the host system binaries to be used as
the interpreter inside the chroot. But apparently, this only works with
static-built qemu targets, according to the linux's
Documentation/admin-guide/binfmt-misc.rst.
On Guix there are no flags set, and the binary used is a dynamically
linked executable:
$ cat /proc/sys/fs/binfmt_misc/qemu-aarch64
enabled
interpreter
/gnu/store/sw2rrqmjij73wcy3ajd47ypvmzh12yz6-qemu-3.1.0/bin/qemu-aarch64
flags:
offset 0
magic 7f454c460201010000000000000000000200b700
mask ffffffffffffff00fffffffffffffffffeffffff
So there are (at least) two things needed to make this work on Guix:
* A way to set the flags on qemu-binfmt-service-type.
* A static build of qemu-user targets
* A way to set which qemu to use for qemu-binfmt-service-type.
The *three* things are...
With this working correctly foreign-architecture chroots would become
trivial:
# on an amd64 host:
$ debootstrap --arch=arm64 buster buster-chroot http://deb.debian.org/debian
...
$ chroot buster-chroot /bin/bash
Enabling qemu-binfmt-service-type to operate in this way would obviate
the need for the "guix-support?" qemu-binfmt-configuration option, as
you could simply assemble the build environment without having to
include all of qemu's dependencies in the container.
It's a pretty magical feature.
live well,
vagrant
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 4 years and 72 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.