[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-08 00:13:57)
> > 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?

yes, remember how in one of my last mails I ran into an error because the hurd
preinst was missing a check for [ -z "$DPKG_ROOT" ]. In chrootless mode,
maintainer scripts are run but without a chroot call, so the tools from the
outside are used to process the scripts and the $DPKG_ROOT tells the tools what
to do. So either the preinst or the postinst could gain a snippet like this:

mkdir -p "$DPKG_ROOT/servers" "$DPKG_ROOT/dev"
for f in /servers/exec /servers/startup /dev/console; do
	touch "$DPKG_ROOT/$f"
done

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

Since I cannot boot into this system, I'm afraid I cannot run
update-alternatives to get output like the above. :)

But here is my /var/lib/dpkg/alternatives/runsystem:

auto
/etc/hurd/runsystem
halt
/sbin/halt
poweroff
/sbin/poweroff
reboot
/sbin/reboot

/etc/hurd/runsystem.gnu
5
/sbin/halt-hurd
/sbin/poweroff-hurd
/sbin/reboot-hurd

So this is missing entries for /etc/hurd/runsystem.sysv. The hurd.postinst only
sets up the entry for runsystem.gnu at priority 5. So I looked at the
initscripts.postinst from sysvinit and that one also calls "uname" :D

I'll have to go through the postinst scripts of the essential packages and find
out who calls uname and then send patches. Until then I can hack around it.

> > If I do that I get:
> > 
> > /usr/libexec/runsystem.hurd: 117: Pipe call failed
> 
> You are probably also missing /servers/socket/1

No, I have that. Check here:

$ curl --silent https://people.debian.org/~josch/hurd.tar.xz | unxz | tar tv | grep /servers/socket/
drwxr-xr-x root/root         0 2024-02-07 17:12 ./servers/socket/
-rw-r--r-- root/root         0 2024-02-07 17:12 ./servers/socket/1

I checked what should be in there according to exodar.debian.net and also
created the remaining entries manually, so now I have:

$ ls -lha /mnt/servers/socket/
total 8.0K
drwxr-xr-x 2 root root 4.0K Feb  8 07:49 .
drwxr-xr-x 3 root root 4.0K Feb  7 17:12 ..
-rw-r--r-- 1 root root    0 Feb  7 17:12 1
-rw-r--r-- 1 root root    0 Feb  8 07:49 2
-rw-r--r-- 1 root root    0 Feb  8 07:49 26
lrwxrwxrwx 1 root root    1 Feb  8 07:49 inet -> 2
lrwxrwxrwx 1 root root    2 Feb  8 07:49 inet6 -> 26
lrwxrwxrwx 1 root root    1 Feb  8 07:49 local -> 1

But the problem remains the same.

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

But now think about this: if support for this is in debvm and then autopkgtest
has debvm support, then you can build hurd packages on linux using sbuild's
autopkgtest backend or more directly via sbuild-qemu. That would be super cool,
no?  :D

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

I hope you have another theory!

Thank you so much for your help!! :)

cheers, josch

Attachment: signature.asc
Description: signature


Reply to: