Hi,
Quoting Samuel Thibault (2024-12-05 09:00:35)
> > So now I can create bootable ext2 hurd-i386 disk images on my arm64 Linux
> > box.
>
> That's cool :) I'll have to see if I can then automate the building of
> the image that I put on cdimages.
you are creating that image manually right now? How do you do it?
>
> > 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(), so libarchive support
is an optional feature. This is important because e2fsprogs is supposed to also
work on distros without libarchive and it's important to not make bootstrapping
harder.
Nevertheless, e2fsprogs could at least Recommends or Suggests libarchive13 so I
opened bug #1089085.
> Ideally others would be automatically included too (notably the port archive
> keyring since it's a debian-port,
This is a difficult problem. It would require that there exists some sort of
mapping between the mirror URL to a keyring. As of today, we do not have a
machine readable way to make this mapping. In my opinion, this should go into
distro-info-data (and you will see bugs I filed there about this several years
ago) but I'm talking with juliank about improving the status quo. This is not
ready today though.
> sysvinit because it's not linux)
But mmdebstrap cannot know that you want an init system in the first place and
the init package is no longer Essential. So how would you make this selection
automatic?
> > --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. If one creates a bootable linux image (which for example debvm does)
then you also need to explicitly list linux-image-${arch}.
> > | chroot "$1" /sbin/mkfs.ext2 -q -F -o hurd -I 128 -b 4096 -d - /tmp/hurd.ext2 204800' \
>
> -I 128 -b 4096 are useless, -o hurd is enough to automatically get
> everything that is needed.
I was surprised about the requirements for inode-size and block-size. Thus, I
hard-coded those to be on the safe side and to have this documented for me.
> > I think this is pretty cool. A bootable GNU/Hurd disk image created on Linux
> > from first principles, straight from the ports.d.o apt mirrors without going
> > through d-i or downloading disk images and thus everything that we built is
> > verified using GPG (via debian-ports-archive-keyring). No superuser privileges
> > required. Works when running from Debian stable.
>
> Yay :)
>
> Also, I didn't know about the -d option of mke2fs. We can probably use
> it in d-i and drop the genext2fs package.
Another problem with genext2fs is, that it shows some O(N²) behaviour, see
https://github.com/bestouff/genext2fs/issues/31
A benefit of genext2fs is, that it produced bit-by-bit reproducible output
automatically.
> > The only wrinkle is, that the result is not yet bit-by-bit reproducible when
> > having SOURCE_DATE_EPOCH and a uuid and hash_seed set... I'll investigate that.
> Thanks.
Found it. It's here:
https://sources.debian.org/src/hurd/1%3A0.9.git20240714-4/debian/local/setup-translators/#L151
[ -r /var/lib/random-seed ] || date > /var/lib/random-seed 2> /dev/null
It writes the current time into /var/lib/random-seed which of course makes the
output unreproducible. I filed #1089092 with a patch. If you prefer, there's
also this MR: https://salsa.debian.org/hurd-team/hurd/-/merge_requests/3
> > I also plan to add this to the dpkg-root-demo salsa CI pipeline to make
> > sure that this setup keeps working going forward.
> Yes, that'll be a useful CI.
I'll do that after the thing is bit-by-bit reproducible. :)
Thanks!
cheers, joschAttachment:
signature.asc
Description: signature