Your message dated Tue, 5 Oct 2021 21:52:53 +0300
with message-id <[email protected]>
and subject line Re: Bug#943885: SHELL=/usr/bin/zsh triggers qemu-debootstrap
failure: file not found error
has caused the Debian Bug report #943885,
regarding SHELL=/usr/bin/zsh triggers qemu-debootstrap failure: file not found
error
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.)
--
943885: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943885
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: qemu-user-static
Version: 1:4.1-1+b4
Dear maintainer,
When I was trying to bootstrap a foreign stage3 with qemu-debootstrap,
it failed and said "/debootstrap/debootstrap: no such file or
directory". After investigating the problem with strace I fixed it
with
export SHELL=/bin/sh
--- End Message ---
--- Begin Message ---
On Thu, 31 Oct 2019 12:22:38 +0000 Mo Zhou <[email protected]> wrote:
Package: qemu-user-static
Version: 1:4.1-1+b4
Dear maintainer,
When I was trying to bootstrap a foreign stage3 with qemu-debootstrap,
it failed and said "/debootstrap/debootstrap: no such file or
directory". After investigating the problem with strace I fixed it
with
export SHELL=/bin/sh
Well. This is not qemu-debootstrap issue. qemu-debootstrap runs regular
debian debootstrap to do the whole work (btw, qemu-debootstrap itself is
not needed actually, it is just a useless wrapper these days, don't use
it).
What happens is: debootstrap installs a new system within a given directory
(it does not matter if it is foreign or not), and has to run some stuff
inside it. At this time, from your environment, we have SHELL=/bin/zsh.
But zsh is not installed within the newly installed system (unless you
explicitly tell debootstrap to --include= it). And here we go, some
scripts inside the newly created chroot are trying to be run with $SHELL
which does not exists.
Perhaps debootstrap can set some sane value for $SHELL, I dunno. In any
case this has absolutely nothing to do with (obsolete) qemu-debootstrap
wrapper.
I'm closing this bugreport now. If you think debootstrap is incorrect there,
you can file a bugreport against debootstrap.
Thanks!
/mjt
--- End Message ---
