On Tue, 8 Oct 2024 00:00:11 +0200 Samuel Thibault <samuel.thiba...@gnu.org> wrote: > I didn't know that trisquel had a Hurd port? It doesn't, it only has a crosshurd package. And so I guess that given your answer it does require a Hurd port to work, and I would guess that it uses Debian's hurd port.
> This doesn't seem a bug that would be hard to fix.
The issue here is also that I wanted to improve a bit the documentation
we have on booting other operating systems than GNU/Linux and
promote GNU Hurd as well along the way without being dragged into fixing
things that can delay the documentation patches for too long.
However I'm not against fixing these bugs later on as it would simplify
things for everybody.
Part of the issue here is also that in Guix some patches are reviewed
rapidly while other can wait for year(s) when the patches are
complicated and that most reviewers are not familiar with the topic, so
our current approach is to send patches upstream and to integrate them
independently on top of Guix 1.4.0 in GNU Boot source code, not to be
stuck if the patches are waiting to be accepted for a long time. We
mainly use 1.4.0 to benefit from the manual being hosted there.
All this works fine for packages but all the Guix code mentioned here
(more on that below) is not in packages, so this complicate things.
Hence my research for more information and workarounds rather than
fixing directly, because If I find the time, I can probably manage to
start digging into them without needing to bother people on the HURD
mailing lists.
> > 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.
>
> Where do you see that hardcoding? This doesn't seem a bug that would
> be hard to fix.
I see it in the grub configuration in "root=part:1:device:hd0" like
below:
> menuentry "GNU with the Hurd 0.9.git20231217" {
> multiboot
> /gnu/store/y7y93cbrx94hdva4c80m52hciki2379y-gnumach-1.8-0.2556fde/boot/gnumach
> root=part:1:device:hd0 root=87c2de13-ec83-7077-6604-780f87c2de13
> gnu.system=/gnu/store/8ghkjk31rzh1n8q2597irbqiqr45wfm5-system
> gnu.load=/gnu/store/8ghkjk31rzh1n8q2597irbqiqr45wfm5-system/boot
> module
> /gnu/store/8dgzmp2rms174pmi3yhsbfvjs9rczynv-hurd-0.9.git20231217/hurd/pci-arbiter.static
> pci-arbiter --host-priv-port='${host-port}'
> --device-master-port='${device-port}' --next-task='${disk-task}'
> '$(pci-task=task-create)' '$(task-resume)' module
> /gnu/store/8dgzmp2rms174pmi3yhsbfvjs9rczynv-hurd-0.9.git20231217/hurd/rumpdisk.static
> rumpdisk --next-task='${fs-task}' '$(disk-task=task-create)' module
> /gnu/store/8dgzmp2rms174pmi3yhsbfvjs9rczynv-hurd-0.9.git20231217/hurd/ext2fs.static
> ext2fs --multiboot-command-line='${kernel-command-line}'
> --exec-server-task='${exec-task}' --store-type=typed
> --x-xattr-translator-records '${root}' '$(fs-task=task-create)'
> module
> /gnu/store/8dgzmp2rms174pmi3yhsbfvjs9rczynv-hurd-0.9.git20231217/hurd/exec.static
> exec '$(exec-task=task-create)' }
I've also tested it in practice on real hardware: if I remove the cdrom
and replace 'hda' by 'sda' the boot proceed further on computers like
the T60 with Intel GPU or the T400.
To get that configuration I did the following:
> guix system image [...]--image-type=hurd-raw hurd-vm-system.scm
with something based on gnu/system/examples/bare-hurd.tmpl and it gets
"hda1" inside grub.cfg instead of some UUID or label.
I've something like that for the GRUB configuration:
> (bootloader (bootloader-configuration
> (bootloader grub-minimal-bootloader)
> (terminal-outputs '(console))
> (targets '("/dev/sdX"))))
The 'guix system image' tends to ignore the targets field.
So I then looked a bit and found that in gnu/build/hurd-boot.scm:
> (disk (string-append "hd" n))
So I assumed that it was hardcoded somehow, even if I didn't debug
precisely how this got inside the grub configuration and I fear that
would take quite some time for me to do it as I'm not familiar with that
code yet.
> > (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.
>
> Do you have references on this?
The hurd-team branch in the guix source code[1] has the following
commits:
> commit fa003825efb5b6ea79f8570680c94930b9a17fdf
> Author: Janneke Nieuwenhuizen <jann...@gnu.org>
> Date: Tue May 30 18:08:38 2023 +0200
>
> DRAFT hurd-boot: Support second boot.
>
> * gnu/build/hurd-boot.scm (boot-hurd-system): Check for stale
> shepherd socket and remove it. Be chattier about /hurd symlink
> replacement.
>
> commit 6b34e08e4d257b31d21404405b66b730f15a0b89
> Author: Janneke Nieuwenhuizen <jann...@gnu.org>
> Date: Tue May 30 18:02:38 2023 +0200
>
> DRAFT hurd: Support second boot.
>
> XXX This works beautifully, also on my x60, as long as the
> filesystem is clean. Although our fsck in libexec/runsystem doesn't
> work without or with the current ftab, this may be a bad idea?
>
> This avoids hanging upon second boot and ensures a declarative
> /hurd and /dev.
> * gnu/packages/patches/hurd-startup.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/hurd.scm (hurd): Use it.
> [arguments]: In stage create-runsystem remove /dev/urandom.
It's also a well known issue within Guix Hurd and it was discussed
informally at the latest FOSDEM in person. There are also bug reports
but I'm unsure which ones exactly as the commit above don't contain
references to bug reports. I'll try to run more tests in a VM to
capture the output.
> Concerning Debian GNU/Hurd, there is simply no contrib or non-free
> section in its debian-ports archive, so it's really only free
> software.
Thanks a lot, this is interesting. However in our case we prefer
staying on the safe side and only recommend the official free distros
to avoid the risk of creating huge debates.
References:
-----------
[1]https://git.savannah.gnu.org/cgit/guix.git
Denis.
pgpk5DHSyNdab.pgp
Description: OpenPGP digital signature
