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 <jann...@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com