Re: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode
Johannes Schauer Marin Rodrigues, le jeu. 08 févr. 2024 00:04:25 +0100, a ecrit:
> Quoting Samuel Thibault (2024-02-07 23:32:34)
> > > So I manually created the empty files /servers/exec, /servers/startup and
> > > /dev/console as it is done by debootstrap here:
> > >
> > > https://sources.debian.org/src/debootstrap/1.0.134/functions/?hl=1304#L1304
> >
> > That's needed, yes.
>
> Could/should those be created by a postinst maintainer script of a package in
> the essential set? Maybe by the hurd package?
It used to be set by scripts but we can probably make the hurd postinst
create them, yes. But is the hurd postinst actually run in your case?
> > > /usr/libexec/runsystem.hurd: line 129: /usr/libexec/rc: No such file
> >
> > Not sure how your system looks like exactly. One issue we have is that
> > the debian-kosher way to run things is not the same as the hurd upstream
> > way to run things. Normally what happens is:
> >
> > startup/startup.c's `tries' array starts with LIBEXECDIR "/runsystem",
> > i.e. /usr/libexec/runsystem, which symlinks to /etc/hurd/runsystem,
> > which symlinks to /etc/alternatives/runsystem, which symlinks to
> > /etc/hurd/runsystem.sysv, which doesn't look at /usr/libexec/rc at all.
> > All of this is supposed to be shipped by the hurd package, either from
> > the tarball or as an alternative, not sure why (I guess) your alternative is
> > not being set?
>
> The symlink chain is this one:
>
> /usr/libexec/runsystem -> /etc/hurd/runsystem -> /alternatives/runsystem -> /etc/hurd/runsystem.gnu
>
> Should that last one be linking to /etc/hurd/runsystem.sysv?
Yes, I don't see why it's not doing that, isn't the alternative like
this?
Selection Path Priority Status
------------------------------------------------------------
* 0 /etc/hurd/runsystem.sysv 10 auto mode
1 /etc/hurd/runsystem.gnu 5 manual mode
2 /etc/hurd/runsystem.sysv 10 manual mode
> If I do that I get:
>
> /usr/libexec/runsystem.hurd: 117: Pipe call failed
You are probably also missing /servers/socket/1
> My final goal is to have debvm-run (which is just a wrapper around mmdebstrap)
> create a disk image that can be run with debvm-run (which is just a wrapper
> around qemu). I think it would be really cool if in Hurd-related bug reports
> one could just say "to reproduce this hurd problem locally, just run this".
Yes, clearly (though we have already been providing hurd qemu images for
a long time without that many people actually using the recommended
qemu-based way to start them...)
> I'm probably missing more customizations to make this work. Where else other
> than in debootstrap should I look? Maybe the Debian installer is doing
> something funny? Maybe there is a hurd-specific udeb that does some setup?
There shouldn't be much more left than the /servers/socket/1 piece.
Samuel
Reply to: