Thanks, was a bit worried about getting a negative response!
To try to be more specific, when I specify to install say SQM, what file do I edit? And where/when do I edit it, i.e over the console when OpenWRT is running, or from Luci or do I edit a config file before flashing the SD card?
After that say if I want to retain the way SQM is configured does that happen automatically when I update or do I need to specify the settings somewhere so they are retained/reapplied?
sqm is installed... it just needs to be enabled... this is described on the top post
this is common sqm setup for which there are many documents and guides available here in the forum or wiki...
not before flashing as nothing is there... ( if you mean sysupgrade see point below )
yes ( search the thread for ENABLEDSERVICES to have sqm auto-enabled after the upgrade )
Thanks, maybe SQM was a bad choice of example! Also i made a flub by saying before flashing, I meant to say after flashing but before putting the card in the Pi 
So for things that i want to stay enabled after upgrading do I need to edit a file on the SD card before upgrading or do I need to edit something in the new image?
Also is luci enabled automitically and is there a way to change the IP address of the router by editing the SD card before putting it in the Pi?
Sorry if these seem like silly questions, I'm just not quite getting my head around things!
technically it is possible to place your existing sqm-config file on the sdcard prior to booting... but usually re-setup is a few clicks so better to do that I think
only 'extra' things that not everyone uses... sqm is one of them... it can be edited in LUCI > services > banip > advanced > wrt.ini ( edit: post 2021-02-05 > system > startup )
ENABLEDSERVICES="sqm"
yes
yes... but you will need an existing network config file to use as a sample or just copy your old one, again... setup is generally a few clicks so it not normally worth the trouble
Thanks for all this, I'll give it a whirl and see what happens and come back if I have specific problems.
Cheers,
Dave
I got the X728 UPS on the Pi lastnight. This morning I ran it for close to 3 hours on two old 18650 vape 3000mah vape batteries and the battery LEDs were still showing over 75% capacity. Not to worry, brand new batteries are on the way along with the add-on board to hold 2 more batteries.
I expect more snow and power outages sometime before winter is over... I'm ready. 
Now I just need to find the time to fiddle with this script and see if I can come up with something that works. I'd love to have battery level and AC power show up on a graph in statistics or status overview page in the future.
If anyone has suggestions that would save me some time let me know!
create a thread on the general forum... ( link to the post above )... way more exposure there than on this thread anyway...
that said... I have some i2c auto-enable code and dtbo auto-setup stuff that may be useful within the build if a few more users are using these... ( and the necessary underlying glue is ironed out )
not wanting to be a party-poopon... but I doubt any (official) UI stuff would manifest ( unless you/someone wrote some glue API which ties in common system calls into the i2c bus or whatever nut / existing UI facility is there )
(short term)... possibly look at writing a php/perl/etc-page... or a luci-app-command that provides whatever UI features your contemplating... And I'd be more than happy to integrate any bespoke such code within the build if/when it eventuates...
I just upgraded to 2.7.15-2 (r15599-37752336bd) and I'm getting a NotFoundError on the SQM page https://x.x.x.x/cgi-bin/luci/admin/network/sqm
Dunno if this is relevant:
# cat /etc/config/sqm
config queue 'eth1'
option interface 'eth1'
option debug_logging '0'
option qdisc 'cake'
option enabled '1'
option script 'piece_of_cake.qos'
option linklayer 'ethernet'
option overhead '22'
option download '225000'
option upload '10750'
option verbosity '2'
/etc/init.d/sqm enable; /etc/init.d/sqm restart
That worked but I'm puzzled why I needed to start it manually since my /root/wrt.ini has ENABLEDSERVICES="sqm banip adblock"
thanks for the report... looks like a bug perhaps... if you have not rebooted since upgrading...
(dmesg ; logread) | grep -i sqm
there are some potential issues i'm tracking on master re: sqm... so I need to hold off before diving too deep into it rather than tear apart stuff... hence that build being labelled 'testing'...
I uploaded the previous build in case you'd like to downgrade... just double check dnsmasq upgraded / run the one-liner above if you install it as it has the buggy dnsmasq... ( why only 'testing' was up )
symptoms i'm seeing are lock issues and service needs to be restarted on boot ( or firewall restart );
Wed Jan 27 14:12:36 2021 user.notice SQM: ERROR: Giving up on getting lock after 10 attempts
Wed Jan 27 14:12:36 2021 user.notice SQM: ERROR: This is a bug; please report it at https://github.com/tohojo/sqm-scripts/issues
Wed Jan 27 14:12:36 2021 user.notice SQM: ERROR: Then, to re-enable sqm-scripts, manually remove /var/run/sqm/sqm-run.lock
Wed Jan 27 14:12:36 2021 user.notice SQM: WARNING: Unable to get run lock - already held by 31714
Wed Jan 27 14:12:37 2021 user.notice SQM: WARNING: Unable to get run lock - already held by 31714
Wed Jan 27 14:12:38 2021 user.notice SQM: WARNING: Unable to get run lock - already held by 31714
mentioned here;
Ah, nuts. I did reboot after upgrading. I wanted to double-check my settings and make sure it wasn't a user error before I posted. The only thing dmesg | logread) ... is telling me now is
Wed Jan 27 15:20:20 2021 user.notice ucitrack: Setting up /etc/config/firewall reload dependency on /etc/config/sqm
I don't feel the need to downgrade. I'll keep an eye on the releases & upgrade when the next becomes available.
Hi, complete newbie here.... failing at [nearly] the first hurdle.
Got up and running OK with rpi4.64-snapshot-25261-2.7.15-2-r15599-ext4-fac and logged in at 192.168.1.1 luci & ssh working on a standalone pc.
First thing I need to do is change LAN ip to 192.168.0.254/24 On my network I have quite a few devices with fixed ips which know this is the netmask & gateway and it would be a real hassle to have to change them all.
I managed to do a change in luci, and get it to save - however, when I now go to 192.168.0.254 the page /cgi-bin/luci/ is blank because it is returning a 403 forbidden.
So there is obviously more to changing the lan ip on this build than meets the eye.
Could someone tell me how to do it please? - Starting from a new virgin snapshot, perhaps I can get ssh working and then there's a script I can run?
Thanks
Richard
This is not a build specific issue though.
First verify that the PC you are connecting to the router got the correct IP in 192.168.0.0/24 subnet. Try to clean the browser cache, use a different browser or use private browsing mode.
Can you login with ssh using the new IP?
I already knew I could login by SSH to 192.168.0.254 fine which is what was so mysterious, but you prompted me to have another go in browser incognito mode - and bob's my uncle.
So thankyou - it was a browser caching problem - solved.
Thankyou so much
Richard
Recently I started receiving some weird errors from the RPi, which turned out to be due to rootfs mounted ro. A reboot didn't fix it, nor could I enable the fsck on boot. Eventually it was faster to plug the sd card in my pc and check the fs there.
Maybe it would make sense to enable the filesystem check on boot by default in the image?
when enabled... you'd see something like this in dmesg;
[ 6.809436] 79_move_config> fsck-bootpart:/dev/mmcblk0p1 [clean]
[ 6.555143] 80_mount_root> fsck-rootfspart:/dev/mmcblk0p2 [clean]
edit: could be years before anyone reports back... so it's done...
#on by default... only parsed->cmdline.txt at firstboot to disable user needs to comment out this line for the next upgrade and remove from their cmdline.txt
RPI4CMDLINEOPTS="fsckparts"
just pushed a usb_testing beta fw...
not for the average user (yet)...
when I last updated my official-pi-firmware ( to the usb-boot support stable release ) I set my pi-firmware-BOOT_ORDER=0xf14 ... which means try usb first...
my mmc card is hard to get to... so this is better for me... with the default boot order ( 0xf41 ) you'd have to remove (or not have an OS on) the mmc for it to try the usb...
[root@dca632 /usbstick 46°]# rpi-support.sh -b | grep -Ei '(root|boot)'
################################# root-dev: /dev/mmcblk0p2:02010729-02 boot-dev: /dev/mmcblk0p1
root@boot: PARTUUID=02010729-02
root@cmdline: PARTUUID=02010729-02
console=ttyAMA1,115200 root=PARTUUID=02010729-02 rootfstype=squashfs,ext4 rootwait fsckparts brcmfmac.debug=0x100000
boot_delay=3
BOOTORDER: usb mmc
Anyone else try to use two tp-link UE300 usb3 adapters and get stuck in some kind of weird boot loop until one is unplugged when you reboot?
seems the latest build ( 2.7.33-x ) has some statistics cpu alt confs that probably wont get migrated... ( shows per cpu info ... really nice ), may have been on earlier builds but I always migrated my config.
luci_statistics.collectd_cpu=statistics
luci_statistics.collectd_cpu.enable='1'
luci_statistics.collectd_cpu.ReportByCpu='1'
luci_statistics.collectd_cpu.ReportByState='1'
luci_statistics.collectd_cpu.ShowIdle='0'
luci_statistics.collectd_cpu.ValuesPercentage='1'
config statistics 'collectd_cpu'
option enable '1'
option ReportByCpu '1'
option ReportByState '1'
option ShowIdle '0'
option ValuesPercentage '1'