IRC channel logs

<claire>Good evening, I wanted to know what was the position of the Hurd development team regarding the vibe coding. I would like to port Hurd for riscv64 in vibe coding, but as I don't have more info about that I ask the question

<GNU_Hurd_Rocks>claire: perhaps better places to look, however there is some information on other GNU projects and within documentation, https://www.gnu.org/software/gcc/ai-policy.html https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Installing-an-LLM.html

<sneek>Welcome back GNU_Hurd_Rocks, you have 1 message!

<sneek>GNU_Hurd_Rocks, damo22 says: please don't throw the baby out with the bathwater, our existing code is almost working - it just needs debugging, it doesn't need a brand new implementation from scratch just because your device isn't fully detected. Of course, you are free to do what you want, but please keep this in mind.

<GNU_Hurd_Rocks>damo22: I mostly intend to figure out ACPI to at least be familiar with it more before looking further into how this is handled by hurd/rumpkernel

<GNU_Hurd_Rocks>claire: some of us actually are interested with hurd running on RISC-V though, I have a Pi Pico 2 since it supports RV32

<claire>ok it's read, but it's for gcc... when is it for hurd and gnumach and in particular my project to make a port for the riscv64 architecture?

<claire>abort with qemu and then on a hardware based on risv64

<GNU_Hurd_Rocks>I should go debug Hurd related things though :3

<damo22>claire: I'm pretty sure we dont accept LLM written code directly, but you are free to get ideas from anywhere

<claire>That is to say, I don't really understand? Find ideas anywhere?

<GNU_Hurd_Rocks>there are definitely people willing to help with a RISC-V port though, including myself, it's just not something I'm ready to look into yet

<damo22>GNU_Hurd_Rocks: the part of ACPI you need to know about is the _PRT (pci routing tables), its in the SSDT/DSDT acpi table

<GNU_Hurd_Rocks>I need to understand more of the architecture specifics of x86 and aarch64 first, to then know what risc-v needs implemented

<damo22>GNU_Hurd_Rocks: you can look in x86_64/ directory of gnumach, that has the 64 bit specifics for x86

<GNU_Hurd_Rocks>damo22: hopefully guix provides enough utilities in the installer to help debug some things :3

<damo22>claire: you can use a LLM to guide you what to write, but we dont accept code that was written directly by an LLM

<GNU_Hurd_Rocks>damo22: yesterday you mentioned something that could be ran in GRUB

<GNU_Hurd_Rocks>will pull up channel logs...

<damo22>GNU_Hurd_Rocks: "lsacpi" shows the basic MADT table overrides i think

<GNU_Hurd_Rocks>found that :3

<damo22>GNU_Hurd_Rocks: what you could do is hardcode the irq to 6 for rumpdisk and see if your controller works

<damo22>then if that fixes the problem you need to work out why its not detecting the right irq

<claire>damo22: ok I see, so I think I may not have the level yet, unless an LLM can then be a good teacher to learn

<claire>I'm already going to try to cross compile hurd from the git

<damo22>claire: you can load parts of gnumach code into your LLM and then ask it questions about the code, eg, what does this function do

<damo22>it might help

<GNU_Hurd_Rocks>well I guess I can do lspci in grub and it shows some information about the sata controller

<damo22>but you can equally ask questions here

<claire>ok I'm starting to understand, I. believe I'm going to stay connected

<damo22>GNU_Hurd_Rocks: rumpdisk asks acpi for the irq of the disk controller usually

<claire>damo22: except that it will take you too much time, I know how to code well but as for coding there but I'm only a beginner

<claire>i know how to vibe code well*

<damo22>GNU_Hurd_Rocks: i think the problem is, your SSDT/DSDT table has the wrong information about pci routing

<claire>for coding by hand i'm only beginner

<damo22>you can confirm this

<GNU_Hurd_Rocks>damo22: trying to find the information

<damo22>GNU_Hurd_Rocks: you can use acpidump in linux and dump the tables

<damo22>but you still need some way to check the correct irq for the disk controller

<GNU_Hurd_Rocks>will see if guix provides that tool

<GNU_Hurd_Rocks>uh how do I change TTY?

<GNU_Hurd_Rocks>oh, CTRL-ALT, not ALT

<GNU_Hurd_Rocks>unfortunately not provided within the installer

<GNU_Hurd_Rocks>damo22: would this output mean anything to you? https://bpa.st/MD4A

<GNU_Hurd_Rocks>It's lspci, will be looking at acpidump now

<sigttou>GNU_Hurd_Rocks: does it boot with linux pci=nomsi? also `acpidump -b | iasl -d` would help from linux.

<GNU_Hurd_Rocks>sigttou: I have actually tried pci=nomsi and it went fine

