NixWRT - Using nix to build firmware images for consumer router hardware

[telent]

NixWRT is an experiment to see if Nixpkgs is a good way to build an OS for a domestic wifi router of the kind that usually run OpenWRT or DD-WRT or Tomato - typically embedded MIPS SoCs.

I’ve plugged it once or twice on the mailing list and in IRC, but as this weekend I’ve finally got it to the point where it’s live and performing useful work backing up my home desktop, I put together a quick FAQ describing what it is, why it exists and what it’s currently useful for.

[zimbatm]

Good stuff!

What are you looking for to get back from the community, is there a place where you assemble and discuss the project?

[telent]

There’s a good question!

I suppose that right now all I’m really looking from the community is to know it exists, so that anybody who may have been contemplating doing something similar can see what’s been tried already - and maybe to contribute if they think our objectives are compatible - instead of starting from scratch. There isn’t really any discussion happening anywhere outside of my own brain right now, but the obvious place to start one would be to open an issue or a PR on the github repo

[Mic92]

Do you also indent to implement it like the NixOS module system? A the moment it looks like you are building NixWrt as a package: https://github.com/telent/nixwrt/blob/nixwrt/nixwrt/rootfs-image.nix

[zimbatm]

@telent how big are the resulting images?

There is some partial support for musl libc support in nixpkgs that could make your images much smaller if you are not using it already. Once NixWRT gains some maturity it could also be a good motivation to get the RFC merged in or at least expand the surface of musl-supported packages.

[telent]

ls says about 6.4MB for the full firmware image, comprising 2M for the kernel (hmm, not sure why that’s grown so large, it was 1.4MB or so last time I was paying attention) and the rest for the compressed root fs. It’s already using musl: I was pleasantly surprised (bordering on stunned) to find how easy it was to switch.

[dan@loaclhost:/srv/media]$ ls -lh /tftp/    
-r--r--r-- 1 dan users 6.4M Jan  1  1970 firmware.bin                                     
-r--r--r-- 1 dan users 2.0M Jan  1  1970 kernel.image                                     
-r--r--r-- 1 dan users 4.3M Jan  1  1970 rootfs.image                                     

firmware.bin is the image you can actually flash: the separate kernel/rootfs files are development versions that can run entirely from RAM (if you have enough of it)

[telent]

[quote=“Mic92, post:4, topic:203, full:true”]
Do you also intend to implement it like the NixOS module system? [/quote]

I started a reply to this post with the sentence “I’m not sure what this would look like, to be honest” (meaning, of course, "I have no idea what you’re talking about) but after further thought …

It would certainly be rather lovely if it created the configuration attrset by calling some number of user-supplied functions and merging the results using some sane merge strategy. I don’t know enough of how the modules system is implemented to say whether we could reuse the actual code or just the design patterns, though. Is that the kind of thing you had in mind?

Thanks for the question, it’s given me something to think about!

(Cleaning up the internals to use one or more nixpkgs overlays is already definitely on the TODO list and I have high hopes that it will make it easier to read. I’ve more than once already burnt myself by using the wrong busybox derivation)

[Mic92]

It is not just a design pattern, but also you nix code that you can reuse. You can borrow code from not-os to build your own: https://github.com/cleverca22/not-os/blob/master/default.nix