@mercygroundabyss Yes, it is possible the opkg version to not start on boot due to race conditions which certain network setups. Short of changing the start value, there isn't an easy fix because it is quite variable.
The consideration is AdGuardHome devs have made the start value equal to when /etc/rc.local is called, that's right at the end the boot process, which isn't ideal.
The issue is these network race conditions aren't always going to happen, it's down to individual setups. I'm wondering if the opkg version should allow you to configure a custom START value in it's config, as currently it will get wiped on any sysupgrade.
I'm not sure the solution is to just increase the START value to 95, as it's way too late in the boot process for something as critical as DNS.
The workaround I found is implementing a custom init script that runs before AdGuardHome to make sure other network conditions are available before it tries to start.
We could bump the start value a bit, as perhaps 21 is a little too early for all network related areas to be completed, but I wouldn't go as far as increasing to 95.
However one consideration is changing the bind_host/bind_hosts value from 0.0.0.0 could lead to this issue, if you set a specific address that's not available.
There is possibly an argument to leave the bind values as default to any available address, because the firewall rules should prevent access outside of the LAN. Likewise dnsmasq also defaults to all network addresses by default to bind to.