IRC channel logs


back to list of logs

<Steap>ArneBab_: you should probably remove the reference to "refresh" in your blog article, it's confusing
<ArneBab_>what would I give instead?
<civodul>ArneBab_: "guix pull" = "apt-get update"
<civodul>whereas "The primary audience of the ‘guix refresh’ command is developers of the GNU software distribution."
<ArneBab_>ah, ok
<ArneBab_>so guix refresh → change the package list, guix pull → update to the latest checked package list?
<civodul>"Installation is straightforward, except if you follow the docs" :-)
<ArneBab_>they horribly confused me :)
<civodul>guix pull downloads the latest Guix source code and package descriptions, and deploys it
<civodul>ArneBab_: we need to know that
<civodul>otherwise that's unlikely to improve!
<ArneBab_>(maybe because I thought “if I can run it as user except for this small 300 line program, then I’ll do it”
<ArneBab_>civodul: that’s why I posted here :)
<civodul>but make sure to email guix-devel or bug-guix with info about what you found confusing
<civodul>or even suggestions/patches :-)
<ArneBab_>that’s not as easy as writing up a simpler tutorial while following it myself :)
*ArneBab_ should already sleep (tomorrow work starts again), but wanted to finish that simpler tutorial.
<ArneBab_>(besides: feel free to use the org-mode file in the article if you think it could help.
<ArneBab_>(I was happily surprised to see the Guix readme written in org-mode :) )
<civodul>see you!
<mark_weaver>thanks ArneBab_!
<civodul>yes, thanks!
<ArneBab_>(I think the main point of confusion was that the docs are much more detailed than needed for a new user)
<ArneBab_>thanks to you!
<mark_weaver>I've gotten quite impatient for bootable Guix. I might have to take a break from Guile to work on that.
<civodul>ah ah, that'd be nice :-)
<civodul>mark_weaver: i'm currently having troubles with mingetty
<civodul>it does:
<civodul>ioctl(3, TIOCSCTTY, 1) = -1 EPERM
<civodul>and then bails out
<mark_weaver>is it being run as root?
<mark_weaver>mingetty, that is?
<civodul>the search string is "no controlling tty: Operation not permitted" ;-)
<civodul>but i haven't found any clue
<mark_weaver>does dmd do anything funky with Linux capabilities?
<mark_weaver>tty_ioctl(4) says: "If this terminal is already the controlling terminal of a different session group then the ioctl fails with EPERM, unless the caller is root (more precisely: has the CAP_SYS_ADMIN capability) and equals 1, in which case the terminal is stolen, and all processes that had it as controlling terminal lose it."
<mark_weaver>it's pid 1 also, I assume?
<mark_weaver>oh, no it isn't, of course.
<civodul>mark_weaver: that's without dmd currently
<mark_weaver>so I guess that's probably the issue. the terminal is already the controlling terminal of a different session group.
<civodul>i confess i don't quite get what that means...
<mark_weaver>do you know the concept of controlling terminals?
<civodul>not really
<mark_weaver>see setsid(2)
<mark_weaver>well, I guess that doesn't explain very well. let me see if I can find a good description.
<civodul>i found
<mark_weaver>basically, it's about job control.
<mark_weaver>I'm a bit rusty on the details, but basically when a terminal device gets Ctrl-C (or Ctrl-Z, etc), it sends the signal to all processes in the session group.
<mark_weaver>and when the terminal disconnects, SIGHUP is sent, ec.
<mark_weaver>so the idea is, you call 'setsid' and that starts a new session group. and all subprocesses will be part of that session group.
<civodul>yes, i see
<civodul>lemme experiment...
<mark_weaver>I guess there's some job that needs to be done by PID 1 here, at least for the linux console TTYs.
<mark_weaver>well, maybe not. maybe this is just because you're trying to run mingetty on a terminal that already has a session group, which might not normally happen during startup.
<mark_weaver>oh wait. PID doesn't have to be 1. 'arg' has to equal 1. (for some reason that underlined 'arg' didn't get pasted)
<mark_weaver>what is arg? hmm.
<mark_weaver>maybe 'arg' is simply a flag that enables this "stealing" behavior.
<mark_weaver>so maybe the answer is simply to kill all the processes that were associated with that terminal, before running mingetty.
<civodul>actually, from a Guile there, i did (setsid) and then (execl "mingetty" ...), and that worked
<mark_weaver>ah yes, it does mention that it has to be a session leader.
<mark_weaver>so maybe it's assuming that the setsid will be done by init, before running mingetty.
<civodul>yes, something like that
<mark_weaver>(setsid makes the current process a session leader)
*mark_weaver looks at the mingetty source
<mark_weaver>yeah, I couldn't find 'setsid' in the mingetty source code.
<mark_weaver>I suspect that 'init' is supposed to call 'setsid' every time is execs something.
<mark_weaver>s/is execs/it execs/
<mark_weaver>anyway, I'm glad you got it working :)
<civodul>i'll commit what i have so you can try & improve :-)
<civodul>wonderful: it gets to the login prompt, and then barfs
<civodul>there's no /etc/passwd, no /bin/sh, so i guess it feels unhappy
<civodul>anyway, that's a start
<mark_weaver>if we could even get to the point of an extremely crude boot system, it would be easy to incrementally improve.
<mark_weaver>civodul: sounds good!
<mark_weaver>sleep well :)
<civodul>thanks, good day to you ;-)
<mark_weaver>hi civodul!
<mark_weaver>do you happen to know off hand how to redirect the serial port within a guest to the qemu console on the host, without -nographic? I want a graphical display for mingetty to run in, but I also want a serial port so I can see the full kernel panic.
<civodul>Hello Guix!
<civodul>mark_weaver: yes, "-serial stdio"
<civodul>and then add "console=ttyS0" for the kernel
*mark_weaver just learned that mingetty can't be used on serial ports :)
<civodul>(in GRUB)
<mark_weaver>yep, I got both of those.
<civodul>for debugging i also got the image to start Bash instead of mingetty
<civodul>otherwise it could be hard ;-)
<mark_weaver>yeah, I was thinking about including gdb in there too, but the initrd is getting kind of big.
<mark_weaver>ooc, when you run this test image in qemu, what other options do you typically pass to qemu?
*mark_weaver is a newbie at qemu
<mark_weaver>e.g., I'd like to make my host's /nix/store available to the guest, ideally
<mark_weaver>and I wonder what --root=/dev/vda1 is supposed to map to in this case. maybe I'm not giving it what it needs.
<mark_weaver>(I can figure all this out with time, but maybe you can save me some, if you're willing)
<Arne`>Steap: I cannot ^C the daemon, when I run it via initscript.
<mark_weaver>btw, on my system, building the derivation returned by (example2) randomly crashes the guest kernel while it tries to reboot, about 1/4 - 1/2 of the time.
<Arne`>taylanub: The best initsystem I know is the one of the Hurd. Because it just uses translators: When you access a device you need via the filesystem, the necessary services get started.
<Arne`>taylanub: Though I like OpenRC: It just works.
<mark_weaver>it seems silly to me that each daemon should come bundled with a separate command that kills the daemon. IMO, that's should be the job of the init system.
<Arne`>If guix had a proper Gentoo-ebuild, I’d agree. … maybe I can reuse the start-stop-daemon in my local.d/guix-daemon.start/*.stop
<mark_weaver>Arne`: Maybe we can find a volunteer to make a proper ebuild for Guix :)
<Arne`>But why shouldn’t there be a way to tell the daemon to shut down?
<Arne`>The daemon already listens for commands, so one command could be “quit now”.
<mark_weaver>I think it's poor design to duplicate that functionality in every daemon. it can be done just once, in a proper init system, and then there's no needless duplication.
<mark_weaver>all the systems I'm familiar with have something like that.
<mark_weaver>debian, ubuntu, fedora, and more generally systemd and upstart, all have it.
<Arne`>Gentoo also has it, but that means that I have to replicate the functionality in every distro I use.
<Arne`>One key advantage of using Guix is for me, that I can create a kind of personal-overlay which I can take with me when I should have to switch distros.
<Arne`>Or to give it to colleagues without having to find out how to do it in their distro.
<mark_weaver>one problem with implementing a "quit now" command in the daemon is that unprivileged users would be able to shut down the system build daemon, leading to denial of service for the other users.
<Arne`>I’ve long been searching for a way to install something in all possible distros.
<Arne`>that’s true, yes.
<Arne`>… as long as it’s not a single-user system, that would mean, that the daemon would have to have a way to identify the priviledged user, and that sounds like a bit too much…
<mark_weaver>hmm. among other things, I'm seeing this when Guile loads in the initrd:
<mark_weaver>GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
<mark_weaver>that worries me, and I wonder why it's happening.
<mark_weaver>I modified the 'boot' script to fork before exec'ing mingetty, and for the parent (PID 1) to wait for mingetty to finish.
<mark_weaver>after mingetty crashes, Guile crashes while trying to print a backtrace, with: "Exception thrown while printing backtrace: ERROR: In procedure module-lookup: Unbound variable: frame-arguments"
<mark_weaver>oh, nevermind, I see that the Guix linux-initrd code already forks.
<mark_weaver>I seem to be fumbling around here :-(
*civodul is back
<civodul>mark_weaver: sharing the host's store is possible, but with qemu-with-multiple-smb-shares
<civodul>that's what is used by expression->derivation-in-linux-vm
<civodul>but qemu-image copies things, because the end goal is to have a stand-alone image
<mark_weaver>ah, thanks!
<mark_weaver>What do you make of the GC warning I quoted above?
<civodul>and the GC warning in the initrd is OK, don't worry ;-)
<civodul>yeah, that's fine
<civodul>it's just that at the beginning there's no /proc, and libgc likes /proc
<civodul>but it can live without it (when compiled with with USE_LIBC_PRIVATES)
<civodul>as for the Guile crash, see the comment in gnu-system-initrd
<civodul>basically, we're not allowed to crash ;-)
<mark_weaver>in the generated qemu image (from example2), what does --root=/dev/vda1 end up mounting? do I have to add a command line option to qemu to map that to something?
<mark_weaver>more generally, are there command line options that I should be passing to qemu to run this image properly?
<civodul>mark_weaver: --root is interepreted by the initrd
<civodul>and /dev/vda1 basically means the QEMU image itself
<civodul>the one passed with -hda on the qemu command line
<civodul>i run it like this:
<civodul>qemu-system-x86_64 -serial stdio -net nic,model=e1000 -net user,smb=$PWD -hda t.img
<civodul>but the only important option is -hda
<mark_weaver>ah, thanks!
*mark_weaver has been doing it wrong :)
<mark_weaver>will the initrd handle mounting the host's $PWD somewhere automatically?
<civodul>you have to do (configure-qemu-networking) and (mount-qemu-smb-share ...)
<civodul>as done in qemu-initrd
<mark_weaver>given the qemu command line you gave above, what should be the first argument to 'mount-qemu-smb-share' ?
<civodul>/qemu, IIRC
<Arne`>mark_weaver: I now have clean local.d/guix-daemon.start/*stop scripts for Gentoo. Where can I post them?
<mark_weaver>Arne`: I don't know, maybe I'm only marginally involved with Guix, so I'm not the best person to ask such questions.
<mark_weaver>though it seems to me that the one person who really needs to see it is whoever creates a Gentoo ebuild for Guix.
<mark_weaver>civodul: I'm having trouble mounting the SMB share. I passed "-net user,smb=/nix" to qemu. Within qemu, I did (configure-qemu-networking) and (mkdir "/root/host-nix") and (mount-qemu-smb-share "/qemu" "/root/host-nix"), and I get: "ERROR: In procedure mount: No such device". Any ideas?
<mark_weaver>oh, I just realized I wasn't running the qemu from Guix, but rather the one from debian.. maybe that's the problem. let me try.
<mark_weaver>well, same problem with the qemu from Guix.
<civodul>hmm, problems? :-)
<civodul>i seem to lose the connection when people discuss problems
<mark_weaver>I'm unable to mount the host smb share.
<mark_weaver>I passed "-net user,smb=/nix" to qemu. Within qemu, I did (configure-qemu-networking) and (mkdir "/root/host-nix") and (mount-qemu-smb-share "/qemu" "/root/host-nix"), and I get: "ERROR: In procedure mount: No such device". Any ideas?
<mark_weaver>(I used the same qemu command line you recommended above, using qemu-system-x86_64 from Guix)
<mark_weaver>except that I replaced $PWD with /nix
<mark_weaver>(I replaced --load=... with --repl in the linux command line, and exited the first REPL to get to the second one)
<mark_weaver>well, I need to sleep now anyway, so we can pick this up again later.
<mark_weaver>maybe I should just use 'qemu-with-multiple-smb-shares', since that obviously seems to work.
<mark_weaver>hmm. can't get that to work either.. :-(
<mark_weaver>oh, maybe I haven't yet loaded the needed modules...
<mark_weaver>ah yes, that must be the problem. and the needed modules haven't been copied to the initrd. well, at least now I know :)
<mark_weaver>okay, time for sleep. good night!
<mark_weaver>or good morning to you, I suppose :)
<civodul>"No such device" could be because the SMB share wasn't found
<civodul>normally qemu launches smbd (Samba) as needed
<civodul>but i think it looks for it in $PATH
<civodul>so you may have to install it first
<mark_weaver>well, in this case, the needn't modules weren't loaded, and weren't present in the initrd.
<civodul>aah, right
<civodul>qemu-initrd loads them, but not gnu-system-initrd
<mark_weaver>I see what needs to be done, but now it's time for sleep :)
<civodul>ok :-)
<civodul>good night!
<mark_weaver>hopefully Il
<mark_weaver>hopefully I'll eventually become more useful than I've been in the last hours :)
<civodul>heh :-)
<civodul>well, all this is quite messy still
<civodul>so it's not your fault ;-)
*mark_weaver --> zzz
<mark_weaver>hi civodul!
<civodul>hey, mark_weaver
<mark_weaver>I added the modules to the initrd, and it got a little farther but still failed to mount the smb share.
<civodul>the /qemu share?
<mark_weaver>this time, it said: "CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 3.3" and "CIFS VFS: cifs_mount failed w/return code = -6".
<mark_weaver>well, I was using qemu-with-multiple-smb-shares, so I tried to mount both /store and /xchg. they both failed.
<civodul>and you did have smbd around?
<mark_weaver>ah yes, that's right, it didn't run smbd. I'd forgotten that. (I did the test last night)
<mark_weaver>but it seems to run smbd when it's building the image.
<mark_weaver>in fact, it certainly does. I saw it in "ps" output.
<civodul>well it does work because that's what 'expression->derivation-in-linux-vm' uses ;-)
<civodul>now i wonder what could differ
<mark_weaver>but not when I run it directly.
<civodul>and is smbd in $PATH?
<mark_weaver>I'm sure I can figure it out with time, but thought I'd check with you in case you had an easy idea.
<civodul>nothing comes to mind currently
<mark_weaver>ah, indeed it isn't! strange, I did "guix package -i samba"
<civodul>maybe it's in sbin?
<mark_weaver>thanks :)
<civodul>you're welcome :-)
*mark_weaver tries again...
<mark_weaver>*grump* smbd was started this time, but it's still not working :-(
<mark_weaver>well, I'll figure it out. it just takes time...
<civodul>you're mounting with "guest,sec=none", right?
<mark_weaver>I'm just using 'mount-qemu-smb-share', as found in qemu-initrd. how do I specify those flags?
<civodul>ah it does specify them already
<civodul>what's the error this time?
<mark_weaver>same as I wrote above: "CIFS VFS: cifs_mount failed w/return code = -6".
<mark_weaver>(after the "default security mechanism requested" warning)
<civodul>and networking works correctly?
<civodul>you can boot with --repl to fiddle with all this ;-)
<mark_weaver>I'm in a REPL right now.
<mark_weaver>(I used grub interactively to change --load=... to --repl)
<civodul>ok, so you do have networking?
<mark_weaver>good question. I'll check.
<civodul>can you (getaddrinfo "")?
<civodul>or .4, even
<mark_weaver>(getaddrinfo "") => (#(0 2 1 6 #(2 167772675 0) #f) #(0 2 2 17 #(2 167772675 0) #f) #(0 2 3 0 #(2 167772675 0) #f))
<mark_weaver>similar for .4, but with those large integers incremented.
<civodul>QEMU is running with -smb /foo, right?
<mark_weaver>exact command: /nix/store/afdw1dj51js0dqxiw3b9hhs130qw0lsk-qemu-with-multiple-smb-shares-1.5.1/bin/qemu-system-x86_64 -serial stdio -net nic,model=e1000 -net user,smb=$PWD -hda guix-image-1
<civodul>can you "strace -f -p $(pidof qemu-system-x86_64)", then call mount-qemu-smb-share at the REPL, and check whether/how smbd is invoked
<mark_weaver>the smbd's are already running.. (two of them)
<mark_weaver>presumably one for each share.
<mark_weaver>will it run another command when I try to mount?
<civodul>ah, no, i don't think so
<civodul>can you check their command line?
<mark_weaver>will the smbd logs go somewhere I can see?
<civodul>perhaps you can strace smbd to see whether they receive something
<mark_weaver>I looked at the "multiple-shares" patch, and it looked like qemu was creating a configuration file for smbd.
<mark_weaver>any idea where those config files end up?
<mark_weaver>I'll strace the smbd
<mark_weaver>(good idea)
<civodul>in /tmp IIRC
<mark_weaver>indeed, and in the config where the logs go too... looking...
<mark_weaver>hmm, the log file was never created.
<mark_weaver>I'll strace the smbd
<mark_weaver>btw, I'm running qemu as 'mhw'. is that okay?
<mark_weaver>attempting to mount the share caused activity in the smbd. looking closer now.
<mark_weaver>the log is ending up in /var/log/samba/log. and in that log, it shows that it's trying to stat /var/lib/samba/usershares/store
<mark_weaver>I think it might be picking up one of my global samba configs from debian
<mark_weaver>but I have only Guix paths in my shell PATH, when I run qemu
<civodul>i don't have /var/lib/samba
<mark_weaver>also, I set all the environment variables according to the recommendations made by "guix package -i"
<civodul>that should be OK
<mark_weaver>nonetheless, 'expression->derivation-in-linux-vm' works for me.
<mark_weaver>but I guess that's being run by the guix-builder, so maybe in a better environment.
<civodul>do you have Samba installed from Debian?
<civodul>could it be picking that one?
<mark_weaver>I guess probably so, despite my restricted PATH
<mark_weaver>yes, of course, ps shows: "/usr/sbin/smbd -D"
<mark_weaver>now to figure out how 'qemu' looks for smbd...
<mark_weaver>I guess it probably has some hardcoded paths to look for it, and the 'chroot' of the builder environment avoids that problem.
*mark_weaver looks in the qemu manual for a way to specify which smbd to use.
<mark_weaver>I guess this should be fixed in Guix's qemu package.
<civodul>in Guix, QEMU is configured with --smbd=.../bin/smbd
<civodul>so it should not be referring to /usr/sbin/smbd
<mark_weaver>well, I'm definitely running the qemu from guix, and yet it's launching /use/sbin/smbd
<mark_weaver>I think I'll have to dig into the qemu source to find this answer.
<civodul>i'm actually running qemu from NixOS, when i run it by hand
<civodul>because ours lacks graphical support
<mark_weaver>I just noticed, those smbd daemons have been running since Aug 25
*mark_weaver killed them, trying again.
<mark_weaver>civodul: qemu is launched smbd, but afaict, smbd doesn't live very long, and doesn't leave behind any log.
<mark_weaver>qemu is launching the correct Guix smbd, is what I mean.
<mark_weaver>(verified by strace)
<mark_weaver>or if it is running, its command line is obscure enough that I can't find it easily.
*civodul feels clueless
<mark_weaver>I have qemu running in strace now, and I stopped it (it was obviously very slow and generating a huge trace)
<civodul>yeah it doesn't like running in strace
<civodul>it's better to attach strace at the last moment
<mark_weaver>well, I wanted to see it launching the smbd
<mark_weaver>actually, now I'm not so sure it has launched the smbd. I see where it calls "access" on it, and then where it creates the /tmp/qemu-smb.*" directory and generates the config file.
<mark_weaver>and then I see a clone not long after, which I assumed was the smbd, but now I think it isn't.
<mark_weaver>maybe it launches it lazily?
<civodul>yes, i think so
<civodul>that's why i think you can attach strace at the last moment
<mark_weaver>okay, I'll try again.
<mark_weaver>it worked!! :)
<mark_weaver>so I guess it was just those old debian smbd's that were messing things up.
<civodul>well, good that it works!
<mark_weaver>they were presumably launched when I ran Debian's qemu a few days ago by mistake, instead of the one from Guix.
<civodul>but it's really annoying that QEMU/smbd can't better report what's going on
<mark_weaver>okay, now I have a copy of gdb to use
<civodul>i'm working on generating /etc/shadow
<civodul>but i guess i'll soon go to bed, so you'll be able to continue during the night shift ;-)
<civodul>i have a "store monad" around also, to make things nicer to write
<civodul>it feels like the right way to do things
<Steap>Noobie question here, but I really don't think I can easily DuckDuckgGo "Guile %": what does (define %foo ...) mean ?
<civodul>Steap: it's a naming convention
<mark_weaver>% is just a normal character, like A or B
<Steap>what's it used for ?
<civodul>it's used in some circumstances :-)
<Steap>What's the convention here ?
<mark_weaver>by convention, it usually indicates something sort of "internal"
<civodul>for global variables, system things, internal things
<civodul>that sort of things
<civodul>sometimes people use stars, like *foo*
<mark_weaver>many (most?) of the ASCII symbols are treated just like letters by Lisp/Scheme.
<Steap>I suppose nobody would be crazy enough to use a leading underscore to show that something is meant to be "internal" :)
<mark_weaver>that's a C convention, probably because they have so few non-alphanums to work with.
<mark_weaver>I'm not sure it's a good choice, but it's what most people are used to anyway.
<civodul>actually one of the relevant standards says that C identifiers with a leading underscore are reserved "for the system"
<mark_weaver>de gustibus non est disputandum
<civodul>oh, nice one :-)
<Steap>civodul: really ? People often use that in C, while a double underscore is reserved for the libc, iirc
<civodul>well, but that's the way it is
<civodul>and identifiers starting with 'E' are reserved, too (!)
<civodul>(for errno values)
<mark_weaver>civodul: really? wow.
<mark_weaver>that's news to me :)
<civodul>yeah :-)
<civodul>youpi (of GNU/Hurd) has all sorts of stories about that
<civodul>because glibc on GNU defines 'ED', just for a joke
<civodul>and that happens to break a number of packages
<civodul>so, this is all very dirty and still doesn't work
<civodul>but that'll improve
<civodul>it will have to ;-)
<civodul>anyway, good night/day!