Hi,
just shortly before hitting the *send* button on this mail, Guillem contacted
me in chat and was so kind to read my reply before I sent it. I have no amended
it with the feedback Guillem provided. I agree that there are a lot of
Linux-isms both in my mental model as well as in mmdebstrap itself. I hope we
can fix both going forward. It still feels very weird to me to think about
things like a "chroot" call not as a syscall but as something that is running
in userspace and can be done by anybody as long as one has the permissions on
the nodes that it is acting upon. That's really cool. :D
Quoting Samuel Thibault (2025-09-06 17:56:46)
> Johannes Schauer Marin Rodrigues, le sam. 06 sept. 2025 16:42:40 +0200, a ecrit:
> > If fakeroot-hurd is something that you wrap the mmdebstrap call in, then it's
> > not something that mmdebstrap should call. Instead, mmdebstrap should be able
> > to do the right thing when it is run inside fakeroot-hurd on hurd, no?
>
> Yes, but it'd be simpler if mmdebstrap could just call fakeroot itself
> as appropriate. I actually already does use fakeroot-tcp/sysv, it could
> use fakeroot-hurd.
when mmdebstrap is run with --mode=fakechroot, then it re-execs itself under
fakechroot/fakeroot. This is happening very early before any other code is
getting run and is a convenience function such that the user does not have to
manually prefix the mmdebstrap call with "fakechroot fakeroot" all the time.
mmdebstrap does not call a different "chroot" implementation itself. It makes
use of the fact that if a process is run inside "fakechroot fakeroot" then
whenever the "chroot" binary is getting exec-ed, it is not the real "chroot"
binary that gets run but the fake one.
Is what you are saying that under Hurd, mmdebstrap should be doing the same
convenience calling of fakeroot-hurd as it currently does for "fakechroot
fakeroot" such that the user does not have to prefix the call with
fakeroot-hurd?
> > > I don't really know where one would tell mmdebstrap to just use chroot.
> >
> > That's --mode=root.
>
> But we are not root here.
>
> I mean, I understand what you mean technically, but that's not what
> users will understand from the documentation. What I understand from
> "--mode=root" is that mmdebstrap should be run as root (or be given
> sudo rights), while it's not what we want to achieve. We still do need
> fakeroot in the play to be able to get files recorded as seemingly root
> and other debian users.
That sounds more like you'd like a differently named alias for the same option
then?
> > Could you try this patch: https://paste.debian.net/hidden/8e5bf3c7/
> >
> > And then run mmdebstrap with --skip=check/root,check/canmount which should
> > disable both checks that made it fail before and then hopefully you get a bit
> > further.
>
> But then permissions will be all wrong, we need fakeroot for that.
Yes, I mean, run:
fakeroot-hurd mmdebstrap --mode=root --skip=check/root,check/canmount ...
I agree that this is not a good UI yet but maybe you run into another technical
problem that needs fixing. To improve the UI, --mode=root could be replaced by
something that is named differently and does the fakeroot-hurd prefix
automatically on hurd similarly to how it's done for fakeroot/fakechroot on
linux with --mode=fakechroot.
To be clear: I added the --skip options for testing purposes on Hurd and
because I can see use for the --skip options on Linux as well. I did *not* mean
to imply that going forward, hurd users of mmdebstrap now have to always supply
--skip=check/root. In the patch I linked above you can see that I already added
a check for $options->{nativearch} !~ /^hurd-/ making the --skip=check/canmount
not really needed anymore. Maybe the same architecture check should be
happening at the point where I currently have the check for --skip=check/root
or maybe there is a better check for hurd which checks whether mmdebstrap is
really run under fakroot-hurd and thus has "fake" root permissions?
> > Except that fakeroot is not doing chroot at all.
>
> We are misunderstanding each other because we are not talking about the
> same views.
Yes, it's possible we are having a misunderstanding. I'd like to offer having a
video call (jitsi.debian.social) to maybe be more efficient when clearing up
such misunderstandings. If it's within Europe, a landline/mobile call would
also easily be possible for me without extra charges.
> > And even fakeroot+fakechroot is not doing any actual chroot. It's just
> > intercepting and modifying syscalls.
>
> I mean from the calling perspective, not from the actual technical
> things that get achieved.
>
> I know the latter. But I don't know the mmdebstrap code at all (and have
> just no time available to study it), but I'm quite sure that the code
> path that mmdebstrap already has to call fakeroot+fakechroot would be
> essentially the same to call fakeroot-hurd+chroot. And you do not need
> any particular hurdish knowledge there: fakeroot-hurd is usable exactly like
> fakeroot-tcp/sysv,
In that case, (as i outlined above) mmdebstrap could re-exec itself under
fakeroot-hurd as it does for fakechroot/fakeroot right now when it is run on
hurd with --mode=auto and/or a new --mode=fakeroot-hurd or just --mode=hurd. Is
that what you mean?
> and chroot is just the normal chroot as one would use it on linux.
And here you mean the chroot *binary* in /usr/sbin, right? Indeed mmdebstrap
doesn't really call the chroot binary itself. It is dpkg (if not run with
chrootless) which is doing the chroot. The other "chroot" is manually done by
the user within hooks. This is where fakechroot replaces the "chroot"
executable by its own implementation on Linux.
Thanks!
cheers, joschAttachment:
signature.asc
Description: signature