Only a handful of news on my end right now, thanks to busy jobs on my part taking away from router fun. Here are the updates on the parts that I’m involved with:

New ROOter build systems

Dairyman has released four new build systems since my September update. All four are “special purpose” systems meant to cover a handful of routers. They are:

• SourceMaster (link) to cover MT3000, WS1698, X3000, and Z8102. This is a fork off of the OpenWRT master as of roughly 27 Nov 2023.
• SourceBPIR4 (link) to cover BPI4, the Banana Pi R4. Currently a single image system.
• SourceRPI5 (link) to cover RASPPI5 and RASPPI5USB, which should be the Raspberry Pi 5 board with either the usual SD card or with USB mounted root file systems.
• Source1800 (link) to cover AW1000, AX1800, and AXT1800. These are the Arcadyan AW1000 and two GL-iNet variants, all with ipq chipsets.

None of these are currently expected to become major build systems, but they will be used where necessary to support new systems not yet covered by one of our main systems. I’m still hearing 21.02 is likely to stay our primary system for a while, as 22.03 and 23.05 are producing much larger images that aren’t going to work on a lot of routers we currently support. Kernel growth has been a big issue in particular for several years now.

Build machine upgrades

The autobuild machine has also gotten an upgrade around New Years. With the current number of router images, the main system SSD was staying around 80-90% full. The build machine now has a second SSD of the same size, so we’re set for quite a bit of future growth.

This laptop has been running the autobuild systems for almost two years now. Not bad for a total investment of roughly $250 US – all this is done off of a salvaged Dell e6410 laptop with a 2 core (4 virtual) i7 chip and 8GB of RAM, with two 1TB SSD’s. It has cranked out roughly 250 images per week in recent builds, usually in 55h or less. Never underestimate the value of ancient hardware to do real work, as these laptops were released in 2010. With weekly builds only taking roughly 1/3 of the laptop’s possible duty cycle (in hours of the week), I expect this little guy should be up for the task for a lot longer barring catastropic failure.

One point of interest is that the CPU load is shown on the build system status page here the same as it is on a ROOter status page (which is the number given by the uptime command). In the first part of the build, it’s not unusual to see utilizations hovering in the upper 20’s. Since this is a two core machine, with hyperthreading, it can handle a load of roughly 1.4 per core depending on the type of load, so for anything over about 2.8, the CPU is 100% utilized. Something to remember when people tell you to tune your builds so that your CPU load stays under your core count – that’s absolute BS. For best builds, you want your load ABOVE your core count. The lower recommendations are to make sure your system stays responsive, but it’s much, much better to handle that using the nice command when you start your build. Despite my CPU being overloaded by an order of magnitude, the machine is still perfectly responsive, and the only way to tell how hard it’s working is by hearing the fan spun up or seeing that load number.

Docker Autobuild Image updates

The base image for the autobuild containers has been updated to Debian 11.8 from 11.7. This is because one of the new build systems needed a pair of new build tools added. This can be done directly within the container for testing, but really any change in the toolchain is work updating the base image instead. This keeps the resulting images a lot more consistent.

The new base image has been applied to all 9 build systems (which took half an evening), tested, gone through a week of full builds, and all of the build system changes have been pushed to github with the new images already pushed to Docker Hub.

Bonus: there’s one more feature announcement coming (which the folks on the forum today will have already seen), but it warrants its own post.