Your message dated Fri, 1 Jun 2018 17:02:18 +0300
with message-id <[email protected]>
and subject line Re: Bug#882024: allow bind mounting the qemu binaries into a
chroot
has caused the Debian Bug report #882024,
regarding allow bind mounting the qemu binaries into a chroot
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
882024: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882024
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: qemu-user-static
Version: 1:2.10.0+dfsg-2
Severity: wishlist
qemu-debootstrap's approach of copying the host emulation binary into
the chroot is kind of messy. Nothing updates that binary when this
package is upgraded. If the chroot is turned into a bootable disk image
on the target hardware, the binary ought to be deleted, which is an
added complication to deal with.
So I had an idea of moving the qemu static binaries into a subdirectory
someplace. They could still be symlinked to /usr/bin/, but make the
binfmt-misc paths use the subdirectory. Then that subdirectory could be
bind mounted (readonly) into a chroot to make the binaries available
inside it without copying them.
Downside is that the bind mount would need to be set up on boot,
or when the chroot is used, so the current copying might need to remain
the default, and an option to do a cleaner bind mount added to
qemu-debootstrap.
(Of course, many user of chroots require mounting other stuff into them
eg /proc, so this would just be one more thing to mount.)
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
qemu-user-static depends on no packages.
Versions of packages qemu-user-static recommends:
ii binfmt-support 2.1.8-1
Versions of packages qemu-user-static suggests:
ii sudo 1.8.21p2-2
-- no debconf information
--
see shy jo
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Version: 1:2.12~rc3+dfsg-1
On Fri, 17 Nov 2017 14:07:48 -0400 Joey Hess <[email protected]> wrote:
> Package: qemu-user-static
> Version: 1:2.10.0+dfsg-2
> Severity: wishlist
>
> qemu-debootstrap's approach of copying the host emulation binary into
> the chroot is kind of messy. Nothing updates that binary when this
> package is upgraded. If the chroot is turned into a bootable disk image
> on the target hardware, the binary ought to be deleted, which is an
> added complication to deal with.
>
> So I had an idea of moving the qemu static binaries into a subdirectory
> someplace. They could still be symlinked to /usr/bin/, but make the
> binfmt-misc paths use the subdirectory. Then that subdirectory could be
> bind mounted (readonly) into a chroot to make the binaries available
> inside it without copying them.
I think we now have the solution for this -- see #868030.
More, I think qemu-debootsrap copying the binary is now not necessary
(it can be a separate bugreport but we've enough bugreports for qemu
already ;) )
Please reopen this bug if you think it is not enough.
Thanks,
/mjt
--- End Message ---
