Easy testing on real hardware with FSDG distributions?

[Denis 'GNUtoo' Carikli]

Hi,

The HURD wiki now mentions that the "X200, T400, or T500 Thinkpads"
can now run HURD[1]. 

My interest in HURD at the moment is mainly to test HURD to document
which GNU Boot configurations can or cannot boot HURD and maybe have
some automatic testing done with HURD as well or if it's too much work,
to document the current status (cannot test hurd ourselves, in need for
volunteers to do that, need to wait for <foo> for testing, etc).

Since we don't want to force GNU Boot contributors to run nonfree
distros, and that we can't integrate code to automatically tests with
nonfree distros either, our only option is either to rely on voulonteers
to run tests or to do the tests ourselves with FSDG distros.

In practice we already have automatic testing with Trisquel and LVM for
instance, and Guix and Trisquel are also manually tested quite often
these days.

So this brings my question: Is there an easy way to somehow reproduce
an installation of GRUB with FSDG distributions or does that still
require Debian?

I'm looking for something that can potentially be automatized or
reproduced by following some instructions somehow, and if that doesn't
exist, I'm looking for a way to do that without too much work, or to
document the current status.

The two FSDG distributions that seem to have support for HURD are Guix
and Trisquel.

For Guix it's well tested in VMs within the childhurd compilation
offload Guix service, but when running in some other configurations it
has several issues:
(1) The GRUB configuration somehow hardcodes 'hda1' as the HURD
    partition. On real hardware it can be worked around by identifying
    which partition is the right one and changing it accordingly
    (usually it's sda1 or sda2 depending on if there is a cdrom/dvd
    drive for instance). With standalone VMs this is easier to deal with
    than as one can just make the disk image become ATA and get rid of
    the issue for good.
(2) Guix with GRUB can only boot once on standalone VMs or on real
    hardware. It's a known bug and there are workarounds in the
    hurd-team branch in Guix. With standalone VMs the workaround is to
    copy the VM file before each boot but that is way more time
    consuming to do with real hardware.

The combination of both issues makes it harder to test, especially if we
add other things in the mix like changing the boot software and/or
its build configuration and/or broken hardware.

There is also Trisquel that has a crosshurd package but I've not tested
it yet, but it also seems to use debian's sources.list.

So I was wondering if people had workaround for the issues above to
make it relatively easy to test, or if there are other paths that can
results in a HURD image that can be tested somehow.

References:
-----------
[1]https://darnassus.sceen.net/~hurd-web/faq/drivers/

Denis.

pgpHyB3qn45vN.pgp
Description: OpenPGP digital signature