IRC channel logs


back to list of logs

<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)
<youpi>yes it only works there
<Viking667>hm. so how da heq do non-USAians get their keyboard to work outside of Xorg?
<youpi>I'm talking about variants
<youpi>layouts are supported
<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>(I haven't even tried starting up Xorg yet)
<youpi>it is there for layouts
<youpi>just not for variants
<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
<youpi>yes, see the readme files
<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>Well, I created the link, and now ‘df’ doesn’t show a warning anymore, though it seems the test still fails. It seems to be related to this issue in coreutils: <>
<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.)
<damo22>use the source, luke!
<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.
<damo22>that sounds like a glibc bug
<damo22>is readlink a syscall?
<zamfofex>I don’t know, I don’t think it is on Mach.
<damo22>check the debian glibc source
<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.
<damo22>probably in glibc
<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!)
<damo22>grep -r __lookup
<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>I’ve also been looking at <> but nothing seems to jump out as relevant to me.
<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*"
<damo22>you would see hurdlookup.c
<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>check the hurd source then
<damo22>youre getting there
<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
<damo22>gdb> r
<damo22>gdb> bt
<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
<damo22>run that in qemu
<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>gdb> frame 2
<damo22>gdb> p *result
<damo22>sorry frame 1
<zamfofex>‘$1 = 17099692’
<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
<damo22>it should just return an error?
<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>yeah probably
<damo22>id say __readlink itself should fail
<damo22>how do you tell if a file is a fifo?
<Viking667>check stat?
<Viking667>Does such a thing exist on Debian Hurd?
<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>hurd != linux
<damo22>__file_name_lookup cannot hang
<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>check the flags=65
<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>dig into what you have
<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
<damo22>sorry gtg
<zamfofex>Fair enough. Thanks for your help!
<youpi>zamfofex: I definitely recommend watching
<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
<zamfofex>I see! 🤔
<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>and ditto for readlinkat.c
<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>Debian does run tests
<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>builds never run 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
<Zopolis4>anyone have any idea why this happens?
<youpi>that's a sign the hurd console is stuck and thus doesn't consume kbd/mouse events
<Zopolis4>any idea why that happens? :p
<youpi>but gdb could tell
<Zopolis4>eh as it stands i get 2, maaaaaaybe 3 commands
<Zopolis4>before i have to reset the vm
<Zopolis4>thats really all i need
<Zopolis4>given how long everything takes in pure software anyways
<youpi>can't you set up ssh access?
<youpi>ssh port forwarding
<youpi>see readme files
<Zopolis4>blocked by firewall
<Zopolis4>6 commands though, new record
***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>I don't have such messages
<youpi>so that's probably related
<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
<Zopolis4>no the console does work
<Zopolis4>just not for long
<youpi>no, "console" means it's the mach console, not the hurd console
<youpi>so the mach console works
<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>oh, on windows
<youpi>no idea whether than can work fine
<Zopolis4>same issue on linux
<youpi>perhaps try with -m 2G
<youpi>to be sure
<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>the hard limit is 4G
<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.