re: https-dns-proxy...
i've been aware of 'complications' for a while (since over 6 months ago when neil1 was first having firstboot restoration issues)
for simplicity... i'd like to separate 'firstboot' from typical reboot (where I assume it would startup much more predictably)... so if it does not startup on a reboot and it is enabled... i'd like to know...
info-on-fixes
there are two or three workarounds for the firstboot situation...
- disable it manually before and after upgrade
- Test the ntp bypass method
- Add something a bit fancier... a specific 'wait and watch for dns and or restart' during the firstboot process
i'm sure there is a fairly basic solution... but as this issue is intermittent and I don't run the service, i'm reluctant to spend the several hours needed to pinpoint where things are fouling up... especially when i'm unable to simulate the exact conditions for all users...
some reading material;
https://forum.openwrt.org/t/https-dns-proxy-and-dnsmasq-config-noresolv/106274/4?u=wulfy23
https://forum.openwrt.org/t/https-dns-proxy-and-dnsmasq-config-noresolv/106274/6?u=wulfy23
depending on how often you upgrade and whether reboot is reliable, if I were you guys i'd seriously consider
- using attended-sysupgrade / asu for a while on a seperate sdcard (i.e. simple basic official OS )
- using only 'release'/21.02.0 custom build
to observe behavior.... and minimise how often you need to upgrade...