well... may help to clobber the related files on 61-20 (can't hurt);
possible-patch
wget https://github.com/wulfy23/rpi4/raw/master/utilities/sysuppatch.tar.gz -O /sysuppatch.tar.gz
(cd /; tar -xvzf sysuppatch.tar.gz)
dont really use the luci upgrade function (always command line or one-click) but technically it should work (generally speaking)... just rarely test it...
did you add it to /etc/packagesinstall.txt (one package per line)?
don't have any experience with it... board specific config helpers or UI tweaks sound nice... must admit have toyed with the idea of UPSing the pi...
(one other user posted some li-on rig/expressed interest... anyone else running nut?)
I have an APC UPS protecting some devices (including one NAS and the RPi4 running OpenWrt). I would love to use OpenWrt to manage power on sequences (using WOL) after a power fault. I've already modified /etc/rc.local to do that but I also want to cover situations where the power fault was short, the NAS had shutdown but not OpenWrt, so the NAS needs to be restarted.
Of course the NAS could be parametrized to restart automatically when power is resumed, but I want to avoid situations when there are intermitent power failures until the situation stabilizes. The NAS takes a long time to shutdown so I want to wake it up only when battery level is adequate.
I had a long power fault yesterday and OpenWrt seems to be ok after it, probably it doesn't need to perform orderly shutdowns in my case.
you'd have to provide most of the sample config / setup as i'm unfamiliar with the tools... but sounds like it could be a nice addition... the wol thing can be compartmentalized... (scaled to non nut users via whatever api is simplest so that's easily doable)
add them to your /etc/packagesinstall.txt and let us know when we can test something you have...
Quick question, just noticed something from tinkering around and wanted to confirm.
If I run cat /proc/interrupts the result is 100% of interrupts on eth0 going to CPU0 (ie, 1 core).
Installing IRQ balance and rebooting doesn't change this.
Editing /etc/config/irqbalance and changing option enabled "0" to "1" and rebooting makes a small difference, but CPU0 still handles over 98% of interrupts on eth0, albeit a couple go to cores 3 and 4. Is this just standard? I would've assumed irqbalance would do a better job sharing the love, but don't know enough about it.
Note: my wan speed is only 250/25 so not pushing anything at all, just rather things be as efficient as possible! Packet steering is enabled btw.