Hi Christoph, Quoting Christoph Groth (2022-09-08 10:13:04) > Johannes Schauer Marin Rodrigues wrote: > > > Thank you, your input was very valuable because proot was essentially > > broken since 16 August 2021 and I was waiting for somebody to tell me > > that they are a proot user and why they need it. You are a proot user > > but it seems that creating the chroot in fakechroot mode instead of > > proot still lets you do what you need. Now I guess I can remove it for > > good. > > With mmdebstrap 0.7.5-2.2 on my Debian stable install, so far I can > still run for example > > mmdebstrap --mode=proot --include=hello testing /tmp/proot > > This ends with the error message that prompted our previous discussion. > > The created chroot is usable with proot, however the package “hello” is > NOT available inside (perhaps due to the error during chroot creation). > But I can install it with apt. > > So far nothing new. But when I try (as I believe you suggest), to > execute the following command: > > mmdebstrap --mode=fakechroot --include=hello testing /tmp/fakechroot > > I obtain an error that includes a segmentation fault (see below for the > full output). Am I doing anything wrong? But, I guess, even if I am, > the above command should not result in a segfault.
There are two problems. One problem is written in the log you pasted:
> I: extracting archives...
> done
> /usr/sbin/chroot.fakechroot: line 105: 18113 Segmentation fault env -u
> FAKECHROOT_BASE_ORIG FAKECHROOT_CMD_ORIG=
> LD_LIBRARY_PATH="$fakechroot_chroot_paths"
> FAKECHROOT_BASE="$fakechroot_chroot_base" "$fakechroot_chroot_chroot"
> "${@:1:$(($fakechroot_chroot_n - 1))}"
> "${fakechroot_chroot_newroot#$FAKECHROOT_BASE_ORIG}"
> "${@:$(($fakechroot_chroot_n + 1))}"
> I: the /bin/mv binary inside the chroot doesn't work under fakechroot
> I: with certain versions of coreutils and glibc, this is due to missing
> support
> for renameat2 in fakechroot
> I: see https://github.com/dex4er/fakechroot/issues/60
> I: expect package post installation scripts not to work
This is a bug that is solved in the next Debian release. Nothing you can do
about it if you are using stable only.
The other problem is, that you are trying to create a testing chroot from
stable. The fakechroot mode has the limitation that the C-libraries of the
system on the outside and the system on the inside have to be quite similar. A
few weeks ago, a new glibc upload happened to unstable and since migrated to
testing. Since that upload, it became impossible to create a testing chroot
with fakechroot from stable. This is not the fault of mmdebstrap but a
fundamental problem with how fakechroot works and is also documented in the man
page of fakechroot in the section "LIMITATIONS".
So how do you fix that? We come back to what I said a few emails back.
Directories are a really bad way to work with chroots. Tarballs are much
better. So how about you just run this:
$ mmdebstrap --include=hello testing /tmp/fakechroot.tar
This will probably choose the "unshare" mode on your system. Since you are not
building a directory tree but a tarball, the ownership information in that
tarball will be correct. If you want to use proot with it, then you do not care
about ownership information so you can just extract it as your normal user and
are left with the chroot directory you want.
But why do I need a temporary file you say? You do not if you don't want to.
You can also run this:
$ mmdebstrap --include=hello testing - | tar -C /tmp/fakechroot -x
This will make mmdebstrap write the tarball to standard output (so no temporary
files) and tar will immediately extract that tarball to the directory you pass
with the -C option.
Does that work for you?
Thanks!
cheers, josch
signature.asc
Description: signature
