IRC channel logs

<Steap>ArneBab_: you should probably remove the reference to "refresh" in your blog article, it's confusing

<Steap>imho

<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>:-)

<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 :) )

<ArneBab_>cu

<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>hmm

<mark_weaver>is it being run as root?

<mark_weaver>mingetty, that is?

<civodul>yes

<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 http://en.wikipedia.org/wiki/POSIX_terminal_interface#Controlling_terminals_and_process_groups

<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.

<civodul>ok

<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"

<mark_weaver>thanks!

<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`>:)

<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

<mark_weaver>okay

<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>nope

<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

<mark_weaver>thanks!

<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 guix-devel@gnu.org? 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

<civodul>:-)

<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>yeah

<civodul>qemu-initrd loads them, but not gnu-system-initrd

<civodul>heh

<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>:)

*mark_weaver --> zzz

<civodul>howdy!

<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>ah

<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>hmm

<civodul>and you did have smbd around?

<civodul>ok

<mark_weaver>ah yes, that's right, it didn't run smbd. I'd forgotten that. (I did the test last night)

<civodul>ok

<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>indeed!

<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>argh

<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>ok

<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?

<civodul>yeah

<mark_weaver>good question. I'll check.

<civodul>can you (getaddrinfo "10.0.2.3")?

<civodul>or .4, even

<mark_weaver>(getaddrinfo "10.0.2.3") => (#(0 2 1 6 #(2 167772675 0) #f) #(0 2 2 17 #(2 167772675 0) #f) #(0 2 3 0 #(2 167772675 0) #f))

<civodul>good

<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>ok

<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>dunno

<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?

<civodul>yes

<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.127.0.0.1. 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>oh

<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>hmm.

<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>hmm

*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.

<civodul>yes

<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>blech

<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

<mark_weaver>indeed

<civodul>good

<civodul>i'm working on generating /etc/shadow

<mark_weaver>cool!

<civodul>but i guess i'll soon go to bed, so you'll be able to continue during the night shift ;-)

<mark_weaver>hehe

<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>oh

<civodul>yes

<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

<Steap>thanks

<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

<mark_weaver>heh

<Steap>funny

<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!

IRC channel logs

2013-09-05.log