<Viking667>Okay, I'm back. can't figure out how to get my freshly minted Debian Hurd into dvorak mode on console <youpi>Viking667: keyboard layout variants are not supported yet, contribution welcome ! <Viking667>I edited /etc/defaults/keyboard but I couldn't run setupcon (it complained about only working on Linux and FreeBSD) <Viking667>hm. so how da heq do non-USAians get their keyboard to work outside of Xorg? <Viking667>oookay. How come I can't use a variant then? <youpi>because it's not implemented <youpi>please read about xkb layouts vs variants <Viking667>I'm aware of what variants are, I had a tiny teeny little "battle" getting multiple layouts and variants to get working over on Linux. Is the underlying code not there for console logins? <Viking667>Hm. So I'm stuck with qwerty - haven't used that since 1999, I've got a bit rusty over the decades. <Viking667>well, haven't used that "long term" (i.e. longer than an hour) <youpi>you can ssh into the box to have your host support dvorak <Viking667>hm, so I'd have to get an IP I can use ... the Hurd's inside a VM <youpi>see the readme files about setting up ssh forwarding <Viking667>I'm on the same physical keyboard. The Hurd's inside a VM here on my machine. No need for ssh forwarding, just straight ssh connect. <zamfofex>Though I will note that the cross‐built ‘df’ (built on Linux for the Hurd) also hangs the same way. <iska>I think there's a funny ext2 bug <iska>If you mke2fs the root is owned by root <iska>if you chown the root I think it's impossible to remount (operation not permitted) <iska>so while running a subhurd is easy making one is hard <iska>though chowning the root also needs root >;) <iska>I basically did this to a big partition on my vm because I didn't know '-E root_owner' existed <iska>Linux mounts it just fine however <iska>nevermind, it's not an ext2 bug. Hurd just can't use the partition at all... <zamfofex>Seems like the problem is that it hangs when invoking glibc’s ‘canonicalize_file_name’ on a FIFO. <zamfofex>Now, I need to figure out *why* that happens! <zamfofex>(Or rather, on the pathname of a FIFO to be more accurate.) <zamfofex>Seems like the issue is with ‘readlink’. It seems like, for the Hurd, it invokes ‘__file_name_lookup’, which then eventually invokes ‘lookup’ from ‘<hurd/lookup.h>’, which then blocks. I’m trying to find where ‘lookup’ is defined. <zamfofex>So just invoking ‘readlink’ on the pathname of a FIFO is enough to get it to block. <zamfofex>I don’t know, I don’t think it is on Mach. <zamfofex>I’m not sure why I should check Debian’s glibc, but with ‘guix build --source glibc’, it really doesn’t look like it is a sycall. <zamfofex>As I said, it indirectly invokes ‘lookup’, and I can’t find where it is defined. <zamfofex>Yes, but where? I’ve been looking at ‘grep -r '\blookup\b'’, and I can’t see anything. I also tried ‘grep -r '^lookup'’ to no avail, and also other ways of trying to find it. (Maybe I’m just dumb, though!) <zamfofex>There are only five lines, all of which are ‘__lookup_riscv_flush_icache’. <damo22>maybe your glibc source doesnt have all the hurd patches? <damo22>i dont know if everything is upstream <zamfofex>Aha, I think I figured out *how* I’m dumb! It seems ‘lookup’ is a local variable (function pointer), and the actual function is called ‘__dir_lookup’. <damo22>glibc usually has filenames that include the function you are looking for <damo22>so if you just did find . -iname "*lookup*" <zamfofex>I had found ‘hurdlookup.c’ before, I just hadn’t noticed ‘lookup’ was a local variable (or parameter in that case, I suppose). <zamfofex>It seems ‘dir_lookup’ comes from Hurd, so it does seem like this is a Hurd bug, I think. <damo22>can you run gdb on the readlink command and then break into it and get a backtrace? <zamfofex>I don’t think I know how to do that. I never really learned how to use gdb. <damo22>gdb --args readlink /path/to/fifo <zamfofex>Ah. Well, there is no ‘gdb’ installed by default on Guix. And I can’t build it on the Hurd (because I haven’t bootstrapped coreutils yet), and there are no package substitutes (which is what I’m working on providing). Though thankfully, I think I know some Guix encantations to be able to install a cross‐built gdb from the official substitute servers. <damo22>really? you cant hack on hurd without gdb <zamfofex>It isn’t on the default packages of the OS declaration, though I should be able to add it before building the system image. But it’s easier to just install it to my user profile (in this case root) instead, I feel. <damo22>itd be easier to just download the debian img <zamfofex>Yeah, I suppose so. Though it isn’t difficult to install gdb or anything. And also, I’m unsure whether Debian has the same bug, unless they skip tests, I mean. (Because it would have been caught in the tests, I think.) <zamfofex>I assume there is more logging information, but I don’t know how to get it to show it. <damo22>ok so you need to figure out: is __readlink supposed to continue to call __file_name_lookup or is it a bad thing to do on a fifo? <damo22>or is the bug further down the chain <damo22>or maybe the bug is in __dir_lookup <zamfofex>I don’t understand what the lookup functions are meant to be doing. <damo22>i believe they get a port to the file <damo22>but reading a symlink operation should not work on a fifo <zamfofex>Ah, I see! So the ‘lookup’ functions are similar to ‘open’, except that lower‐level, then? Because ‘open’ is meant to block on a FIFO until a corresponding ‘open’ is called on it by a different process or thread, I’m pretty sure. <damo22>id say __readlink itself should fail <damo22>how do you tell if a file is a fifo? <zamfofex>It seems to be currently using ‘__io_stat’ on the return value of ‘__file_name_lookup’. <damo22>ok so if file_name_lookup is the only way to get a port to look up stat on the file, then readlink has to get a return value from there <damo22>so __dir_lookup needs to handle it <zamfofex>Though just calling ‘stat’ from C on a FIFO works, so I think it’d be worthwhile to verify how it does it. <zamfofex>It seem like it just invokes ‘__file_name_lookup’ too, so now I’m just kinda confused. <damo22>because its return value is needed to call __io_stat and figure out if its a fifo <damo22>it smells like a bug in __dir_lookup <zamfofex>Hopefully this is clearer: Maybe I’m wrong, but I think I was able to run a C program on the Hurd with ‘stat’ invoked on a FIFO’s pathname, and I think it didn’t block. Since stat uses ‘__file_name_lookup’, that ought to mean it didn’t block then. <damo22>readlink is calling file_name_lookup with those flags <zamfofex>‘stat’ invokes it as ‘__file_name_lookup (file, 0, 0)’ <damo22>readlink is ending up in a pathway where it calls dir_lookup <damo22>you keep showing me alternatives <damo22>your backtrace says readlink is calling file_name_lookup ("fifo", 65, 0) <damo22>find out what flags they are and dig into __dir_lookup <damo22>it probably needs to call file_name_lookup(file, 0,0) and then stat the file and make sure its not a fifo before opening it properly? <damo22>maybe that is better done inside readlink <zamfofex>I found that ‘dir_lookup’ is declared in ‘hurd/fs.defs’, though I can’t seem to figure out where it is defined. I also don’t know how it relates to ‘__dir_lookup’. <damo22>usually there are alias symbols __blah <-> blah <zamfofex>Yeah, I figured. It’s likely the case here too, though I’m not 100% sure yet. <damo22>why does dir_lookup need to care if the file is a fifo? <damo22>shouldnt that be handled further up <youpi>and reading the .defs files to know what an RPC call is supposed to do <youpi>readlink on a fifo on debian also blocks indeed <youpi>perhaps glibc's readlink.c should pass O_NOTRANS to avoid getting caught into the fifo behavior when opening it <youpi>stat64.c doesn't have the issue because it doesn't pass O_RDONLY, so the fifo won't stall trying to read <youpi>(readlink.c should probably be made to just call readlinkeat with AT_FDCWD actually) <zamfofex>Does Debian not run tests? Or does it skip that test? <youpi>why that test didn't get caught, the source will tell you <zamfofex>Does Debian run the builds/tests as root? Because I think that test is skipped if ran as root. <youpi>but some pieces may run in fakeroot <youpi>I don't think tests run in fakeroot by default <youpi> # tests fail a lot on the buildds <youpi>see, the source is always righ <youpi>probably, using O_NOTRANS will have the unwanted effect of not following hardlink translation, so perhaps we'd rather make readlink first make a file_name_lookup with flags O_NOLINK, and make another file_name_lookup with O_READ | O_NOLINK inside the S_ISLNK test <youpi>something like that, to be tested <Zopolis4>on qemu, i seem to get a certain amount of keyboard and mouse inputs before i get kbd: queue full and mouse: queue full <youpi>that's a sign the hurd console is stuck and thus doesn't consume kbd/mouse events <Zopolis4>eh as it stands i get 2, maaaaaaybe 3 commands <Zopolis4>given how long everything takes in pure software anyways <youpi>can't you set up ssh access? ***Emulatorman_ is now known as Emulatorman
<Zopolis4>maybe it has something to do with this: /bin/console: Could not receive return value from daemon process: Connection timed out <Zopolis4>although theres a lot of messages like that while booting <youpi>just to be sure, what do you exactly have as prompt at login ? Debian GNU/Hurd bookworm/sid hurd console <- console or tty1 ? <Zopolis4>Debian GNU/Hurd bookworm/sid hurd console <youpi>so the hurd console is not actually running and you are at the mach console <youpi>you can as well just tell your distrib not to start the hurd console <youpi>since apparently it's getting stuck and everythinhg <youpi>no, "console" means it's the mach console, not the hurd console <youpi>but since the hurd console is acting weird, it ends up locking the mach console <youpi>so you can just not start the hurd console <youpi>and work with the mach console <youpi>you'll just not have virtual terminals <Zopolis4>how do i not start the hurd console then <youpi>but at least you'll have a way to set up ssh, and then be able to debug the hurd console startup issue <youpi>as I said, tell your distrib not to <youpi>you didn't tell which distrib you are using so I can't tell <Zopolis4>im just using the debian hurd qemu image reccomended <youpi>I'm surprised that you get an issue then, never had such <youpi>anyway, with debian it's as usual with debian: update-rc.d hurd-console disable <youpi>I'm really curious how exactly you started the image with qemu, that's really not something I've ever seen there <Zopolis4>qemu-system-x86_64.exe -m 6G -drive format=raw,cache=writeback,file="C:\Users\user\3D Objects\debian-hurd-20220824.img" <youpi>no idea whether than can work fine <Zopolis4>lemme complete this boot cycle and get in a command then ill try <Viking667>I brought up a Hurd using qemu-kvm on Linux, seemed to at least boot. The only issue I've had so far has been the lack of support for keyboard variants. <iska>Zopolis4: try using i386 and 4gb of memory <iska>that's the most the image supports <iska>does Hurd just not support 4G of ram? <iska>I deleted the swap partition, rebooted and it still shows 3G <iska>Though I didn't disable an init script for swap <youpi>iska: without 64bit support, it's hard to support more than 3G <iska>youpi: ahh so it's 3G limit <youpi>but then you have kernel/user space split <zamfofex>youpi: Ought that patch be submitted to glibc, then? Meanwhile, I suppose it might make sense to add it to Guix, I think. 