From: Jan Nieuwenhuizen <janneke@gnu.org>
To: "pelzflorian \(Florian Pelz\)" <pelzflorian@pelzflorian.de>
Cc: help-guix@gnu.org
Subject: Re: How to run Guix with Hurd
Date: Sun, 12 Jul 2020 10:51:58 +0200 [thread overview]
Message-ID: <87a705m7yp.fsf@gnu.org> (raw)
In-Reply-To: <20200712065934.bchlfujkfhqgs7ih@pelzflorian.localdomain> (pelzflorian@pelzflorian.de's message of "Sun, 12 Jul 2020 08:59:34 +0200")
pelzflorian (Florian Pelz) writes:
Hello!
> On Sun, Jul 12, 2020 at 01:05:28AM +0200, Jan Wielkiewicz wrote:
>> Hurd lacks SMP (Simultaneous MultiProcessing), is 32-bit only and it
>> doesn't support modern hardware yet.
>
> I too wanted to try Hurd on real hardware. I see Jan Nieuwenhuizen
> does much work on it.
And others, sometimes somewhat more behind the scenes.
> After Jan Nieuwenhuizen’s patches from the beginning of July, I did
> partition /dev/sda as dos, not gpt, and created a partition via
> mkfs.ext2 on it (with inode size 128, but I think it does not matter).
Ooh, sweet!
> But Hurd does not support SATA disks (I think), so booting gets stuck
> when it starts an ext2fs translator.
It may just yet. Make sure your /dev/sda1 smaller than 128GiB.
Booting GNU/Linux on the X86 shows /dev/sda (in fact I have Guix on
/dev/sda2 and used guix system reconfigure together with rsync'ing the
store) but the Hurd just sees hd0s1. It took me quite some time and
help to find this faq entry
https://www.gnu.org/software/hurd/faq/2_gib_partition_limit.html
(I didn't read it because I knew the 2GiB limit was no longer an issue).
I did something simalar on a Thinkpad X60 and managed to boot, but I'm
now stuck getting networking up. We have netdde but I cannot get that
to work yet; it fails with
--8<---------------cut here---------------start------------->8---
netdde: vm_allocate_contiguous : (ipc/mig) bad request message ID
--8<---------------cut here---------------end--------------->8---
Sadly, after applying
--8<---------------cut here---------------start------------->8---
https://salsa.debian.org/hurd-team/gnumach/-/blob/master/debian/patches/70_dde.patch
--8<---------------cut here---------------end--------------->8---
the Hurd does fails to build for me with a link error
--8<---------------cut here---------------start------------->8---
i586-pc-gnu-gcc ... -o boot => boot/deviceServer.c:1227: undefined reference to `ds_device_intr_enable'
--8<---------------cut here---------------end--------------->8---
Apparently, our glibc build is off
--8<---------------cut here---------------start------------->8---
2020-07-07.log:[21:25:53] <youpi> janneke: you need to build glibc against the patched gnumach headers
--8<---------------cut here---------------end--------------->8---
...but all I looked, it seems we are already (always) doing that. I
haven't found if how and where to mould this into a proper bug report
yet; probably it's a mistake on our side.
This probably works OOTB upon a new gnumach+hurd release, and it may
also be obvious/easy when we get more acquainted with the dependencies
here.
See also
http://richtlijn.be/~larstiq/hurd/hurd-2020-07-07
http://richtlijn.be/~larstiq/hurd/hurd-2020-07-11
https://gitlab.com/janneke/guix/-/tree/wip-hurd-reconfigure
> I should try again, but this definitely needs users to spend time with
> making the system work. The Childhurd service is probably better for
> just watching in awe.
Yes; while real hardware is fun, trying takes a lot of time and we can
have lots of productive and fun times with the childhurds for now.
Greetings,
Janneke
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
next prev parent reply other threads:[~2020-07-12 8:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-11 21:14 How to run Guix with Hurd fr33d0m
2020-07-11 23:05 ` Jan Wielkiewicz
2020-07-12 6:25 ` fr33d0m
2020-07-12 6:59 ` pelzflorian (Florian Pelz)
2020-07-12 8:51 ` Jan Nieuwenhuizen [this message]
2020-07-12 8:58 ` Jan Nieuwenhuizen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a705m7yp.fsf@gnu.org \
--to=janneke@gnu.org \
--cc=help-guix@gnu.org \
--cc=pelzflorian@pelzflorian.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).