info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
creating Hurd chroots on Linux using DPKG_ROOT chrootless mode
2 views
Skip to first unread message
Johannes Schauer Marin Rodrigues
Nov 18, 2023, 5:10:05 AM11/18/23
to
Hi werdahias,
I hope you are the same person who recently asked in #debian-devel about using
mmdebstrap to create a Hurd chroot? If not, please ignore this mail.
I'm putting debia...@lists.debian.org into CC for this mail as what I'm
writing here might be interesting for a wider audience.
The most important thing first: the mmdebstrap chrootless mode is called like
that because it runs all utilities without wrapping them in chroot(). This
means you must never run this mode as root or otherwise, packages that do not
yet have DPKG_ROOT support will modify the system you are running this on. If
you want to use chrootless mode, either do not run it as root or, even better,
run it in a throwaway chroot.
Indeed you want the chrootless mode because even with QEMU emulation you cannot
execute Hurd binaries on Linux. So instead, to create your Hurd chroot, you
want to run binaries from outside the chroot but let them operate on the
chroot. This is what dpkg --force-script-chrootless or chrootless mode is for.
It sets the $DPKG_ROOT environment variable so that maintainer scripts know
that they are not run on a real system or inside a chroot but instead the
chroot directory is located in a path pointed to by the $DPKG_ROOT environment
variable.
Support for this is already in all packages in the essential set, in apt,
systemd and build-essential in bookworm. One problem is, that so far, we only
added support to systemd-sys as a provider of "init" but on Hurd you don't have
systemd. I now have prepared patches for init-system-helpers, insserv and
sysvinit to make this work:
https://salsa.debian.org/helmutg/dpkg-root-demo/-/tree/sysvinit/patches
I submitted bug #1056176 to insserv for review already.
But even with those patches there is another blocker. The hurd package throws
the following error in its preinst maintainer script:
ERROR: This version of the GNU Hurd requires kernel version
1.8+git20210923 or later.
Please upgrade your kernel and reboot before installing hurd.
So the hurd package must be patched so that this check is not done if
$DPKG_ROOT is a non-empty string. Can you take care of preparing that patch and
testing it?
The second problem is, that foreign architecture chrootless mode is currently
blocked on a dpkg bug which prevents installation of Architecture:all packages
that depend on Architecture:any packages. This is because dpkg implicitly
considers Architecture:all packages to be of the same architecture as itself
and that cannot yet be configured to be otherwise. One example for such a
dependency is the dependency of the initscripts package on "sysv-rc | file-rc |
openrc" which are all Architecture:any. The relevant dpkg bugs are #825385 and
#1020533.
Since usrmerge also does not work with chrootless mode, it would also be
tremendously helpful to have the usrmerge transition finished that Helmut is
currently working on. Until then, please use this when calling mmdebstrap to
prevent usrmerge to try operate on your system outside the chroot:
--hook-dir=/usr/share/mmdebstrap/hooks/merged-usr
If you have any questions, please don't hesitate to contact me.
Thanks!
cheers, josch
I hope you are the same person who recently asked in #debian-devel about using
mmdebstrap to create a Hurd chroot? If not, please ignore this mail.
I'm putting debia...@lists.debian.org into CC for this mail as what I'm
writing here might be interesting for a wider audience.
The most important thing first: the mmdebstrap chrootless mode is called like
that because it runs all utilities without wrapping them in chroot(). This
means you must never run this mode as root or otherwise, packages that do not
yet have DPKG_ROOT support will modify the system you are running this on. If
you want to use chrootless mode, either do not run it as root or, even better,
run it in a throwaway chroot.
Indeed you want the chrootless mode because even with QEMU emulation you cannot
execute Hurd binaries on Linux. So instead, to create your Hurd chroot, you
want to run binaries from outside the chroot but let them operate on the
chroot. This is what dpkg --force-script-chrootless or chrootless mode is for.
It sets the $DPKG_ROOT environment variable so that maintainer scripts know
that they are not run on a real system or inside a chroot but instead the
chroot directory is located in a path pointed to by the $DPKG_ROOT environment
variable.
Support for this is already in all packages in the essential set, in apt,
systemd and build-essential in bookworm. One problem is, that so far, we only
added support to systemd-sys as a provider of "init" but on Hurd you don't have
systemd. I now have prepared patches for init-system-helpers, insserv and
sysvinit to make this work:
https://salsa.debian.org/helmutg/dpkg-root-demo/-/tree/sysvinit/patches
I submitted bug #1056176 to insserv for review already.
But even with those patches there is another blocker. The hurd package throws
the following error in its preinst maintainer script:
ERROR: This version of the GNU Hurd requires kernel version
1.8+git20210923 or later.
Please upgrade your kernel and reboot before installing hurd.
So the hurd package must be patched so that this check is not done if
$DPKG_ROOT is a non-empty string. Can you take care of preparing that patch and
testing it?
The second problem is, that foreign architecture chrootless mode is currently
blocked on a dpkg bug which prevents installation of Architecture:all packages
that depend on Architecture:any packages. This is because dpkg implicitly
considers Architecture:all packages to be of the same architecture as itself
and that cannot yet be configured to be otherwise. One example for such a
dependency is the dependency of the initscripts package on "sysv-rc | file-rc |
openrc" which are all Architecture:any. The relevant dpkg bugs are #825385 and
#1020533.
Since usrmerge also does not work with chrootless mode, it would also be
tremendously helpful to have the usrmerge transition finished that Helmut is
currently working on. Until then, please use this when calling mmdebstrap to
prevent usrmerge to try operate on your system outside the chroot:
--hook-dir=/usr/share/mmdebstrap/hooks/merged-usr
If you have any questions, please don't hesitate to contact me.
Thanks!
cheers, josch
Samuel Thibault
Nov 18, 2023, 5:40:04 AM11/18/23
to
Hello,
Johannes Schauer Marin Rodrigues, le sam. 18 nov. 2023 11:04:06 +0100, a ecrit:
cross-execution :)
I have commited the attached (untested) patch to the debian hurd repo.
Samuel
Johannes Schauer Marin Rodrigues, le sam. 18 nov. 2023 11:04:06 +0100, a ecrit:
> But even with those patches there is another blocker. The hurd package throws
> the following error in its preinst maintainer script:
>
> ERROR: This version of the GNU Hurd requires kernel version
> 1.8+git20210923 or later.
> Please upgrade your kernel and reboot before installing hurd.
>
> So the hurd package must be patched so that this check is not done if
> $DPKG_ROOT is a non-empty string. Can you take care of preparing that patch and
> testing it?
Oh, indeed, that's an OS-specific thing that shouldn't be done on
> the following error in its preinst maintainer script:
>
> ERROR: This version of the GNU Hurd requires kernel version
> 1.8+git20210923 or later.
> Please upgrade your kernel and reboot before installing hurd.
>
> So the hurd package must be patched so that this check is not done if
> $DPKG_ROOT is a non-empty string. Can you take care of preparing that patch and
> testing it?
cross-execution :)
I have commited the attached (untested) patch to the debian hurd repo.
Samuel
Johannes Schauer Marin Rodrigues
Nov 19, 2023, 1:50:05 AM11/19/23
to
Hi,
Quoting Johannes Schauer Marin Rodrigues (2023-11-18 11:04:06)
> But even with those patches there is another blocker. The hurd package throws
> the following error in its preinst maintainer script:
This is fixed in git already.
> The second problem is, that foreign architecture chrootless mode is currently
> blocked on a dpkg bug which prevents installation of Architecture:all
> packages that depend on Architecture:any packages.
Guillem also now fixed this in git and I already verified that the patch works:
https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/chroot-arch
The last patch I have is against init-system-helpers but I'm waiting with that
one until #1056176 for insserv has been applied because it uses the same
insserv options and I want to make sure with the insserv maintainers that those
options are indeed all as they should be set.
So we might just be very close to creating unprivileged, bit-by-bit
reproducible Hurd chroots from Linux. Though since Hurd binaries cannot run on
Linux, this is of course of limited usefulness. But mmdebstrap can also create
ext4 disk images so I was wondering whether it might be possible to teach debvm
how to boot gnumach.
So I downloaded
https://cdimage.debian.org/cdimage/ports/stable/hurd-i386/debian-hurd.img.tar.gz
and extracted /boot/gnumach-1.8-486.gz from it. I tried the following but it
seems to get stuck and only prints "Booting from ROM...":
qemu-system-i386 \
-m 1G \
-kernel gnumach-1.8-486.gz \
-append root=device:hd0s2 \
-drive file=debian-hurd-20210812.img,format=raw
What am I missing so that I can boot Hurd using qemu without grub?
Thanks!
cheers, josch
Quoting Johannes Schauer Marin Rodrigues (2023-11-18 11:04:06)
> I submitted bug #1056176 to insserv for review already.
now there is also #1056213 against sysvinit.
> But even with those patches there is another blocker. The hurd package throws
> the following error in its preinst maintainer script:
> The second problem is, that foreign architecture chrootless mode is currently
> blocked on a dpkg bug which prevents installation of Architecture:all
> packages that depend on Architecture:any packages.
https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/chroot-arch
The last patch I have is against init-system-helpers but I'm waiting with that
one until #1056176 for insserv has been applied because it uses the same
insserv options and I want to make sure with the insserv maintainers that those
options are indeed all as they should be set.
So we might just be very close to creating unprivileged, bit-by-bit
reproducible Hurd chroots from Linux. Though since Hurd binaries cannot run on
Linux, this is of course of limited usefulness. But mmdebstrap can also create
ext4 disk images so I was wondering whether it might be possible to teach debvm
how to boot gnumach.
So I downloaded
https://cdimage.debian.org/cdimage/ports/stable/hurd-i386/debian-hurd.img.tar.gz
and extracted /boot/gnumach-1.8-486.gz from it. I tried the following but it
seems to get stuck and only prints "Booting from ROM...":
qemu-system-i386 \
-m 1G \
-kernel gnumach-1.8-486.gz \
-append root=device:hd0s2 \
-drive file=debian-hurd-20210812.img,format=raw
What am I missing so that I can boot Hurd using qemu without grub?
Thanks!
cheers, josch
Samuel Thibault
Nov 19, 2023, 4:20:05 AM11/19/23
to
Hello,
Johannes Schauer Marin Rodrigues, le dim. 19 nov. 2023 07:45:16 +0100, a ecrit:
- qemu doesn't seem to properly detect gzipped files, so you need to
gunzip gnumach first
- apparently, booting gnumach with qemu-system-i386 broke at some point
without -enable-kvm, so it is needed (and recommended anyway for
speed), or qemu-system-x86_64
- gnumach itself doesn't contain any ext2fs driver or anything to load
binaries, so this needs to be loaded like grub would. You can fetch
/hurd/ext2fs.static and /hurd/exec.static from the image (e.g. into
/tmp), and add:
--initrd '/tmp/ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed ${root} $(task-create) $(task-resume),/tmp/exec.static $(exec-task=task-create)'
So in the end this works for me:
qemu-system-i386 -enable-kvm -m 1G \
-kernel /tmp/gnumach-1.8-486 \
-append root=device:hd0s2 \
--initrd '/tmp/ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed ${root} $(task-create) $(task-resume),/tmp/exec.static $(exec-task=task-create)' \
-drive file=debian-hurd-20210812.img,format=raw
Samuel
Johannes Schauer Marin Rodrigues, le dim. 19 nov. 2023 07:45:16 +0100, a ecrit:
> So I downloaded
> https://cdimage.debian.org/cdimage/ports/stable/hurd-i386/debian-hurd.img.tar.gz
> and extracted /boot/gnumach-1.8-486.gz from it. I tried the following but it
> seems to get stuck and only prints "Booting from ROM...":
>
> qemu-system-i386 \
> -m 1G \
> -kernel gnumach-1.8-486.gz \
> -append root=device:hd0s2 \
> -drive file=debian-hurd-20210812.img,format=raw
>
> What am I missing so that I can boot Hurd using qemu without grub?
Various things :)
> https://cdimage.debian.org/cdimage/ports/stable/hurd-i386/debian-hurd.img.tar.gz
> and extracted /boot/gnumach-1.8-486.gz from it. I tried the following but it
> seems to get stuck and only prints "Booting from ROM...":
>
> qemu-system-i386 \
> -m 1G \
> -kernel gnumach-1.8-486.gz \
> -append root=device:hd0s2 \
> -drive file=debian-hurd-20210812.img,format=raw
>
> What am I missing so that I can boot Hurd using qemu without grub?
- qemu doesn't seem to properly detect gzipped files, so you need to
gunzip gnumach first
- apparently, booting gnumach with qemu-system-i386 broke at some point
without -enable-kvm, so it is needed (and recommended anyway for
speed), or qemu-system-x86_64
- gnumach itself doesn't contain any ext2fs driver or anything to load
binaries, so this needs to be loaded like grub would. You can fetch
/hurd/ext2fs.static and /hurd/exec.static from the image (e.g. into
/tmp), and add:
--initrd '/tmp/ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed ${root} $(task-create) $(task-resume),/tmp/exec.static $(exec-task=task-create)'
So in the end this works for me:
qemu-system-i386 -enable-kvm -m 1G \
-kernel /tmp/gnumach-1.8-486 \
-append root=device:hd0s2 \
--initrd '/tmp/ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed ${root} $(task-create) $(task-resume),/tmp/exec.static $(exec-task=task-create)' \
-drive file=debian-hurd-20210812.img,format=raw
Samuel
Johannes Schauer Marin Rodrigues
Nov 19, 2023, 6:00:06 AM11/19/23
to
Hi,
Quoting Samuel Thibault (2023-11-19 10:10:06)
kvm for x86 anyways. :)
As a result emulation slowness I get messages like
Timeout reached while waiting for return value
/bin/console: Could not receive return value from daemon process: Connection timed out
> - gnumach itself doesn't contain any ext2fs driver or anything to load
> binaries, so this needs to be loaded like grub would. You can fetch
> /hurd/ext2fs.static and /hurd/exec.static from the image (e.g. into
> /tmp), and add:
>
> --initrd '/tmp/ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed ${root} $(task-create) $(task-resume),/tmp/exec.static $(exec-task=task-create)'
>
> So in the end this works for me:
>
> qemu-system-i386 -enable-kvm -m 1G \
> -kernel /tmp/gnumach-1.8-486 \
> -append root=device:hd0s2 \
> --initrd '/tmp/ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed ${root} $(task-create) $(task-resume),/tmp/exec.static $(exec-task=task-create)' \
> -drive file=debian-hurd-20210812.img,format=raw
Debian GNU/Hurd 11 debian console
login:
Nice! That was it, thank you!! :D
Would you also have handy what argument I'd have to pass to connect the serial
terminal with the login tty to QEMU's serial device so that I can run this
without graphic mode?
The command above and the advice to extract ext2fs.static and exec.static
should be put on some wiki page, I think.
Thanks a lot! :)
cheers, josch
Quoting Samuel Thibault (2023-11-19 10:10:06)
> Johannes Schauer Marin Rodrigues, le dim. 19 nov. 2023 07:45:16 +0100, a ecrit:
> > What am I missing so that I can boot Hurd using qemu without grub?
> - qemu doesn't seem to properly detect gzipped files, so you need to
> gunzip gnumach first
>
> - apparently, booting gnumach with qemu-system-i386 broke at some point
> without -enable-kvm, so it is needed (and recommended anyway for
> speed), or qemu-system-x86_64
well... I'm on an arm64 laptop (MNT Reform 2 with imx8mq) so I don't have any
> gunzip gnumach first
>
> - apparently, booting gnumach with qemu-system-i386 broke at some point
> without -enable-kvm, so it is needed (and recommended anyway for
> speed), or qemu-system-x86_64
kvm for x86 anyways. :)
As a result emulation slowness I get messages like
Timeout reached while waiting for return value
/bin/console: Could not receive return value from daemon process: Connection timed out
> - gnumach itself doesn't contain any ext2fs driver or anything to load
> binaries, so this needs to be loaded like grub would. You can fetch
> /hurd/ext2fs.static and /hurd/exec.static from the image (e.g. into
> /tmp), and add:
>
> --initrd '/tmp/ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed ${root} $(task-create) $(task-resume),/tmp/exec.static $(exec-task=task-create)'
>
> So in the end this works for me:
>
> qemu-system-i386 -enable-kvm -m 1G \
> -kernel /tmp/gnumach-1.8-486 \
> -append root=device:hd0s2 \
> --initrd '/tmp/ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed ${root} $(task-create) $(task-resume),/tmp/exec.static $(exec-task=task-create)' \
> -drive file=debian-hurd-20210812.img,format=raw
login:
Nice! That was it, thank you!! :D
Would you also have handy what argument I'd have to pass to connect the serial
terminal with the login tty to QEMU's serial device so that I can run this
without graphic mode?
The command above and the advice to extract ext2fs.static and exec.static
should be put on some wiki page, I think.
Thanks a lot! :)
cheers, josch
Samuel Thibault
Nov 19, 2023, 7:10:04 AM11/19/23
to
Johannes Schauer Marin Rodrigues, le dim. 19 nov. 2023 11:57:07 +0100, a ecrit:
Samuel
> Would you also have handy what argument I'd have to pass to connect the serial
> terminal with the login tty to QEMU's serial device so that I can run this
> without graphic mode?
You can add in -append: console=com0
> terminal with the login tty to QEMU's serial device so that I can run this
> without graphic mode?
Samuel
Samuel Thibault
Nov 19, 2023, 7:20:05 AM11/19/23
to
Johannes Schauer Marin Rodrigues, le dim. 19 nov. 2023 11:57:07 +0100, a ecrit:
> The command above and the advice to extract ext2fs.static and exec.static
> should be put on some wiki page, I think.
It's the eternal problem with documentation: sometimes it doesn't even
> should be put on some wiki page, I think.
exist, sometimes people don't find it. I have now added more keywords.
https://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#index8h1
Samuel
Johannes Schauer Marin Rodrigues
Nov 23, 2023, 3:40:04 PM11/23/23
to
Quoting Samuel Thibault (2023-11-19 13:14:48)
Uff... I indeed did not come across that URL during my searches prior to
writing my initial mail. I now added it to my notes so that future-me will
hopefully be a bit wiser.
In the meantime, init-system-helpers (#1056391) and insserv (#1056176) have my
DPKG_ROOT patch pending for the next upload. You already fixed the hurd
package. This means only sysvinit (#1056391) is left -- in case any of you has
some good connections to the sysvinit maintainers. :)
Once everything (including the dpkg patch) is in unstable, I'll message you
again about the progress.
Thanks!
cheers, josch
writing my initial mail. I now added it to my notes so that future-me will
hopefully be a bit wiser.
In the meantime, init-system-helpers (#1056391) and insserv (#1056176) have my
DPKG_ROOT patch pending for the next upload. You already fixed the hurd
package. This means only sysvinit (#1056391) is left -- in case any of you has
some good connections to the sysvinit maintainers. :)
Once everything (including the dpkg patch) is in unstable, I'll message you
again about the progress.
Thanks!
cheers, josch
Johannes Schauer Marin Rodrigues
Nov 24, 2023, 6:20:05 PM11/24/23
to
Hi,
Quoting Matthias Geiger (2023-11-24 23:56:11)
> I see. I was merely wondering if there was an easy way to test hurd builds
> locally without having to run a VM,
chrootless mode is for creating chroots for architectures that do not (yet)
have qemu user mode emulation support. This is usually the case for
architectures that are being bootstrapped as in the early days, there is no
qemu support available and/or the available emulators are unusably slow. But if
you look at it from the perspective of our linux architectures, then hurd is an
architecture that is permanently without qemu user mode emulation support.
If you want to compile software, then ideally, no binaries of the host
architecture (the architecture you are building for) are being run. So if you
just want to build hurd software (and not run it) then all you need is "just" a
cross compiler for hurd (should be named gcc-i686-gnu) but I'm not aware of
that being worked on right now?
> guess I went down another rabbithole :)
If you want to have a chroot, then I don't think the rabbit hole is that deep.
Only sysvinit patches need to get applied and things should just magically
start working with chrootless mode.
> Unfortunately I am pretty busy until Christmas so I can't test anything. For
> now I'll upload revisions to see if that mitigates the build failure, but
> that's not ideal.
But then even once you have a chroot, that doesn't give you much unless you
want to turn that into a bootable disk image. I'm writing debvm patches to get
this done but then you are again inside a qemu virtual machine that you booted.
Just that this machine was created entirely without superuser privileges and is
bit-by-bit reproducible if we wait a bit more.
Thanks!
cheers, josch
Quoting Matthias Geiger (2023-11-24 23:56:11)
> I see. I was merely wondering if there was an easy way to test hurd builds
> locally without having to run a VM,
chrootless mode is for creating chroots for architectures that do not (yet)
have qemu user mode emulation support. This is usually the case for
architectures that are being bootstrapped as in the early days, there is no
qemu support available and/or the available emulators are unusably slow. But if
you look at it from the perspective of our linux architectures, then hurd is an
architecture that is permanently without qemu user mode emulation support.
If you want to compile software, then ideally, no binaries of the host
architecture (the architecture you are building for) are being run. So if you
just want to build hurd software (and not run it) then all you need is "just" a
cross compiler for hurd (should be named gcc-i686-gnu) but I'm not aware of
that being worked on right now?
> guess I went down another rabbithole :)
If you want to have a chroot, then I don't think the rabbit hole is that deep.
Only sysvinit patches need to get applied and things should just magically
start working with chrootless mode.
> Unfortunately I am pretty busy until Christmas so I can't test anything. For
> now I'll upload revisions to see if that mitigates the build failure, but
> that's not ideal.
But then even once you have a chroot, that doesn't give you much unless you
want to turn that into a bootable disk image. I'm writing debvm patches to get
this done but then you are again inside a qemu virtual machine that you booted.
Just that this machine was created entirely without superuser privileges and is
bit-by-bit reproducible if we wait a bit more.
Thanks!
cheers, josch
Samuel Thibault
Dec 29, 2023, 4:10:04 PM12/29/23
to
Hello,
Johannes Schauer Marin Rodrigues, le sam. 25 nov. 2023 00:17:35 +0100, a ecrit:
Samuel
Johannes Schauer Marin Rodrigues, le sam. 25 nov. 2023 00:17:35 +0100, a ecrit:
> Quoting Matthias Geiger (2023-11-24 23:56:11)
> > I see. I was merely wondering if there was an easy way to test hurd builds
> > locally without having to run a VM,
>
> > I see. I was merely wondering if there was an easy way to test hurd builds
> > locally without having to run a VM,
>
> If you want to compile software, then ideally, no binaries of the host
> architecture (the architecture you are building for) are being run. So if you
> just want to build hurd software (and not run it) then all you need is "just" a
> cross compiler for hurd (should be named gcc-i686-gnu) but I'm not aware of
> that being worked on right now?
Indeed. The rebootstrap scripts build one, though.
> architecture (the architecture you are building for) are being run. So if you
> just want to build hurd software (and not run it) then all you need is "just" a
> cross compiler for hurd (should be named gcc-i686-gnu) but I'm not aware of
> that being worked on right now?
Samuel
Johannes Schauer Marin Rodrigues
Jan 10, 2024, 6:20:04 PMJan 10
to
(Please continue to CC me as I'm not subscribed)
Hi,
Quoting Johannes Schauer Marin Rodrigues (2023-11-19 07:45:16)
further on creating Hurd chroots on Linux using dpkg --force-script-chrootless.
My next blocker is less. It says in the log:
Setting up less:hurd-i386 (487-0.1+b1) ...
ln: failed to create symbolic link '/usr/bin/lessfile': File exists
dpkg: error processing package less:hurd-i386 (--install):
installed less:hurd-i386 package post-installation script subprocess returned error exit status 1
[...]
Setting up util-linux:hurd-i386 (2.39.3-6) ...
update-alternatives: error: alternative path /tmp/chroot/bin/more doesn't exist
dpkg: error processing package util-linux:hurd-i386 (--install):
installed util-linux:hurd-i386 package post-installation script subprocess returned error exit status 2
The util-linux problem is no surprise because less fails to install when
investigating that issue I noticed the version of less is 487 which is the
version from old-old-stable. Is that plausible? Maybe I'm missing a mirror in
my setup? Currently, I'm running this:
mmdebstrap --variant=apt \
--include=passwd,debian-ports-archive-keyring,mmdebstrap,sysvinit-core,sysv-rc \
--customize-hook='chroot "$1" mmdebstrap \
--mode=chrootless --arch=hurd-i386 \
--hook-dir=/usr/share/mmdebstrap/hooks/merged-usr \
--include=sysvinit-core,sysv-rc,passwd --variant=apt unstable /tmp/chroot \
"deb http://ftp.ports.debian.org/debian-ports/ unstable main" \
"deb http://ftp.ports.debian.org/debian-ports/ unreleased main"' \
unstable /dev/null
Do I need a different set of mirrors? How would I get the latest version of
less on Hurd?
Thanks!
cheers, josch
Hi,
Quoting Johannes Schauer Marin Rodrigues (2023-11-19 07:45:16)
> The last patch I have is against init-system-helpers but I'm waiting with
> that one until #1056176 for insserv has been applied because it uses the same
> insserv options and I want to make sure with the insserv maintainers that
> those options are indeed all as they should be set.
>
> So we might just be very close to creating unprivileged, bit-by-bit
> reproducible Hurd chroots from Linux.
bug #1056176 got fixed earlier today and with it the last blocker to get a bit
> that one until #1056176 for insserv has been applied because it uses the same
> insserv options and I want to make sure with the insserv maintainers that
> those options are indeed all as they should be set.
>
> So we might just be very close to creating unprivileged, bit-by-bit
> reproducible Hurd chroots from Linux.
further on creating Hurd chroots on Linux using dpkg --force-script-chrootless.
My next blocker is less. It says in the log:
Setting up less:hurd-i386 (487-0.1+b1) ...
ln: failed to create symbolic link '/usr/bin/lessfile': File exists
dpkg: error processing package less:hurd-i386 (--install):
installed less:hurd-i386 package post-installation script subprocess returned error exit status 1
[...]
Setting up util-linux:hurd-i386 (2.39.3-6) ...
update-alternatives: error: alternative path /tmp/chroot/bin/more doesn't exist
dpkg: error processing package util-linux:hurd-i386 (--install):
installed util-linux:hurd-i386 package post-installation script subprocess returned error exit status 2
The util-linux problem is no surprise because less fails to install when
investigating that issue I noticed the version of less is 487 which is the
version from old-old-stable. Is that plausible? Maybe I'm missing a mirror in
my setup? Currently, I'm running this:
mmdebstrap --variant=apt \
--include=passwd,debian-ports-archive-keyring,mmdebstrap,sysvinit-core,sysv-rc \
--customize-hook='chroot "$1" mmdebstrap \
--mode=chrootless --arch=hurd-i386 \
--hook-dir=/usr/share/mmdebstrap/hooks/merged-usr \
--include=sysvinit-core,sysv-rc,passwd --variant=apt unstable /tmp/chroot \
"deb http://ftp.ports.debian.org/debian-ports/ unstable main" \
"deb http://ftp.ports.debian.org/debian-ports/ unreleased main"' \
unstable /dev/null
Do I need a different set of mirrors? How would I get the latest version of
less on Hurd?
Thanks!
cheers, josch
Samuel Thibault
Jan 10, 2024, 6:30:04 PMJan 10
to
Hello,
Johannes Schauer Marin Rodrigues, le jeu. 11 janv. 2024 00:12:09 +0100, a ecrit:
waiting for somebody to contribute a fix, see
https://buildd.debian.org/status/logs.php?pkg=less&arch=hurd-i386
Samuel
Johannes Schauer Marin Rodrigues, le jeu. 11 janv. 2024 00:12:09 +0100, a ecrit:
> The util-linux problem is no surprise because less fails to install when
> investigating that issue I noticed the version of less is 487 which is the
> version from old-old-stable. Is that plausible?
It has been failing to build for a long time already and is still
> investigating that issue I noticed the version of less is 487 which is the
> version from old-old-stable. Is that plausible?
waiting for somebody to contribute a fix, see
https://buildd.debian.org/status/logs.php?pkg=less&arch=hurd-i386
Samuel
Guillem Jover
Jan 10, 2024, 6:40:04 PMJan 10
to
Hi!
I looked into it and it seemed trivial, so I've got a patch I'm
polishing now and will submit today.
Thanks,
Guillem
polishing now and will submit today.
Thanks,
Guillem
Johannes Schauer Marin Rodrigues
Jan 11, 2024, 7:00:03 PMJan 11
to
Hi,
Quoting Guillem Jover (2024-01-11 00:32:50)
thank you, Guillem! I subscribed to #1060420 as well as the upstream bug to
make sure I get notified once this gets fixed.
since in chrootless mode, maintainer scripts run tools from the outside, it is
most useful if the version of the tools on the inside is as close as possible
(best equal) to the version of the tools on the outside. To find out if there
are other cases similar to less, I wrote a new mmdebstrap hook which will be
part of the next mmdebstrap release. Here is its current output for when
creating a Hurd chroot:
W: libc0.3 is not installed on the outside
W: version of coreutils differs 9.4-3 (outside) -> 9.1-1 (inside)
W: version of libbz2-1.0 differs 1.0.8-5+b2 (outside) -> 1.0.8-5+b1 (inside)
W: hurd-libs0.3 is not installed on the outside
W: version of tar differs 1.35+dfsg-2 (outside) -> 1.34+dfsg-1.4 (inside)
W: version of diffutils differs 1:3.10-1 (outside) -> 1:3.7-5 (inside)
W: version of grep differs 3.11-4 (outside) -> 3.6-1 (inside)
W: version of startpar differs 0.65-1+b1 (outside) -> 0.65-1 (inside)
W: version of less differs 590-2 (outside) -> 487-0.1+b1 (inside)
W: version of libpam0g differs 1.5.2-9.1+b1 (outside) -> 1.4.0-10 (inside)
W: version of libdb5.3 differs 5.3.28+dfsg2-4+b1 (outside) -> 5.3.28+dfsg2-4 (inside)
W: version of libcom-err2 differs 1.47.0-2+b1 (outside) -> 1.46.6-1 (inside)
W: version of libkrb5support0 differs 1.20.1-5 (outside) -> 1.20.1-3 (inside)
W: version of libk5crypto3 differs 1.20.1-5 (outside) -> 1.20.1-3 (inside)
W: version of libkrb5-3 differs 1.20.1-5 (outside) -> 1.20.1-3 (inside)
W: version of libgssapi-krb5-2 differs 1.20.1-5 (outside) -> 1.20.1-3 (inside)
W: version of libpam-modules-bin differs 1.5.2-9.1+b1 (outside) -> 1.4.0-10 (inside)
W: version of libpam-modules differs 1.5.2-9.1+b1 (outside) -> 1.4.0-10 (inside)
W: version of passwd differs 1:4.13+dfsg1-3+b1 (outside) -> 1:4.13+dfsg1-3 (inside)
W: hurd is not installed on the outside
W: version of login differs 1:4.13+dfsg1-3+b1 (outside) -> 1:4.13+dfsg1-3 (inside)
W: version of gpgv differs 2.2.40-1.1+b1 (outside) -> 2.2.40-1.1+hurd.1 (inside)
W: version of liblz4-1 differs 1.9.4-1+b2 (outside) -> 1.9.4-1 (inside)
W: version of libidn2-0 differs 2.3.4-1+b2 (outside) -> 2.3.4-1+b1 (inside)
W: version of libtasn1-6 differs 4.19.0-3+b2 (outside) -> 4.19.0-3 (inside)
W: version of libgnutls30 differs 3.8.2-1 (outside) -> 3.8.1-4+b1 (inside)
I think the most gaping version differences are:
- coreutils: last successful build in 2022 and fails to configure now (might
be fixable by passing '--disable-year2038 to ./configure)
- pam: last successful build in 2021 and fails with "THIS CODE IS KNOWN TO
WORK ONLY ON LINUX" and "error: sys/prctl.h: No such file or directory"
- grep: last successful build in 2021 and fails its testsuite with "grep:
memory exhausted"
Of those three, only pam seems to have a patch (#1029097).
Thanks!
cheers, josch
Quoting Guillem Jover (2024-01-11 00:32:50)
make sure I get notified once this gets fixed.
since in chrootless mode, maintainer scripts run tools from the outside, it is
most useful if the version of the tools on the inside is as close as possible
(best equal) to the version of the tools on the outside. To find out if there
are other cases similar to less, I wrote a new mmdebstrap hook which will be
part of the next mmdebstrap release. Here is its current output for when
creating a Hurd chroot:
W: libc0.3 is not installed on the outside
W: version of coreutils differs 9.4-3 (outside) -> 9.1-1 (inside)
W: version of libbz2-1.0 differs 1.0.8-5+b2 (outside) -> 1.0.8-5+b1 (inside)
W: hurd-libs0.3 is not installed on the outside
W: version of tar differs 1.35+dfsg-2 (outside) -> 1.34+dfsg-1.4 (inside)
W: version of diffutils differs 1:3.10-1 (outside) -> 1:3.7-5 (inside)
W: version of grep differs 3.11-4 (outside) -> 3.6-1 (inside)
W: version of startpar differs 0.65-1+b1 (outside) -> 0.65-1 (inside)
W: version of less differs 590-2 (outside) -> 487-0.1+b1 (inside)
W: version of libpam0g differs 1.5.2-9.1+b1 (outside) -> 1.4.0-10 (inside)
W: version of libdb5.3 differs 5.3.28+dfsg2-4+b1 (outside) -> 5.3.28+dfsg2-4 (inside)
W: version of libcom-err2 differs 1.47.0-2+b1 (outside) -> 1.46.6-1 (inside)
W: version of libkrb5support0 differs 1.20.1-5 (outside) -> 1.20.1-3 (inside)
W: version of libk5crypto3 differs 1.20.1-5 (outside) -> 1.20.1-3 (inside)
W: version of libkrb5-3 differs 1.20.1-5 (outside) -> 1.20.1-3 (inside)
W: version of libgssapi-krb5-2 differs 1.20.1-5 (outside) -> 1.20.1-3 (inside)
W: version of libpam-modules-bin differs 1.5.2-9.1+b1 (outside) -> 1.4.0-10 (inside)
W: version of libpam-modules differs 1.5.2-9.1+b1 (outside) -> 1.4.0-10 (inside)
W: version of passwd differs 1:4.13+dfsg1-3+b1 (outside) -> 1:4.13+dfsg1-3 (inside)
W: hurd is not installed on the outside
W: version of login differs 1:4.13+dfsg1-3+b1 (outside) -> 1:4.13+dfsg1-3 (inside)
W: version of gpgv differs 2.2.40-1.1+b1 (outside) -> 2.2.40-1.1+hurd.1 (inside)
W: version of liblz4-1 differs 1.9.4-1+b2 (outside) -> 1.9.4-1 (inside)
W: version of libidn2-0 differs 2.3.4-1+b2 (outside) -> 2.3.4-1+b1 (inside)
W: version of libtasn1-6 differs 4.19.0-3+b2 (outside) -> 4.19.0-3 (inside)
W: version of libgnutls30 differs 3.8.2-1 (outside) -> 3.8.1-4+b1 (inside)
I think the most gaping version differences are:
- coreutils: last successful build in 2022 and fails to configure now (might
be fixable by passing '--disable-year2038 to ./configure)
- pam: last successful build in 2021 and fails with "THIS CODE IS KNOWN TO
WORK ONLY ON LINUX" and "error: sys/prctl.h: No such file or directory"
- grep: last successful build in 2021 and fails its testsuite with "grep:
memory exhausted"
Of those three, only pam seems to have a patch (#1029097).
Thanks!
cheers, josch
Johannes Schauer Marin Rodrigues
Feb 7, 2024, 12:10:04 PMFeb 7
to
Hi again,
Quoting Johannes Schauer Marin Rodrigues (2024-01-11 00:12:09)
which includes the fix of Guillem and the problem did not go away so I
investigated again. Turns out, the problematic bit of code is this one:
https://sources.debian.org/src/util-linux/2.39.3-6/debian/util-linux.postinst/#L4
if [ "$(uname -s)" = "Linux" ]; then
update-alternatives --install /usr/bin/pager pager /bin/more 50 \
--slave /usr/share/man/man1/pager.1.gz pager.1.gz \
/usr/share/man/man1/more.1.gz
fi
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?
Instead of calling uname, maintainerscripts could (and probably should) use
$DPKG_MAINTSCRIPT_ARCH.
So I hacked around that by replacing /bin/uname with a shell script that prints
something that is not "Linux". And then it works! I'm now stuck elsewhere. When
putting everything into a disk image and attempting to boot it, I get the
problem that was discussed here:
https://lists.debian.org/debian-hurd/2007/09/msg00073.html
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
The next error I'm getting is:
/usr/libexec/console-run: /dev/console: Not a terminal
/usr/libexec/runsystem.hurd: line 129: /usr/libexec/rc: No such file
I looked on exodar.debian.net and that file doesn't exist there either. What
does this error mean? What is the setup code I'm missing besides the few lines
in debootstrap itself?
Thanks!
cheers, josch
Quoting Johannes Schauer Marin Rodrigues (2024-01-11 00:12:09)
> The util-linux problem is no surprise because less fails to install when
> investigating that issue I noticed the version of less is 487 which is the
> version from old-old-stable. Is that plausible? Maybe I'm missing a mirror in
> my setup?
this turned out to be a red herring! There was a release of less yesterday
> investigating that issue I noticed the version of less is 487 which is the
> version from old-old-stable. Is that plausible? Maybe I'm missing a mirror in
> my setup?
which includes the fix of Guillem and the problem did not go away so I
investigated again. Turns out, the problematic bit of code is this one:
https://sources.debian.org/src/util-linux/2.39.3-6/debian/util-linux.postinst/#L4
if [ "$(uname -s)" = "Linux" ]; then
update-alternatives --install /usr/bin/pager pager /bin/more 50 \
--slave /usr/share/man/man1/pager.1.gz pager.1.gz \
/usr/share/man/man1/more.1.gz
fi
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?
Instead of calling uname, maintainerscripts could (and probably should) use
$DPKG_MAINTSCRIPT_ARCH.
So I hacked around that by replacing /bin/uname with a shell script that prints
something that is not "Linux". And then it works! I'm now stuck elsewhere. When
putting everything into a disk image and attempting to boot it, I get the
problem that was discussed here:
https://lists.debian.org/debian-hurd/2007/09/msg00073.html
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
The next error I'm getting is:
/usr/libexec/console-run: /dev/console: Not a terminal
/usr/libexec/runsystem.hurd: line 129: /usr/libexec/rc: No such file
I looked on exodar.debian.net and that file doesn't exist there either. What
does this error mean? What is the setup code I'm missing besides the few lines
in debootstrap itself?
Thanks!
cheers, josch
Samuel Thibault
Feb 7, 2024, 5:40:04 PMFeb 7
to
Hello,
Johannes Schauer Marin Rodrigues, le mer. 07 févr. 2024 18:07:21 +0100, a ecrit:
added UL_REQUIRES_LINUX([more]) since the addition of using signalfd,
which is Linuxish.
> So I hacked around that by replacing /bin/uname with a shell script that prints
> something that is not "Linux". And then it works! I'm now stuck elsewhere. When
> putting everything into a disk image and attempting to boot it, I get the
> problem that was discussed here:
>
> https://lists.debian.org/debian-hurd/2007/09/msg00073.html
>
> 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.
> The next error I'm getting is:
>
> /usr/libexec/console-run: /dev/console: Not a terminal
That one is just a warning.
> /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?
Samuel
Johannes Schauer Marin Rodrigues, le mer. 07 févr. 2024 18:07:21 +0100, a ecrit:
> if [ "$(uname -s)" = "Linux" ]; then
> update-alternatives --install /usr/bin/pager pager /bin/more 50 \
> --slave /usr/share/man/man1/pager.1.gz pager.1.gz \
> /usr/share/man/man1/more.1.gz
> fi
>
> 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
> update-alternatives --install /usr/bin/pager pager /bin/more 50 \
> --slave /usr/share/man/man1/pager.1.gz pager.1.gz \
> /usr/share/man/man1/more.1.gz
> fi
>
> 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?
added UL_REQUIRES_LINUX([more]) since the addition of using signalfd,
which is Linuxish.
> So I hacked around that by replacing /bin/uname with a shell script that prints
> something that is not "Linux". And then it works! I'm now stuck elsewhere. When
> putting everything into a disk image and attempting to boot it, I get the
> problem that was discussed here:
>
> https://lists.debian.org/debian-hurd/2007/09/msg00073.html
>
> 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
> The next error I'm getting is:
>
> /usr/libexec/console-run: /dev/console: Not a terminal
> /usr/libexec/runsystem.hurd: line 129: /usr/libexec/rc: No such file
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?
Samuel
Johannes Schauer Marin Rodrigues
Feb 7, 2024, 6:10:05 PMFeb 7
to
Hi,
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? 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
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
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!
> > 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.
> > 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.
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?
/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' \
mmdebstrap --variant=apt --include=passwd,debian-ports-archive-keyring,mmdebstrap,sysvinit-core,sysv-rc \
--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 \
--mode=chrootless --arch=hurd-i386 \
--hook-dir=/usr/share/mmdebstrap/hooks/merged-usr \
"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 .' \
"deb http://ftp.ports.debian.org/debian-ports/ unreleased main"' \
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
Samuel Thibault
Feb 7, 2024, 6:20:05 PMFeb 7
to
Johannes Schauer Marin Rodrigues, le jeu. 08 févr. 2024 00:04:25 +0100, a ecrit:
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
> 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
> > > /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?
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?
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
> 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".
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?
Samuel
Johannes Schauer Marin Rodrigues
Feb 8, 2024, 2:20:05 AMFeb 8
to
Hi,
Quoting Samuel Thibault (2024-02-08 00:13:57)
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
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
> > 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?
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
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
$ 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...)
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.
Thank you so much for your help!! :)
cheers, josch
Samuel Thibault
Feb 8, 2024, 4:40:04 AMFeb 8
to
Johannes Schauer Marin Rodrigues, le jeu. 08 févr. 2024 10:04:51 +0100, a ecrit:
>
> in_target /usr/lib/hurd/setup-translators -k
This cannot be done on Linux.
> settrans -a "$TARGET/dev" /hurd/firmlink /dev
> settrans -a "$TARGET/servers" /hurd/firmlink /servers
> settrans -a "$TARGET/proc" /hurd/firmlink /proc
This is only useful when running as chroot (think of it as the bind
mount that you'd do in Linux)
Samuel
> On 2024-02-08 00:13, Samuel Thibault wrote:
> > Johannes Schauer Marin Rodrigues, le jeu. 08 févr. 2024 00:04:25 +0100,
> > a ecrit:
> > Johannes Schauer Marin Rodrigues, le jeu. 08 févr. 2024 00:04:25 +0100,
> > a ecrit:
> > > 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.
>
> Maybe I found the missing bit. In debootstrap, there is:
> > > 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.
>
>
> in_target /usr/lib/hurd/setup-translators -k
This cannot be done on Linux.
> settrans -a "$TARGET/dev" /hurd/firmlink /dev
> settrans -a "$TARGET/servers" /hurd/firmlink /servers
> settrans -a "$TARGET/proc" /hurd/firmlink /proc
This is only useful when running as chroot (think of it as the bind
mount that you'd do in Linux)
Samuel
Johannes Schauer Marin Rodrigues
Feb 8, 2024, 4:40:04 AMFeb 8
to
On 2024-02-08 00:13, Samuel Thibault wrote:
> Johannes Schauer Marin Rodrigues, le jeu. 08 févr. 2024 00:04:25 +0100,
> a ecrit:
> a ecrit:
>> 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.
>> 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.
Maybe I found the missing bit. In debootstrap, there is:
in_target /usr/lib/hurd/setup-translators -k
in_target /usr/lib/hurd/setup-translators -k
settrans -a "$TARGET/dev" /hurd/firmlink /dev
settrans -a "$TARGET/servers" /hurd/firmlink /servers
settrans -a "$TARGET/proc" /hurd/firmlink /proc
I'll have to figure out how to translate what these do to something I
settrans -a "$TARGET/servers" /hurd/firmlink /servers
settrans -a "$TARGET/proc" /hurd/firmlink /proc
can do on Linux.
I'll come back once I have some code. :)
Thanks!
cheers, josch
Samuel Thibault
Feb 8, 2024, 11:50:05 AMFeb 8
to
Johannes Schauer Marin Rodrigues, le jeu. 08 févr. 2024 08:12:51 +0100, a ecrit:
> > > 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
Actually, checking runsystem.{hurd,sysv} again, it's the converse: they
configure /servers/socket/1 only if it doesn't exist at all. So images
creators are currently expected to either configure it completely, or
not create it at all.
Samuel
> 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
Ah, ok, that's it indeed.
> 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
> > > 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
configure /servers/socket/1 only if it doesn't exist at all. So images
creators are currently expected to either configure it completely, or
not create it at all.
Samuel
0 new messages