[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode



Hi,

Quoting Samuel Thibault (2024-02-07 23:32:34)
> > And in unshare mode, uname -s prints "Linux" because I'm running this on
> > linux.  Do you happen to know what this conditional is for on non-linux
> > systems?
> util-linux doesn't seem to ship /bin/more on non-linux.  Upstream indeed
> added UL_REQUIRES_LINUX([more]) since the addition of using signalfd, which
> is Linuxish.

oooh that makes sense. Thank you!

> > 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? Then debootstrap could drop this
special-casing.

> > /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?

If I do that I get:

/usr/libexec/runsystem.hurd: 117: Pipe call failed

I created a tarball of my system and put it here:

https://people.debian.org/~josch/hurd.tar.xz

You can (mostly, minus the adjustments I mentioned above) recreate it by
running this:

mmdebstrap --variant=apt --include=passwd,debian-ports-archive-keyring,mmdebstrap,sysvinit-core,sysv-rc \
    --chrooted-customize-hook='echo "#!/bin/sh\necho Dummy" > /bin/uname' \
    --customize-hook='chroot "$1" mmdebstrap \
                --mode=chrootless --arch=hurd-i386 \
                --hook-dir=/usr/share/mmdebstrap/hooks/merged-usr \
                --include=sysvinit-core,sysv-rc,passwd,gnumach-image-1-486 --variant=apt unstable /tmp/chroot.tar \
                "deb http://ftp.ports.debian.org/debian-ports/ unstable main" \
                "deb http://ftp.ports.debian.org/debian-ports/ unreleased main"' \
    --customize-hook='copy-out /tmp/chroot.tar .' \
    unstable /dev/null

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".

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?

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature


Reply to: