IRC channel logs
2026-05-13.log
back to list of logs
<etno>Just guessing, but this could mean that the device cache is not detected as write-through and flush is not implemented by the device ? <bjc>does anyone have any documentation on how the multiboot stuff works in grub.cfg? <bjc>the grub documentation is crickets on it. the only source is a very low-level description of the abi, which doesn't help <bjc>like, specifically, how does the $(…task=task-create) and next-task stuff work <bjc>thanks. i'll read 'em when darnassus starts responding again =) <jab>etno: Milos emailed me privately. The warning message that I described is not a huge issue. Apparently if I built from a newer version of master it should fix itself. <jab>Specifically I need to build a use a never version of Mach. <jab>bjc: You can always use hurd.ion.nu It's an unofficial hurd wiki clone <bjc>this looks like exactly what i was asking for, thanks everyone <bjc>am i reading this right and tmpfs requires the pager to be running? <jab>bjc I know that tmpfs has some issues currently. I believe that it randomly forgets files... <bjc>back to the drawing board <jab>bjc: what are you trying to do ? <bjc>i was hoping to tmpfs mount /dev at boot time so i could work around some issues we're having with mounting / --readonly <bjc>for whatever reason, on guix, something is trying to open /dev/urandom before the filesystem is checked and remounted, and it causes everything to hang <bjc>debian doesn't have the issue, so it's something in guix, but tmpfs mounting /dev would have been an elegant solution to a number of problems <jab>bjc: your idea of "tmpfs mount /dev at boot time" might be an ok solution...I'm really not super technical with the Hurd stuff. Double check with a competent developer and/or email bug-hurd :) <jab>actually I might have your solution...just a second... <bjc>if you do, great! =) <jab>what about a ramdisk ? <bjc>but from my reading of tmpfs this isn't going to work without some major rework of booting or tmpfs itself <jab>I'm trying to find the specific wiki page... <jab>but basically I believe that you can create a reliable tmpfs with mount an ext2fs translator in RAM. <jab>it's slower and not as desirable...but it might work... <bjc>sounds very hacky, but might be worth it as a stop-gap <jab>oh it's probably very hacky! <jab>again, I'm a hurd user. Not a developer. You have been warned. :) <bjc>that's pretty clever if it works at boot <jab>I don't know that it will work at boot.... <bjc>i can give it a whirl and report back =) <jab>bjc: are you aware there is some upcoming code to make /dev better? <bjc>i am not aware, do you have a link? <jab>ie: right now, my Hurd shows /dev/wd0s[1-10] and I only have /dev/wd0s1, /dev/wd0s2, /dev/wd0s3. Maybe soon /dev/ will only report the SSD partitions that you actually have. <jab>let me find you that link. <jab>Samuel was actively asking people if they want /dev/hd0/1 or /dev/hd/0/1, so please do feel free to comment your opinions on the matter. <bjc>thanks, ill go have a look at it in a bit <bjc>hah. that ramdisk trick worked great <bjc>thank you so much. i don't think it would have ever occured to me to do that <azert>does anyone remember what is the exact issue with tmpfs? <azert>Probably something related to shared memory and ownership <gnucode>hmmm, I think we need an open_issues/web_browsers page. At present I know of only a few web browsers that work by default. emacs' eww, maybe lynx, and that odd lua web browser. I think it's luakit. <gnucode>bjc: the ramdisk worked!? That's awesome! <gnucode>I'm writing that one down as a win for the team! <bjc>well, it does work on a r/o filesystem, which is great <bjc>unfortunately, since it requires so many steps it won't work well for me <bjc>our issue is that, under some conditions, we never get to spawning runsystem. so any work in that area has to be done in c, and at that point it doesnt seem worth it anymore <gnucode>bjc: bummer. remind me what "runsystem" means in guix land. <bjc>better to just figure out why we're hanging where we are. somethin using /dev/random too early, but i don't know what <bjc>runsystem is a hurd thing <bjc>at the very end, after all essential services are up, startup calls console-run on libexec/runsystem <gnucode>are running into problems with quietboot ? aka the hurd's current bootstrap is failing (for some reason) and is not telling you what went wrong. <bjc>yeah, it's troublesome that way <gnucode>that's why I hope someone eventually codes serverboot v2. <bjc>i have some debugging output, but i don't know how to interpret a bunch of opaque integers <gnucode>you can always send an email to bug-hurd. <bjc>serverboot v2 is probably too far off to wait for <bjc>i'm fairly sure this is a guix problem. we mostly crib from debian, and debian works fine with /dev/random and urandom in place at boot <gnucode>Or weirdly enough, you could try claude...I think Brent spent $100 - $300 to find some really good bugs with our current SMP implementation. Maybe an AI can find the bug/problem for you. <gnucode>no pressure. Just offering a suggestion. <bjc>i have extremely serious ethical objections to those services that no amount of convenience will offset <sam_>i also really don't like people suggesting it <sam_>it's obvious people can use it if they want, i don't need to be told about it <sam_>(policies in projects and so on notwithstanding) <gnucode>I don't know that the Hurd has an AI policy. At least not a written one. <gnucode>We have an unwritten rule not to accept code from an AI...but I believe we bent that rule once for a trivial ai change. (1 or 2 lines). <gnucode>again, not trying to change your minds. <sam_>it's not about changing minds, i'd just rather not see it brought up to anyone who has a problem <gnucode>bjc: actually, does guix use debian's specific patches that are not in the source code ? <bjc>janneke knows more about that part of the build, i think. i've mostly been keeping to fairly small sections to solve immediate problems <gnucode>I'm just finding out that you sam_ and potentially bjc have a problem with it. :) <bjc>i don't find it useful to bring up on irc much, so i don't. i have, however, ranted a couple of times on the ml =) <gnucode>Well I am excited to see where guix hurd and gentoo hurd get. It's nice to have more Hurd distrubitions! <gnucode>oh, by the way...I may be the first person to use "ext3/4fs" on real hardware. <gnucode>I believe that I am using it right now. <bjc>can't e2fsprogs tell you? <gnucode>probably...I don't seem to have that installed at the moment... <gnucode>once luakit finishes installing, I'll take a look. <bjc>ah, it should be pre-installed. but i think i'm wrong anyway. i don't see any tools to investigate <janneke>guix is using quite some debian patches, notably for gnumach,hurd,glibc,rumpdisk, but also libacpica and others <gnucode>but the console is giving me a warning about something with the journal not properly flushing...according to "ext3/4fs" developer, that means that it's working, but I should use a newer GNU Mach. <janneke>espcially the glibc situation has been made quite a lot better the past years by the hurd developers upstreaming patches <gnucode>I kind of wonder how many of those patches are "crucial". And if and when they should be tidied up/fixed to get merged. Don't bother wasting time telling me. I could take a look myself. <gnucode>I did like the latest guix blog post by the way. <janneke>upstreaming patches to a project like glibc is not trivial, and many patches are/were quite unfinished, or workarounds <janneke>so it's really not fair to blame debian, they've been doing amazing work <bjc>man, we'd be so far behind without debian <janneke>also, i think that maybe guix doing more serious hurd work, has helped to encourage upstreaming <gnucode>janneke: I am excited that guix has a policy to run packages testsuites before shipping those packages to users. I imagine that when you all get around to running various packages testsuits, you'll find all sorts of hairy bugs. <bjc>this entire exercise of trying to fix up guix on hurd has been, for me, a very big and hairy yak <bjc>my actual goal has been to port a couple packages <janneke>ACTION is very glad you strayed a bit from that path ;) <bjc>had to. packages were too onerous to try to port without a decent dev environment <bjc>which means much shorter edit-build-test cycles <bjc>which means local tooling <bjc>it is really nice to watch it come together, though. i'll be very happy when ‘guix pull && guix system reconfigure config.scm && reboot’ works <janneke>esp after the 64-bit hurd effort, i'd been hoping that much of the hurd work in guix would be "just packaging" <janneke>but that might have been a bit optimistic <bjc>i need smp too, at some point =) <janneke>we've got a pull request in guix for that, but yeah, also undecided <bjc>i've tried with --enable-ncpus=8 and adding a few in qemu, but all it seems to do is make everything a lot slower <sam_>yeah, I had the same optimism <sam_>but it's not been so bad either <bjc>8gb should be enough for anyone <bjc>but how much extra does smp take? <janneke>on 32-bit, with 3 cpus (and 4GB) it gets slow, with 4 cpus it almost comes to a standstill <bjc>yeah, i saw that. i lowered to -smp 4, but it didn't help <bjc>it's only for some things i think. like startup seems to take a lot longer in the hand-off to runsystem <gnucode>I'm using 12GB or real hardware. :) I got the Debian installer to run on an Optiplex 7010 I think...that had 32 GB. <bjc>no working fsck means no real hardware for guix =( <bjc>getting pretty close on that, at least <gnucode>may I ask what's the difficulty on no working fsck on guix ? <bjc>the /dev/random thing i mentioned earlier is, i think, the culprit for the problems <gnucode>and hopefully "ext3/4fs" will help in that regard too. <bjc>something in early boot tries to use it, which makes the translator attempt to open the seed file rw, which causes everything to hang <bjc>if /dev/random doesn't have a passive translator on it, though, everything boots fine <bjc>so there's a workaround for that, but we can still end up unbootable if someone accidentally adds the passive translator back to that node for whatever reason <janneke>(and several chained previous issues) <gnucode>oh wow, I can actually read that in eww. <gnucode>I'm currently compliling netsurf from source. <sam_>this is something I had to workaround too and didn't get to come back to yet (we're far earlier on than the guix port, things work but it needs much polish) <gnucode>that's a nitpick for me personally. I wish Debian GNU/Hurd had a reliable web browser that was just one "apt install web-browser". <gnucode>But there's a couple of minor path_max issues with netsurf and dillo at the moment. <paculino>Could you be more specific? I am very slowly tinkering with dillo-plus, currently just working to document dependencies better and figure out making it a zim reader too. <paculino>I assume that the tweak to fix would be similar to the linux vs openbsd makefile tweak <gnucode>paculino: I'm assuming that you are asking me about why dillo and netsurf do not currently install easily on debian GNU/Hurd... <gnucode>and it's not a makefile issue. It's that netsurf (and dillo I belive) use PATH_MAX, which the Hurd does not define. <gnucode>It's actually really easy to compile netsurf from source. In 4 files, you just define PATH_MAX to some number. <gnucode>but that's not good enough to upstream to netsurf. <paculino>Path_max is defined similarly in dillo-plus <gnucode>thinking about this...I should probably just ask a netsurf developer if they wouldn't mind fixing the build for the Hurd. <gnucode>or I could try to write a simple patch to fix it.