Hi, Quoting Giovanni Mascellani (2019-09-13 10:18:07) > it seems that mmdebstrap does not work inside a docker container. After > installing docker.io and qemu-user-static on a computer, for example: > > # docker run -it --rm debian:unstable > [now inside the container] > # apt update > # apt install qemu-user-static mmdebstrap > # mmdebstrap --architectures=armhf --verbose unstable /tmp/debian.tar.gz > 'http://deb.debian.org/debian' > I: automatically chosen mode: root > I: armhf cannot be executed, falling back to qemu-user > E: binfmt_misc not found in /proc/mounts -- not mounted? > > Here mmdebstrap fails because it tries to look for the binfmt_misc > filesystem, which is not available inside docker. This is not a problem, > because the support for foreign executable is still configured outside > the container and is available in the container too, but it would be > useful to tell mmdebstrap to accept that binfmt_misc is available even > if it cannot check it. > > I can do this manually by commenting out a few lines in mmdebstrap: > > > #{ > > # open my $fh, '<', '/proc/filesystems' or error "failed > > to open /proc/filesystems: $!"; > > # unless (grep /^nodev\tbinfmt_misc$/, (<$fh>)) { > > # error "binfmt_misc not found in > > /proc/filesystems -- is the module loaded?"; > > # } > > # close $fh; > > #} > > #{ > > # open my $fh, '<', '/proc/mounts' or error "failed to > > open /proc/mounts: $!"; > > # unless (grep /^binfmt_misc > > \/proc\/sys\/fs\/binfmt_misc binfmt_misc/, (<$fh>)) { > > # error "binfmt_misc not found in > > /proc/mounts -- not mounted?"; > > # } > > # close $fh; > > #} > > #{ > > # open my $fh, '-|', '/usr/sbin/update-binfmts', > > '--display', "qemu-$options->{qemu}" // error "failed to fork(): $!"; > > # chomp (my $binfmts = do { local $/; <$fh> }); > > # close $fh; > > # if ($binfmts eq '') { > > # error "qemu-$options->{qemu} is not a > > supported binfmt name"; > > # } > > #}
the code you quote exists to give meaningful output in cases where foreign architecture binaries cannot be executed. Instead of adding another knob to the command line interface, I would prefer either of these two solutions: - turn the errors into warnings -- in case there is an error later, the user can use the earlier warning to diagnose it - only run the checks after executing a test executable failed as a diagnostic. If the test executable was successfully executed, then there is no reason to run the checks from above. Thanks! cheers, josch
signature.asc
Description: signature
