Hi, there is a lot to unpack here...
Quoting Christoph Groth (2022-09-02 18:24:08) > > Quoting Christoph Groth (2022-09-02 15:58:45) > > > Running mmdebstrap in proot mode seems no longer to work, > > > > yeah, I'm aware. I'm tempted to "solve" the problem by removing proot > > mode. > > > > I am curious: why do you want to use proot mode over the other modes? > > What advantage does it give you for your use-case? > > I use mmdebstrap and proot to quickly create debugging environments, > usually under /tmp/. For example right now I’m trying to debug why > a test in some library of mine fails [1] for Python 3.10 on i386. If you just want to debug a FTBFS of a Debian package, why do you not just run sbuild with --anything-failed-commands=%s and call it a day? Advantages: - you do not need to setup your own chroot - you get exactly the environment that the FTBFS happened in - all your dependencies are already installed - in contrast to using proot, all ownership information will be correct - you do not need mmdebstrap at all - you do not need to do any special cleanup at the end > The way I usee mmdebstrap and proot is like this: > > mmdebstrap --mode=proot --include=python3-all-dev testing /tmp/test 'deb > http://deb.debian.org/debian/ testing main non-free contrib' > > Then, as a non-priviledged user, I can run > > proot -S /tmp/test > > to become “root” within that environment and, for example, install > missing packages. > > I can also run > > proot -R /tmp/test > > to use the environment as a regular user, with read and write access to > my regular home directory. This is how I run my tests. You are mixing different things here which are actually orthogonal. In principle you have two problems: 1) you want to create a chroot directory 2) you want to enter that chroot but also have your /home available Those are two different things and proot is not necessarily the answer to both. The reason why I stopped caring about proot is, that in contrast to fakeroot and fakechroot it doesn't preserve ownership between individual runs. This is okay in many situations and I can imagine that debugging some Python problem doesn't care about any ownership information. But a lot of applications very much do care about this, so I consider proot to be suboptimal and not worth a lot of my time. Nevertheless, as explained above you actually have two problems. Even if you accept that ownership information is dropped and that's fine for you, you do not necessarily use proot for both tasks. You could use fakechroot mode to solve (1) and then use proot to enter the directory that was created to solve (2). Also, do you actually need the chroot directory to persist permanently? Because you could also run something like this: mmdebstrap --mode=unshare --include=python3-all-dev testing \ --customize-hook='mount -o ro,bind /path/outside "$1"/path/inside' \ --customize-hook='chroot "$1" /bin/bash' \ /dev/null Using unshare mode, you get nearly all the things root can do (proot cannot do all these things) and using two customize hooks you mount a path into your chroot and then spawn a bash terminal in it that lets you do whatever you want inside the chroot. By giving /dev/null as the chroot path, the whole thing will only live in a temporary directory and will automatically be cleaned up once you leave that shell. But you are going beyond what mmdebstrap was meant for. mmdebstrap was meant for you to create a chroot and that's it. As you can see from the example above it is totally possible to also use it for your use-case but that's rather hacky. If you want the functionality of entering a chroot you created and do stuff in it, maybe use some software that was meant to be used like that? For example you can combine mmdebstrap (for creating the chroot) with docker or podman or systemd-nspawn. See the man page for examples. > I would be grateful if you could point me to some alternative way of > using mmdebstrap-created chroots as a regular user, with the possibility > to install further packages, and with the possibility to access my > regular home directory. > > I tried > > mmdebstrap unstable ./unstable-chroot > mmdebstrap --unshare-helper /usr/sbin/chroot ./unstable-chroot /bin/bash > > which is brievly mentioned in mmdebstrap(1) but seems otherwise > undocumented. It runs, but within that environment I’m unable to > install anything: > > ################################################################ > root@drac:/# apt update > Get:1 http://deb.debian.org/debian unstable InRelease [192 kB] > 0% [Working]/usr/bin/apt-key: 95: cannot create /dev/null: Permission denied > /usr/bin/apt-key: 95: cannot create /dev/null: Permission denied > /usr/bin/apt-key: 95: cannot create /dev/null: Permission denied > E: gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed > Err:1 http://deb.debian.org/debian unstable InRelease > gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed > Reading package lists... Done > W: GPG error: http://deb.debian.org/debian unstable InRelease: gpgv, gpgv2 or > gpgv1 required for verification, but neither seems installed > E: The repository 'http://deb.debian.org/debian unstable InRelease' is not > signed. > N: Updating from such a repository can't be done securely, and is therefore > disabled by default. > N: See apt-secure(8) manpage for repository creation and user configuration > details. > ################################################################ Yes. This is because if you just run "mmdebstrap --unshare-helper /usr/sbin/chroot" then it will do nothing else then do a chroot into the given directory. Since you cannot create any device nodes as the unshared user, /dev/null is missing. You can either bind-mound /dev/null and all the other device nodes from the outside yourself or you can use another trick and enter a chroot tarball like this: mmdebstrap --variant=custom --skip=update \ --setup-hook='tar-in chroot.tar /' \ --customize-hook='chroot "$1" bash' \ unstable /dev/null This is also documented in the man page but again, this is abusing what mmdebstrap can do and you should instead use a tool that was meant to do this like docker, podman or systemd-nspawn. Also note how above command uses a tarball as input and not a directory. Using a tarball over directories has many advantages: 1. you preserve all permission and ownership information and even extended attributes 2. you can just rm the tarball once you are done with it without any special tricks (see below) 3. the tarball will use less space than the unpacked directory and can even be compressed if you like, saving even more space > Moreover, I have to become root to remove that unstable-chroot directory > (which is strange, since I created it as a regular user)! You do not need to be root to remove that directory but you do need to be the unshared user because that user was the one who created it. So this will work: mmdebstrap --unshare-helper rm -rf ./unstable-chroot/* rmdir ./unstable-chroot The first command will remove everything inside your chroot directory and the second will then remove the now-empty directory. The first command cannot remove the directory itself because it's in a directory owned by you and not by the unshared user, so the second command needs to be run by you and not by the unshared user. So in summary, I still don't understand why proot-mode should stay. Even if I delete proot mode from mmdebstrap for good your use-case will still continue to work because you can create the chroot directory that you need for proot with the fakechroot mode. I would recommend you to use tarballs instead of creating directories for the reasons given above. But then again, since you are fine with proot it seems that you don't care about preserving ownership information. But then again, going back to your very initial issue (you want to debug a Debian FTBFS bug) it seems you do not need neither mmdebstrap nor proot and are just making your life more complicated. :) What do you think? cheers, josch
signature.asc
Description: signature
