Null hypothesis#

Tue, 24 Apr 2018 22:39:25 +0000

When I blogged last week I left off at the point that syslogd and ntpd were not writing their pid files into /run.

Having basically no hypothesis[*] as to why this might be, I looked into building gdbserver and I looked into building strace and then I decided to try good old printf debugging first. To do this I wanted a slightly faster development cycle than having to build and tftp an entire image for each change.

Shared folders

It is probably fair to say I had never heard of the Plan 9 Filesystem Protocol (9P for short) before I started messing around wth Nix, but it turns out not only is it a Thing That Replaces NFS, but that it is a Thing which has client support in the Linux kernel and server support in qemu. So now I start qemu with some command rather like

qemu-system-mips  -M malta -m 128 -nographic -kernel malta/kernel.image \
 -virtfs local,path=`pwd`,mount_tag=host0,security_model=passthrough,id=host0 \
 -append 'root=/dev/sr0 console=ttyS0 init=/bin/init' \
 -blockdev driver=file,node-name=squashed,read-only=on,filename=malta/rootfs.image \
 -blockdev driver=raw,node-name=rootfs,file=squashed,read-only=on \
 -device ide-cd,drive=rootfs -nographic

where for the purpose of this blog post the interesting bit is the line starting with virtfs. This exports the current working directory such that inside the qemu VM I can mount it with

mount -t 9p -o trans=virtio,version=9p2000.L host0 /run/mnt

There is one weirdness that I've found, which is that trying to run a binary from from inside /run/mnt fails with Not a socket errors. I don't know why, but if I copy the same binary into /tmp it works fine. Don't ask me, because I don't know.

Anyway, this is all rather lovely because now I can build binaries - such as, for completely random example, a busybox executable with calls to fprintf(stderr, "here %s:%d\n", __FILE__, __LINE__) every four lines - and try them instantly in a running emulator wthout restarting anything. Doing this led me to the discovery that it's trying to open /dev/null as part of daemonising itself, and that that file is somehow mode 0660 instead of 0666. I took a guess (yes, ladies and gentlemen, the "null hypothesis" [*]) that this might make a difference, and turns out I was right. So, fix is to add an mdev.conf entry . It would be interesting to know why it makes a difference, considering that both of the daemons involved run as root, but I haven't really dug into it.

Change my switch up

In other news, after some experimentation with iproute2 and some more reconfiguring the kernel, I believe I might just understand how the builtin switch works and can do networking the Right Way (i.e. treat the WAN and LAN ports separately). But more about that in another thrilling installment.

[*] if you're reading this footnote for the first time, it's not just a lame joke it's foreshadowing an even worse one. See you again in about five paragraphs.