Hi, I'm putting Debian Hurd maintainers in CC.
Quoting J.P.Malhado (2025-04-29 17:26:34) > When running with the following command prompt > > mmdebstrap --mode=chrootless --format=directory --arch=hurd-i386 \ > > --include=sysvinit-core,sysv-rc,debian-ports-archive-keyring,gnumach-image-1-486 > --customize-hook="passwd --root=\"\$1\" --delete root" \ > --variant=apt unstable /hurd \ > "deb http://deb.debian.org/debian-ports/ unstale main" \ > "deb http://deb.debian.org/debian-ports/ unreleased main" > > where /hurd is the mountpoint for a partition with a filesystem > generated with "mk2efs -o hurd" with write permissions to non-root > users, and the command is being run by a normal user account, > I'm getting the following output: > > I: skipping emulation check in chrootless mode > I: finding correct signed-by value... > done > readdir() attempted on invalid dirhandle $dh2 at /usr/bin/mmdebstrap line > 6889. > readdir() attempted on invalid dirhandle $dh2 at /usr/bin/mmdebstrap line > 6890. > readdir() attempted on invalid dirhandle $dh2 at /usr/bin/mmdebstrap line > 6893. > closedir() attempted on invalid dirhandle $dh2 at /usr/bin/mmdebstrap line > 6897. > I: running apt-get update... > downloading: 0.00 [> > > And seems to get stuck. you title your bug "readdir() attempted on invalid dirhandle". That problem is easily "fixed" with the following patch: --- a/mmdebstrap +++ b/mmdebstrap @@ -6914,7 +6914,9 @@ sub main() { # it, if it's empty if ($entry eq "lost+found" and -d "$options->{root}/$entry") { - opendir(my $dh2, "$options->{root}/$entry"); + opendir(my $dh2, "$options->{root}/$entry") + or error + "Can't opendir($options->{root}/$entry): $!"; # Attempt reading the directory thrice. If the third # time succeeds, then it has more entries than just "." # and ".." and must thus not be empty. 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? 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? I fear that it takes somebody who understands Hurd to track down your "stalling" problem with apt. Did you try running strace or something to figure out where it stalls? Thanks! cheers, josch
signature.asc
Description: signature
