Hello josch, Thank you for looking into this.
On Tue, Apr 29, 2025 at 11:09:21PM +0200, Johannes Schauer Marin Rodrigues wrote: > The problem is, that you are running mmdebstrap as the normal user and that > user does not have the required privileges to look into the lost+found > directory to check whether it's really empty. With above patch, mmdebstrap > will > just fail with an appropriate error message. This will avoid the "readdir() > attempted on invalid dirhandle" errors from the subject of this bug. > > But I guess this is not quite why you opened this bug and your actual problem > is that mmdebstrap gets stuck? Thank you for your explanation and patch. mmdebstrap might not have been stuck at the download phase, my network was just irresponsive and I was killing the process as I saw the errors showing up. However, I am seeing errors further down. With the same prompt, I'm now seeing I: skipping emulation check in chrootless mode I: finding correct signed-by values... done I: running apt-get update... done I: downloading packages with apt... done I: extracting archives... tar: .: Cannot utime: Operation not permitted tar: .: Cannot change mode to rwxr-xr-x: Operation not permitted tar: Exiting with failure status due to previous errors E: tar --extract failed: 512 W: hooklistener errored out: E: received eof on socket I: main() received signal PIPE: waiting for setup... E: mmdebstrap failed to run > If yes, please read on. Otherwise, consider the bug as fixed with the next > upload of mmdebstrap via above patch. > > Firstly, please be *very* careful with chrootless mode. You are running > maintainer scripts outside the chroot and this mode is barely tested and many > packages are not made to work with it at all. So anything can happen including > a complete wipe of your $HOME. For that reason and because nothing is checking > whether the versions of programs run by maintainer scripts are of the version > that your packages inside the chroot expect, it is always a good idea to wrap > a > chrootless mmdebstrap call in some sort of containerization. This includes > running mmdebstrap in chrootless mode as a customize hooks inside mmdebstrap > in > unshare mode, for example. > > Secondly, have you tried creating a hurd chroot on linux the "normal" way? > That > is by creating a filesystem from a tarball? > > Here is my latest set of runes on the topic: > > https://salsa.debian.org/helmutg/dpkg-root-demo/-/merge_requests/3/diffs#57c00b22e45b81dde62199ab610d05ce70f829bf_0_17 > > What do you ultimately want to do? What I am trying to do is to use mmdebstrap to setup a hurd + linux dual boot setup, in a similar way to what is achieved with crosshurd (https://packages.debian.org/sid/crosshurd). I see what you mean about creating a tarball and copying this over to a new partition, but since mmdebstrap can use a directory as a target, I thought it would be possible to shortcut that step. I hear all the warnings you make about chrootless mode, and that is why I was running as a normal user instead of root, but you seem to advise even against that. The problem in running mmdebstrap --mode=chrootless --arch=hurd-i396 inside another mmdebstrap chroot is that the target mountpoint for the hurd partition would not be accessible. Do you see a way to install a hurd image to a partition without creating and copying a tarball explicitly? Many thanks, João