<GNU_Hurd_Rocks>also, https://bpa.st/DZBA

<sigttou>GNU_Hurd_Rocks: `sudo acpidump -b` should create dsdt.dat, can you share that?

<GNU_Hurd_Rocks>uh where should I put that?

<sigttou>for example: https://paste.c-net.org/ `curl --upload-file dsdt.dat 'https://paste.c-net.org/'

<GNU_Hurd_Rocks>should be that? https://paste.c-net.org/McgeeFusion

<sigttou>did you boot with nomsi, please do and provide `grep -i ahci /proc/interrupts` `dmesg | grep -iE 'ahci|GSI|INTx|irq [0-9]+'` and `sudo setpci -s 00:12.0 0x3d.b`

<GNU_Hurd_Rocks>oh, that was without it, tested previously, but yeah will go do that now

<sigttou>the dsdt.dat file is fine like that, the other 3 commands would be great to have in nomsi

<GNU_Hurd_Rocks>sigttou: last couple things are me being silly, https://bpa.st/CF2Q

<GNU_Hurd_Rocks>and the cmdline ;3 BOOT_IMAGE=/boot/gentoo pci=nomsi dokeymap nodhcp root=live:CDLABEL=Gentoo-amd64-20260913 rd.live.dir=/ rd.live.squashimg=image.squashfs cdroot

<sigttou>GNU_Hurd_Rocks: did you ever try the amd64 hurd image to boot?

<GNU_Hurd_Rocks>uh I swear yes, but I will go reinstall again to test again

<GNU_Hurd_Rocks>although I am yet to try my Gentoo version as I keep trying to use the guix version instead

<sigttou>ok, are you able to catch the bootlog (from the 32bit boot is fine)? 'interrupt expected on irq X arrived on irq Y' 'device_intr_register failed with N' 'tried acpi to get pci gsi and failed for 00:12.0' 'failed to register irq N' lines would be interesting.

<GNU_Hurd_Rocks>unfortunately I don't think so

<GNU_Hurd_Rocks>would be neat to have less-like paging though, would help

<sigttou>that's a pitty, serial console would be great! Maybe you are able to spot one of these lines, 'interrupt expected on irq 19 arrived on irq 6' is my guess.

<sigttou>idk if shift+pgup works, but you can try

<GNU_Hurd_Rocks>sigttou: it's a laptop so the screen is where it outputs to

<GNU_Hurd_Rocks>will try key combination, assuming keyboard even works at all in such state

<GNU_Hurd_Rocks>still waiting on guix though :3

<sigttou>GNU_Hurd_Rocks: yeah, if you manage to spot any of these lines, let me know, might also be right above the hang during boot. Also, try the amd64 image, could also be a 32bit issue, but I am just guessing.

<GNU_Hurd_Rocks>Is this still accurate? "Hurd" stands for "Hird of Unix-Replacing Daemons". And, then, "Hird" stands for "Hurd of Interfaces Representing Depth"

<GNU_Hurd_Rocks>waiting on the install to finish though, will try 32-bit if 64-bit fails, and will try to catch the error

<GNU_Hurd_Rocks>sigttou: spams out so much text...

<sigttou>sadly so, there was hoping either scrollback is there or the interesting line(s) are above the hang :/

<GNU_Hurd_Rocks>and unfortunately couldn't scroll back

<sigttou>is this 32bit now? where is it hanging?

<GNU_Hurd_Rocks>should be 64-bit, can check somehow I think

<sigttou>I think it should say in grub

<GNU_Hurd_Rocks>grub config, https://bpa.st/BDWQ

<GNU_Hurd_Rocks>uhm wtf does grub have access to the filesystem

<GNU_Hurd_Rocks>yes it is 64-bit, "gnumach: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, with debug_info, not stripped"

<GNU_Hurd_Rocks>or at least it is ELF64...

<sigttou>ok, so what's the last line during boot it hangs now?

<GNU_Hurd_Rocks>It's still related to not finding the root partition

<GNU_Hurd_Rocks>er the device

<sigttou>anything above that stating irq?

<GNU_Hurd_Rocks>recorded the boot, will try to share somewhere

<GNU_Hurd_Rocks>reasons I need a file server lol

<sigttou>if possible, not sure how handy you have it, can you also check the 32bit boot hang?

<GNU_Hurd_Rocks>It's a lot of frame-by-frame copying, hopefully I understood it, https://bpa.st/VEZQ

<GNU_Hurd_Rocks>and then later this, which I hae shared, https://bpa.st/HBRQ

<GNU_Hurd_Rocks>will go try 32-bit now

<sigttou>that's helpfull, not sure if you could manage, but maybe worth trying - boot linux pci=nomsi, reboot (command, not power cycle), load hurd, it might read 19 there.

<GNU_Hurd_Rocks>started with 32-bit install after you said that, ouch

<sigttou>ok, the 32bit works? that's nice

<GNU_Hurd_Rocks>have not booted it yet

<GNU_Hurd_Rocks>only happened to get it started after

<GNU_Hurd_Rocks>hopefully it finishes installing soon though

<sigttou>you boot from USB? we can also use that to debug ACPI, might be worth a shot

<GNU_Hurd_Rocks>sigttou: 32-bit, https://bpa.st/5X2A

<GNU_Hurd_Rocks>similar but oddly less verbose I guess

<GNU_Hurd_Rocks>no intnull(6)

<sigttou>if you can boot from USB, you can try this script as root: https://paste.c-net.org/PostmanShovels

<sigttou>also, on linux `sudo setpci -s 00:12.0 0x3c.b` would be good information

<GNU_Hurd_Rocks>both on linux host?

<sigttou>The script to run when booting hurd 64bit from USB, if that works.

<sigttou>the command on linux live, it's reading the interrupt line

<GNU_Hurd_Rocks>that returned 05

<GNU_Hurd_Rocks>rebooting to see if it changes per boot...

<sigttou>good luck, I suspect ACPI isn't available when rumpdisk starts, if booting from USB works and we can confirm rumpdisk works with reordering it might be fixable

<GNU_Hurd_Rocks>without pci=nomsi, 05, with pci=nomsi, 05, so that's the same either way

<GNU_Hurd_Rocks>lspci "Interrupts: pin B routed to IRQ 19"

<GNU_Hurd_Rocks>will see if I can copy over to USB though...

<sigttou>if you have linux still up `sudo setpci -s 00:12.0 0x3d.b 0x3c.b`

<sigttou>if you manage to add to the usb image, would be the best

<GNU_Hurd_Rocks>bringing it back up under linux to try copying the partition structure over

<GNU_Hurd_Rocks>sigttou: 01 05

<GNU_Hurd_Rocks>is there bootable media that works for USB though?

<GNU_Hurd_Rocks>will try debian hurd at least

<damo22>looks like your DSDT says IRQ=19 for SATA

<damo22>but did you see it working with 5?

<GNU_Hurd_Rocks>I have minimal understanding on acpi

<damo22> 0x0012FFFF,

<damo22> Zero,

<damo22> 0x13

<GNU_Hurd_Rocks>I'm guessing and thinking 0x13 is 19

<sigttou>19 apic. 6 pic

<GNU_Hurd_Rocks>pic, ouch, old stuff

<GNU_Hurd_Rocks>doing a tar xf on something so I should go deal with that

<sigttou>GNU_Hurd_Rocks: i honestly don't know if boot from USB is possible, I haven't tried anything besides qemu so far

<GNU_Hurd_Rocks>for the "debian-hurd.img.tar.xz" at http://cdimage.debian.org/cdimage/ports/latest/hurd-i386/ do I just tar unpack and then put that onto the device? (that is what I am trying)

<GNU_Hurd_Rocks>random changing of what I was saying lol...

<damo22>yes

<Alicia>is there a reason for that to be a tar instead of just .img.xz?

<damo22>you need to capture the full boot log

<damo22>tar packs the empty space between files

<Alicia>ah!

<azeem>there's only one file in the tar though IIRC

<GNU_Hurd_Rocks>yes indeed I need full boot log

<GNU_Hurd_Rocks>yes, only one

<GNU_Hurd_Rocks>ok it booted but the error was different, still partition related except it sees the device this time

<Alicia>I interpreted "empty space between files" as the empty parts in sparse files?

<damo22>i think so

<azeem>right, that makes sense

<GNU_Hurd_Rocks>transcribing, if that's the right term, the boot logs that I can at least see

<damo22>can you see a line that says irqhelp [19] or something

<damo22>you need to check what irq rumpdisk is using and if it worked or not

<GNU_Hurd_Rocks>I think the most important thing though is this, part:2:device:hd0: No such device or address, however there is a wd0 and is showing information such as being 119 GBs, and it being a SSSTC CVB-8D128-HP

<damo22>aha

<GNU_Hurd_Rocks>maybe part:1:device:wd0?

<damo22>your device is selected wrong

<GNU_Hurd_Rocks>will try what I said to see

<damo22>you need to change hd0 to wd0 in the boot step yes

<GNU_Hurd_Rocks>oh lol, panic, because bad magic number, is it supposed to be part:2 ?

<damo22>is this the downloaded disk image?

<GNU_Hurd_Rocks>I think yes

<damo22>part:2

<damo22>part:1 is swap most likely

<GNU_Hurd_Rocks>came up with something about fsck

<GNU_Hurd_Rocks>fsck.ext2: No such device or address while trying to open /dev/hd0s2

<damo22>/etc/fstab has the wrong entry

<GNU_Hurd_Rocks>also the terminal is not echoing when typing

<GNU_Hurd_Rocks>ah, "reset" fixed so we are good there

<GNU_Hurd_Rocks>I always forget about that command lol

<damo22>so it booted

<GNU_Hurd_Rocks>that is a definite yes

<damo22>sudo lspci | grep Net

<damo22>sudo lspci -nn | grep Net

<damo22>sorry

<GNU_Hurd_Rocks>RTL8821CE [10ec:c821] (I know this thing requires firmware to be loaded)

<damo22>hmm netdde might work

<GNU_Hurd_Rocks>there is the ethernet controller though, [10ec:8168]

<damo22>ok

<GNU_Hurd_Rocks>ideally I can change hd0s2 and hd0s1 to instead be wd prefixed instead?

<GNU_Hurd_Rocks>that is within the fstab

<damo22>yeah

<damo22>you can get network access too

<GNU_Hurd_Rocks>unfortunately root was mounted read only

<damo22>sudo mount -o remount,rw /

<GNU_Hurd_Rocks>damn, that's crazy

<GNU_Hurd_Rocks>there is an entry for /dev/hd2 with a mount point of /media/cdrom0 so I'm commenting that out, but it does have noauto at least as an option

<GNU_Hurd_Rocks>and I made certain to touch the grub config to fix that one thing

<damo22>edit /etc/network/interfaces and put:

<damo22>iface /dev/eth0 inet dhcp

<damo22>then you can do ifup /dev/eth0

<damo22>it might already be there

<GNU_Hurd_Rocks>ok I rebooted and uh not doing anything lol

<damo22>where is it stuck

<GNU_Hurd_Rocks>it says that is is listening/sending on Socket//dev/eth0

<damo22>is this hardware? did you plug a network cable in?

<damo22>if you dont want network now you can ctrl-z to skip

<GNU_Hurd_Rocks>will try that I guess

<GNU_Hurd_Rocks>damo22: yes hardware

<GNU_Hurd_Rocks>uh ctrl-z causes it to start syslogd because I think it messed with init

<GNU_Hurd_Rocks>I think it was meant to be within a VM but I'm using it on a laptop

<damo22>you could remove "auto /dev/eth0" from /etc/network/interfaces

<damo22>then it wont try to autostart networking on boot

<damo22>or just plug in a network cable

<GNU_Hurd_Rocks>doing "nano /etc/network/interfaces" doesn't like something

<damo22>good luck, sleep time

<damo22>sleep(28800)

<GNU_Hurd_Rocks>after doing some sed related things and accidentally making the file contents empty, I finally got it removed

<GNU_Hurd_Rocks>never trust me using sed

<GNU_Hurd_Rocks>damo22: gnue

<GNU_Hurd_Rocks>gnute*

<damo22>o/

<GNU_Hurd_Rocks>I AM LOGGED IN NOW YIPPEE

<GNU_Hurd_Rocks>end result, looks to be a guix bug that I have no idea how to explain

<sigttou>what's the state

<GNU_Hurd_Rocks>sigttou: state?

<GNU_Hurd_Rocks>however, later I will be moving over to Gentoo/Hurd :3 (personal favorite for operating systems)

<sigttou>if you got it booting on that HW now GNU_Hurd_Rocks

<GNU_Hurd_Rocks>and yes it is currently the Debian version right now

<sigttou>ok, so the disk works with debian hurd?

<sigttou>or is that a live system?

<GNU_Hurd_Rocks>works with the disk

<sigttou>ok, is it 32 or 64bit?

<GNU_Hurd_Rocks>32-bit right now

<GNU_Hurd_Rocks>so I will have to later look at 64-bit

<sigttou>would be interesting to see, let's check first, can you run: https://pastee.dev/p/Q7kFkExh

<GNU_Hurd_Rocks>that's crazy, "Due to issues with the Internet.ee domain registry, our main domain, paste.ee, is currently disabled due to abuse reports"

<sigttou> https://pastebin.com/mNE4G2Sc mirror

<GNU_Hurd_Rocks>yes I can see it though, don't worry

<GNU_Hurd_Rocks>sigttou: https://bpa.st/BQMA

<GNU_Hurd_Rocks>did not do ls /dev/wd* as there were a lot of different things listed

<sigttou>and https://bpa.st/SUUA please GNU_Hurd_Rocks

<GNU_Hurd_Rocks>ah yikes I really need network then

<sigttou>oh, you can also take a picture

<sigttou>issue is likely the boot order of guix pci arbiter, rumpdisk, ext2fs is the working one from Debian

<sigttou>Surprised openvpn just works(tm) nowadays...

IRC channel logs

2026-09-18.log