Hi João, sorry for taking so long to come back to you on this. Life (exam season) got in the way of things. Quoting João Pedro Malhado (2025-04-30 19:13:57) > 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 Further down you write that you are running mmdebstrap as the normal user. What the above error message is telling you is, that your user does not have the required permissions to change the utime and mode of your /hurd directory which tar sees as ".". > > 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. Yes, it should work if you have the required privileges. But to be able to create files owned by root you need to have the required privileges which your normal user does not. Going via a tarball "cheats" because of course anybody can create a tarball containing files owned by 0:0. It could work if you run it as the superuser but doing so is very dangerous thanks to how chrootless mode works. This is why I'd recommend splitting your installation into two steps, each of which has different risks: First step: create the rootfs. Since this involves running arbitrary maintainer scripts, this should be contained in a way that avoids messing with the rest of your system. This requirement directly conflicts with your requirement of "I want it to perform changes in /hurd" which is why there is: Second step: now that you have the tarball created, extract it somewhere. Extracting a tarball is not running arbitrary shell scripts and is thus much safer to do as the superuser. > 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. Yes. Your normal user still has the required privileges to wipe your $HOME. > 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. You can cheat though because mmdebstrap allows execution of arbitrary code as part of hooks. You thus could use a hook to mount things in a way which allow the inner mmdebstrap to perform the changes you need but I have not done that. If you want to go that route, you are exploring new territory. > Do you see a way to install a hurd image to a partition without creating and > copying a tarball explicitly? If you hate creating temporary files that much there is also the option of piping the tarball which mmdebstrap can write to stdout into mke2fs: mmdebstrap [options and hooks] "-" | sudo mke2fs -d - /dev/sdX Again, unexplored territory. If you have more questions please don't hesitate to ask. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature