diary at Telent Netowrks

Milestone 0 / Mildly stunned 1#

Tue, 20 Feb 2018 23:46:18 +0000

Since last week I added USB mass storage support and came up with a reasonably effective - I think - way to mount my USB hard drive when the disk appears.

This entailed rebuilding the kernel with usb-storage driver plus support for various kinds of filesystem and partition table I thought I might reasonably encounter, and then an inordinate amount of time poking through /sys and looking at kernel sources to find out why the disk still wasn't showing up. After girding my mental loins - hmm, that might be an image I could have lived without - in preparation for a deeply techy post about whatever subtle trick or obscure option was necessary to make it all work, a sudden flash of enlightenment led to the realisation that I simply hadn't copied the new kernel into the tftp server directory

Doh.

The only actual problem I found was that USB is hotpluggable, so devices are added to the system asynchronously and generally after the rc script has run mount -a, so just putting the disk in /etc/fstab doesn't work. Instead I am using mdev to get events when devices are added/removed, and causing it to run a monit command to start/stop monit "filesystem" services. This works for my use case (mounting a known filesystem in a known place) but wouldn't be much good for a more dynamic environment - e.g. automounting random USB keys on insertion. I don't think I want to do that anyway though, because security.

So the only thing I really still need to do for M0 is get this onto the original router. If it still works. (And yes, I am alert to the possibility that this may require shrinking the image a bit, somehow, just to get it into the WR-842's flash)

Faced with that tantalising glimpse of success I decided it was time to make matters more complicated: I would upgrade my nixpkgs installation to current master and see how badly it caused nixwrt to break. And the answer, dear reader, which I still find really quite surprising, is "almost not at all". I have a couple of PRs to add mips32 support and to make monit cross-compile, and really that's about all there is.

Current status: waiting for a git filter-branch thing to finish, because I would like to extract nixwrt from the wreckage of the nixpkgs it grew up in and make it point to a package collection somewhere else.

Configuratioration#

Wed, 14 Feb 2018 22:17:47 +0000

I apologize most humbly for missing my self-imposed Tuesday update deadline. This is because yesterday my phone stopped acknowledging the presence of either wifi or any form of mobile reception, making it somewhat useless as a communications device, and so I spent my allotted blogging time instead on fiddling with adb and fastboot and reflashing random new ROMs, making it not even boot - just as useless as a communications device, but additionally useless as a music player, games platform or even a flashlight. FTW!

Now running[*] on backup phone ...

This week I have mostly been rearranging things so that the configuration is separate from the mechanism, and am reasonably content with the result, at least as a starting point:

(In the picture: the development board for Milestone 0 and the victim^Wtarget device for Milestone 1, both sitting on top of the build host)

[*] "walking" or "crawling" might be better descriptors, Galaxy Nexus is a bit long in the tooth these days

Ssh!#

Tue, 06 Feb 2018 23:08:11 +0000

NixWRT somehow popped up on Reddit a couple of weeks ago, and I was besieged (not really) with questions like "which wireless community groups are using it?" and "is it better than OpenWRT?".

To which the answers are basically "nobody" and "no", right now, but it made me think a bit about where if anywhere this is all going and how fast it will get there, and in response I updated the README with some milestones/use cases

The good news is that I'm approaching the point where I can see what's left to attain M0. This week I have got it to boot and run an SSH server, and I have a rudimentary but not completely awful way to specify services - which run under monit, so will get restarted when they fail. Once I have decided how it's actually going to perform backups (don't know whether to just install rsyncd, or something fancy like unison or perkeep), and on the perhaps unlikely proviso that my target hardware device still even works then basically everything else is cleanup. I'm providing configuration points that accept attrsets instead of expecting the user to write text-based config format, and I've started work on extracting the generic nixwrt stuff from my local config (this is still ongoing)

Not a whole lot of war stories or weird random bugs this week, either.

In other news, beginning to think I might keep the NixWRT name. Partly because I haven't thought of a better one, but also - given that I'm using their kernel if not their build scripts or userland - as an acknowledgement of the work that goes into maintaining that project. I'm standing on the hipbones of giants.

Little Nix#

Wed, 31 Jan 2018 00:50:01 +0000

In short, because There is Little To Relate and the Hour Is Late:

I don't have much to expound on here because nixwrt has taken a back seat to $dayjob and family this week, The only things I feel I should point out (because Pages I Have Googled are by and large not very good at pointing them out) is that if you ever get a message

mount: mounting tmpfs on /run failed: Invalid argument

it may well be because you didn't enable CONFIG_TMPFS when building the kernel, and if you get

tmpfs: No value for mount option 'defaults'

then ... actually I don't know what the correct way to deal with this one is, but the pragmatic response is to edit /etc/fstab and replace defaults with rw. Works For Me.

Hopefully next week some actual news.

Userland? I monit, init#

Tue, 23 Jan 2018 23:58:57 +0000

[ ObTitleCommentary: sorry ]

This week really is not much more than the "there is no progress to report since last week but I am writing anyway just to maintain the weekly schedule" post I threatened last week

"The question is,", said Humpty Dumpty, "which is to be PID 1".

tl;dr I'm playing with the busybox init applet plus Monit run from an inittab entry. Haven't got very far yet: not had time.

Running the rootfs in ram

You may remember that a few weeks ago I was describing how I thought I ought to be able to use the MTD "phram" driver to download and use a root filesystem without having to write it into flash? For the record, it did work, it was just that the console bug made it impossible to test.

Well, it did work until I switched to the 4.9 kernel, in which the memmap= parameter has no effect, and even then it carried on apparently working for a while until I tried running a few more processes, and then I started getting filesystem corruption. Another one for the "obvious in hindsight" tally, when I checked the boot messages. So, I had to backport that code from 4.14

<6>Determined physical RAM map: 
<6> memory: 04000000 @ 00000000 (usable)
<6>User-defined physical RAM map:
<6> memory: 04000000 @ 00000000 (usable)
<6> memory: 00b00000 @ 01178000 (reserved)
<5>Kernel command line: console=ttyATH0 panic=10 oops=panic init=/bin/init phram.phram=rootfs,0x81178000,10Mi root=/dev/mtdblock0 memmap=11M$0x1178000 ath79-wdt.from_boot=n ath79-wdt.timeout=30 ethaddr=90:A2:DA:F9:07:5A machtype=AP121 mem=64M                                      

No time because ...

Because other things. One of them is that I'm moving my shell host from Debian to NixOS [*] and have been having fun with setting up email. Now running nixos-mailserver and fairly happy with it, but more on that subject forthcoming after I've refined my notmuch configuration a bit.

[*] Once upon a time it was running debian stable. Then while I wasn't looking it became oldstable. Then I did a dist-upgrade and that upgraded Puppet to a version that no longer understood my Puppet manifest and then I decided that it was time to start again