bug#36117: qemu-binfmt with non-native chroot

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 3118 bytes --]

On 2019-06-07, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant@debian.org> skribis:
>> 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.
>
> True!  Though adding all the dependencies of QEMU in the chroot the way
> ‘guix-support?’ does it turns out to be pretty magical too ;-), because
> we can precisely list those dependencies and include nothing but these
> dependencies in the chroot—something that cannot be done on an FHS
> system.

Indeed!


> As an quick workaround, perhaps you could bind-mount all the entries of:
>
>   guix gc -R $(guix build qemu)
>
> in your Debian chroot?

I tried an even lazier experiment, bind-mounting all of /gnu into the
new chroot directory before running debootstrap, and it worked!


That said, it's still a manual step (mounting /gnu or /gnu/store/qemu*)
required to do something that could otherwise be handled transparently
with a static build of qemu and adjusting the binfmt_misc flags... so if
permitted to dream, I still think that would be a nice option to have
available. :)


Another interesting angle is that including qemu and all of qemu's
dependencies in a guix build environment is that qemu or one of it's
dependencies might actually get used during the build... even if not
explicitly included in one of the inputs or one of the build systems. So
maybe the case can be made that the qemu-static build from executed from
the host system is cleaner than copying all of qemu and dependencies
into the build environment...


> (Speaking of which… it would be great to have a Debian API in Guix, where
> you could write, say:
>
>   (debian-build #~(system (string-append "/bin/uname > "
>                                          #$output)))
>
> Food for thought…)

Not quite sure of what you're going for, but perhaps best to have that
conversation elsewhere.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]