IRC channel logs
2026-05-24.log
back to list of logs
<Pellescours>I’m hacking xfstests to run them on hurd. I succeed to run the firsts tests and some failed due to hurd unimplemented things. I see no option to respect noatime nodiratime, where and how do you think it should be implemented? <jab>morning Hurd people! <jab>Pellescours: I am glad that you are working on xfstests! <jab>documentation / more info on the wiki would be super helpful! <jab>I've been thinking that we should make an unofficial hurd /etc repo and put your script and Milos dev setup script into it. <jab>We shouldn't lose those scripts. <jab>Also, it would make it TONS easier if, you were willing to assign copyright to the FSF. That way, if you script ever gets robust enough that Samuel is willing to merge it, there is no issue. <Alicia>I feel like it maybe doesn't really belong in any of the existing repos to begin with <jab>Well, it could go into $hurd-src/etc The $hurd-src/etc directory is where people can include various scripts, but are not considered maybe fully backed...or other people might find useful. <jab>There are apparently a few open source projects that do this. Drew Devault blogged about it once, but I can't find the blog post at the moment. <Alicia>shouldn't those scripts be ones that are necessary/helpful for compiling the code in the current sourcetree though? to me it feels wrong to checkout a source tree only to run one script therein that downloads binaries and does nothing with the source <jab>Alicia: there might already be such a script....actually I think that there was such a project once upon a time... <Alicia>ah, that doesn't seem like something that should go in the hurd sourcetree either. maybe the part of it that compiles hurd (but not the part that would have downloaded it again) <jab>it either should be apart of the hurd source or not, but I strongly advice that we commit it somewhere. :) <jab>the newest AArch64 patches that came in look interesting. <Alicia>yeah I agree with committing them somewhere <Alicia>if the AArch64 builds can run on raspberry pis that could be really cool for ease of access to run on real hardware <sneek>Welcome back solid_black, you have 2 messages! <sneek>solid_black, damo22 says: my latest patch for irq nesting should fix a race causing a hang in smp, but it seems to have exposed a new vm bug, can you try gnumach smp with my latest patch and try compiling with multiple cores? you seem to understand the vm subsystem way more than i do, the error was: {cpu5} ../vm/vm_fault.c:709: vm_fault_page: Assertion `!must_be_resident' failed <sneek>solid_black, damo22 says: once i get realtek "re" driver working in rumpnet, i can set up a native hurd amd64 box on my HP T620 running coreboot <solid_black>and sneek is thill there, holding messages for me that must be what, years old? <rsmarples>for a vm which would be better to try and get working? i386 or x86_64? <rsmarples>for a network install iso is it normal to fail to detect installation media? <rsmarples>it seems to take ages creating the device nodes for fd and hd <rsmarples>on the console it says somethings about cd0 cannot detect superblock and then goes back to the installer with the "installation media could not be mounted" error <rsmarples>qemu-system-x86_64 -rtc base=utc,clock=host -device ahci,id=ahci -device ide-hd,drive=disk13,bus=ahci.0 -drive file=hu <rsmarples>rd.qcow2,if=none,id=disk13 -object rng-random,id=rng13,filename=/dev/urandom -netdev tap,ifname=tap13,id=net13,script=no <rsmarples>,downscript=/home/roy/qemu/qctrl-tapdown -device 'e1000,romfile=,netdev=net13,mac=52:54:00:73:00:0d' -vnc ':13,password' -monitor 'telnet:127.0.0.1:4413,server,nowait' -pidfile /home/roy/qemu/run/qemu-hurd.pid -daemonize -m 4G -smp cpus=2 - <rsmarples>cdrom debian-hurd-2025-amd64-NETINST-1.iso -boot d <jab>rsmarples: I would try running the Hurd on real hardware. I've been trying to run the Hurd in a vm for years...I personally have had better luck on real hardware. <rsmarples>jab: that doesn't help testing a DHCP server/client in the lab when I can't put the subjet in the lab to begin with ... <Alicia>I've never had success with hardware so far. qemu seems fine <jab>I'm fairly happy with my T420. <jab>I think I am actually running "ext3/4fs" now. <rsmarples>Alicia: what is the secret sauce to install please? :) <rsmarples>gah, ill try a pre-installed image then i guess <rsmarples>Alicia: well actualy that's some progress. the pre installed image boots, gets on my network (dhclient isn't rfc compliant, lol) <rsmarples>but i can't login as it says kbd: queue full <rsmarples>ok, so i can login but as soon as the graphical console fires up boom, no more input <rsmarples>i can interact with ssh, but can't login as it won't accept a blank password for root <jab>rsmarples: is kvm enabled ? <rsmarples>jab: this is a netbsd host. the eqivalent accelerator (nvmm) is disabled <jab>trying to virtually run the hurd without kvm...is going to be a poor experience. <rsmarples>ill take a working experience over a fast one! <jab>I don't know that the hurd "works" without kvm. <rsmarples>jab: the kvm just allows the vm to take advantage of host hardware to go faster <rsmarples>i mean yeah i enable nvmm and it's a much much much faster boot but qemu eventually crashes <sam_>it indeed works fine, just slowl <Alicia>idk the cause or fix/workaround for the input queue issues, but to sidestep it you could probably mount the image and insert your public key for ssh public key authentication and/or set the password in $HURD_MOUNT/etc/shadow <Alicia>rsmarples: iirc it's just two partitions, first one is boot and second one is root <diegonc>rsmarples: you can try disabling the hurd console to avoid the kbd full error ( i think in /etc/defaults/hurd-console -> ENABLE="false" ) <diegonc>by default it must initilize before 20 sec, so without kvm it can't finish initializing in time <Alicia>oh! I should add that as an option to my run-hurd script