[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-12-05 18:22:11)
> > you are creating that image manually right now? How do you do it?
> 
> Yes, see http://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.txt

oh no! :D

I looked into how that can be automated. I think you can do what you want by
using unattended installations with debian-installer. I have used a preseed
file to create Debian installations unattended for all release architectures
except for s390x and mips* (because they lack a bootloader). I hear that hurd
can be booted with GRUB, so maybe the process in debian-hurd.img.txt can be
completely automated using a preseed file doing the basic setup and then a "d-i
preseed/late_command" which carries out most of your custom configurations
automatically?

I looked into doing this and started with this:

qemu-img create -f qcow2 disk.qcow 4G
wget -nc http://cdimage.debian.org/cdimage/ports/latest/hurd-i386/netinst.iso

# we need to extract files from the cdrom image because we want to pass additional options
bsdtar --to-stdout -xf netinst.iso boot/initrd.gz > initrd.gz
bsdtar --to-stdout -xf netinst.iso boot/kernel/exec.static > exec.static
bsdtar --to-stdout -xf netinst.iso boot/kernel/ext2fs.static > ext2fs.static
bsdtar --to-stdout -xf netinst.iso boot/kernel/gnumach.gz > gnumach.gz
gunzip -f gnumach.gz

qemu-system-i386 -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000 -m 1G \
  -kernel gnumach -append "TERM=mach-gnu-color auto-install/enable=true debconf/priority=critical netcfg/get_hostname=hostname netcfg/get_domain=domain passwd/root-password=r00tme passwd/root-password-again=r00tme passwd/user-fullname=user passwd/username=user passwd/user-password=insecure passwd/user-password-again=insecure pkgsel/run_tasksel=false popularity-contest:popularity-contest/participate=false grub-installer/bootdev=/dev/sda" \
  -initrd 'initrd.gz $(ramdisk-create),./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 gunzip:device:rd0 $(task-create) $(task-resume),./exec.static $(exec-task=task-create)'

This gets me all the way up to d-i where it seems to hang here with nothing
else in the log:

https://mister-muffin.de/p/p6Xj.png

Apologies for having to post a screenshot of qemu. I haven't yet figured out
which options I have to pass to hurd to get output on the serial line that
qemu prints to the terminal with -nographic. Under Linux it would be something
like console=ttyS0,9600,n8

The input to the process is netinst.iso. How (and by whom) is that generated?

> > > 
> > > >     mmdebstrap --variant=apt \
> > > >         --include=passwd,debian-ports-archive-keyring,mmdebstrap,sysvinit-core,sysv-rc,e2fsprogs,libarchive13 \
> > > 
> > > It's odd that you need to ask for libarchive13 explicitly?
> > 
> > Yes. The libarchive support of e2fsprogs is via dlopen(),
> 
> Ah, ok.

I have filed #1089085 about this which is tagged as pending.

> > > sysvinit because it's not linux)
> > 
> > But mmdebstrap cannot know that you want an init system in the first place
> 
> > > >             --include=sysvinit-core,sysv-rc,debian-ports-archive-keyring,gnumach-image-1-486
> > > 
> > > Here, also, the kernel should be autodetected?
> > 
> > But mmdebstrap cannot know that the chroot you want to create is supposed to be
> > bootable.
> 
> Perhaps mmdebstrap could be given options to tell so and behave
> accordingly?

That's the task of a higher-level tool like debvm. I want to create a tool that
can do one thing well by avoiding layer-violations. The task of mmdebstrap is
to create chroots. For more special tasks, another tool can call mmdebstrap in
a special way to achieve this. I want to avoid creating a tool that tries to
do everything at the same time and then looks like this:
https://manpages.debian.org/bookworm/sbuild/sbuild.1.en.html

> > A benefit of genext2fs is, that it produced bit-by-bit reproducible output
> > automatically.
> 
> mke2fs doesn't?

It can if you pass it some extra options which I would not call "automatically"
anymore. You also need to feed mke2fs a tarball. It is probably a bug that
mke2fs cannot create reprodicible disk images when given a directory, even with
the special options, but I have not yet figured out how to fix it, so I work
with tarballs. The special options are -U and -E hash_seed=... The former gives
a non-random uuid to the filesystem and the latter a non-random seed for the
internal hash functions.

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature


Reply to: