probably... local startup in this build is not rc.local it is /root/wrt.ini
(sorry about this... but it's how i've had/chosen to expose build features to users given alot of people are not comfortable with text file editing)
it has a variable called ENABLEDSERVICES that you add sqm to...
ENABLEDSERVICES="sqm"
(remove the # and space from the front of the line if present)
AH! I'll report back when corrected.
Thank you!!
I removed the added lines, using the ENABLEDSERVICES="sqm" instead.
Rebooted and the missing menu items are back.
Thanks for the assist/help!!
ha! that was an interesting learning experience...
note to self:
note: ENABLEDSERVICES is only read/applied on upgrade not reboot... so you still might need to enable and start sqm manually... ( but I think your 'script' 
already took care of that this install )
interesting... something similar popped up on a totally unrelated build... speaks to underlying causation / interactions...
Filtering dns over https
I’ve masqueraded dns connections back to my pihole
I’ve also completed the dns over tld block
But the dns over https errors out.
Any chance of some amazing help @anon50098793?
plenty! (but maybe not from me... i'm not a big dns + httpX modder and I seem to struggle assimilating architectural questions that are not in front of me)
it'll need its own thread with a little more config / diagnostic info provided...
lsof -i -nP
cat /etc/config/WHATEVERSERVICESAREINVOLVED | grep -v ipset
shame there is no traceroute for dns... that would be really handy from a client... but you'll probably get similar help on your new thread breaking down where the blockage/misconfig is...
architecturally, if you are masquerading dns to<>from pihole then it makes more sense to run the https / upstream elements on the pi-hole device... but again i'm not that much of an expert and your topology may be fine...
fyi, i believe I came across the spot today that was disabling wifi...
it applie(d)s only if wifi was at the default settings and WIFIDEFAULTON (legacy option pretty much) is not set in wrt.ini... (which may explain why i didn't see it when I tested)
as mentioned... what probably was sort of intended as part of the logic AGES AGO... you would have seen this on first boot if you'd done a dmesg | grep -i wifi
as most people will not edit wrt.ini prior to firstboot and there is/was some other logic that does stuff with wifi i've hopfully fixed the error/legacy logic now...
thanks for the report and sorry it took so long to find / validate your report...
for absolute vanilla firstboot... technically seeding your own edited wrt.ini @ /boot (partition 1) is doable... so if you grab the default template edit it with notepad++ or similar and place it on boot with values like
WIFIDEFAULTSSID="notabuilddefaultssid"
WIFIDEFAULTPWD="notabuilddefaultpassword"
WIFIDEFAULTCOUNTRY="AU"
WIFIDEFAULTENABLED=1
FIRSTBOOT_LAN_IPADDR="10.20.3.1"
FIRSTBOOT_LAN_IPMASK="255.255.255.0"
your wifi country, ssid, password and lanip would all be setup during firstboot...
for people that don't want wifi the/one current method is via WIFIREMOVE=1 which is a boot-time option... but as above could be slightly buggy...
massive thanks to PaulFertser and @daemonix
i've added (initial) support for RPI_GPIO=1 option which will setup python3 rpi.gpio on firstboot
it'll likely be a little volatile... in otherwords... I can't guarantee it's always gonna work due to python bumps or buildbot package failures from one build to the next...
(would be nice to build a little custom library of python3 scripts that use it... so if anyone does so... please mention what your using here and well try to incorporate those... come to think of it well probably need a RPI_PYTHON3_PIP_INSTALL="abc xyz" also so you can list additional pip stuff)upgraded to 1.1.5-19. and i can't reboot through cmd i waited 5 min before send the command again.
here dmesg
[ 3399.425981] /etc/custom/dca63264c50f.sh shutdown [ok]
[ 3399.462566] dca63264c50f.sh> /etc/custom/dca63264c50f.sh shutdown
[ 3399.469050] calling sync
[ 3399.722806] calling umount -a
[ 3405.769497] calling /bin/busybox reboot
[ 3616.392370] /etc/init.d/persistentdata: DBG: stop-nothing to sync (/tmp/dlwrapper > /boot/dlwrapper)
[ 3616.744893] /etc/custom/dca63264c50f.sh shutdown [ok]
[ 3616.780372] dca63264c50f.sh> /etc/custom/dca63264c50f.sh shutdown
[ 3616.786864] calling sync
[ 3616.888180] calling umount -a
[ 3622.900932] calling /bin/busybox reboot
thankyou!... i did mess with some stuff there recently... apologies...
try;
/bin/busybox reboot
no changes, still cannot reboot the pi. should i plug-in/out the adapter?
sure... you'll probably get a message in luci about fsck was needed... but wont really harm anything...
Still errors. Manually power off/on electric sadge.
given
/bin/busybox reboot does not workI'm thinking it's more of a disk / after market app thing?...
(possibly board hw issue? some indications power from periferals can cause this or is it eeprom)
what does this command show
pswww
sha256sum /bin/busybox
what errors?
somehow it's fixed?
sha256sum
[root@dca632 / 51°]# sha256sum /bin/busybox
c61750e260c6fc836370a828da184995a4adcf5e16d93bb9a40473d77a753e00 /bin/busybox
and what do i do for eeprom updates?
ok good... busybox is fine...
how about;
rpi-eeprom-config
vcgencmd bootloader_version
do you have a powered usb hub connected?
rpi4_eeprom.sh update
reboot #maybe
rpi-eeprom-config
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
vcgencmd bootloader_version
Apr 16 2020 18:11:26
version a5e1b95f320810c69441557c5f5f0a7f2460dfb8 (release)
timestamp 1587057086
update-time 0
capabilities 0x00000000
yes i have usb hub connected to pi, and wifi adapter tp-link tl-wn823n (need install the packages)
if you cant reboot after the eeprom is updated... you'd have to test without the usb-hub (and/or without it powered)...