AdGuardHome Asuswrt-Merlin-AdGuardHome-Installer (AMAGHI) cont.

[privacyguy123]

My file is just fine ... just as it's been every update previous to these newest 2 ...

The error makes no sense me - I understand how formatting .yaml and writing .sh files works ...

 

[SomeWhereOverTheRainBow]

My file is just fine ... just as it's been every update previous to these newest 2 ...

View attachment 54836
The error makes no sense me - I understand how formatting .yaml and writing .sh files works ...

Have you tried configuring with a new file to see if issue goes away. There still could be an expired option inside your .yaml file.

Here is my recent update with no issues in my attempts to reproduce the error you have presented here:

 

[privacyguy123]

Have you tried configuring with a new file to see if issue goes away. There still could be an expired option inside your .yaml file.

Doesn't the script automatically write a (good) new file when it renames the old one to .yaml.err?

This should have happened last update cycle - so this .yaml file already is a "new file" and the error has persisted through 2 updates.

 

[SomeWhereOverTheRainBow]

Doesn't the script automatically write a (good) new file when it renames the old one to .yaml.err?

This should have happened last update cycle - so this .yaml file already is a "new file" and the error has persisted through 2 updates.

No because the aim is not to "write a new" when you should review your file to find out the problem and correct it. The aim of the installer is to only provide "basic" level config for users to set the log-in password. All this installer does is write a "basic" config for setting the password, and initial dns entries for the first run time. It does no other configuration. Users spend time in configuring their AGH. Steps the installer does not provide, such as choosing block lists and specfic dns configurations, etc. That is why it is moved to .err so users can review the file to identify the error. Need be, I can also review the .err and try to identify why there is an error.

 

[SomeWhereOverTheRainBow]

Doesn't the script automatically write a (good) new file when it renames the old one to .yaml.err?

This should have happened last update cycle - so this .yaml file already is a "new file" and the error has persisted through 2 updates.

If you want a "new" config, select option "4" of the installer. When it prompts select the option to reconfigure instead of using the "old" config.

Option "3".

 

[Kingp1n]

@SomeWhereOverTheRainBow

Within AdguardHome, would you know what would be a similar list to the Diversion predefined 'minimal' list? Thanks for your input!

 

[SomeWhereOverTheRainBow]

@SomeWhereOverTheRainBow

Within AdguardHome, would you know what would be a similar list to the Diversion predefined 'minimal' list? Thanks for your input!

 

[SomeWhereOverTheRainBow]

@Kingp1n

here is my selections:

 

[SomeWhereOverTheRainBow]

Doesn't the script automatically write a (good) new file when it renames the old one to .yaml.err?

This should have happened last update cycle - so this .yaml file already is a "new file" and the error has persisted through 2 updates.

Just to let you know, I pushed an update. I don't really think it will resolve the annoyance with AGH built-in .yaml checker, but it might.

https://github.com/AdguardTeam/AdGuardHome/issues/4067 is just one of the past annoyances I tracked down with the .yaml checker. Ultimately, any bugs in it need to be resolved by the AGH team. That is one of the reason's I have it move the yaml to yaml.err. The problem with the installer is, it will only attempt to let you reconfigure on the first ".yaml" check failure. It then performs another check at the end of reconfiguration, if it fails again you have to rerun the entire reconfig option. This is just a consequence of the feature. The intended purpose is to actually determine the root cause of the break in the yaml.err. Sometimes it is a "schema version" disagreements, other times adguardhome has added or changed a setting in the .yaml file which breaks something. I usually have to add drop-in's to the installer to band-aid the issue.

Next time you run into a problem like this, you can actually check the error yourself using the AGH checker from the command-line

AdGuardHome --check-config -c "/opt/etc/AdGuardHome/AdGuardHome.yaml.err" --no-check-update

It will output, what's causing the problem if there is one.

 

[Tomo]

@Kingp1n

here is my selections:

View attachment 54847

View attachment 54848

View attachment 54849
View attachment 54850

Do you think these lists can be managed by my Ac86U?
At moment i'm using OsidBig and the 2 of Adguard.

 

[SomeWhereOverTheRainBow]

Do you think these lists can be managed by my Ac86U?
At moment i'm using OsidBig and the 2 of Adguard.

I am not 100 percent positive, but am fairly certain you should be able to use some of them. My routers been purring along with the ones I show selected above.

I strictly use the ones supplied by AdGuard as a minimalist approach.

 

[privacyguy123]

Just to let you know, I pushed an update. I don't really think it will resolve the annoyance with AGH built-in .yaml checker, but it might.

https://github.com/AdguardTeam/AdGuardHome/issues/4067 is just one of the past annoyances I tracked down with the .yaml checker. Ultimately, any bugs in it need to be resolved by the AGH team. That is one of the reason's I have it move the yaml to yaml.err. The problem with the installer is, it will only attempt to let you reconfigure on the first ".yaml" check failure. It then performs another check at the end of reconfiguration, if it fails again you have to rerun the entire reconfig option. This is just a consequence of the feature. The intended purpose is to actually determine the root cause of the break in the yaml.err. Sometimes it is a "schema version" disagreements, other times adguardhome has added or changed a setting in the .yaml file which breaks something. I usually have to add drop-in's to the installer to band-aid the issue.

Next time you run into a problem like this, you can actually check the error yourself using the AGH checker from the command-line

AdGuardHome --check-config -c "/opt/etc/AdGuardHome/AdGuardHome.yaml.err" --no-check-update

It will output, what's causing the problem if there is one.

Running this command on current .yaml shows "no error" - running it on the error file is senseless as there is obviously an error in that file?

Pushing the update through amtm shows this same BS.

Info: Checking AdGuardHome configuration...
2023/12/14 18:03:06 [error] Couldn't get logging settings from the configuration: yaml: line 5: mapping values are not allowe
ed in this context
Info: Moving invalid configuration file to /opt/etc/AdGuardHome/AdGuardHome.yaml.err.

As I said earlier in the thread: this bug is new (past 2 updates) and seems to be part of the updating script, not AG home itself. I let AG make a new config file and answer all the questions yet this bug that the config file is "wrong" persists through updates. Explain how that makes sense?

 

[jsbeddow]

Can someone explain the "right" way to do an upgrade/update (if that has been solved with any workarounds), given the issues with many reports of broken installations (.yaml issues, etc)? I tried to do the update on mine today, and even though it didn't seem to have any visible errors, and initially appeared to be a successful update, I wasn't getting any DNS resolution on the clients of my OpenVPN server (all seemed OK on the local network though). My only solution was a "restore" from the backup, which thankfully worked perfectly, but of course rolled back my version(s) (both the installer and the AGH version).

While it was broken, I tried running the above command to see if it might be the infamous broken .yaml formatting issue, but my installation threw a different error, see below:

ASUSWRT-Merlin GT-AX6000 3004.388.5_0 Sat Dec  2 17:49:54 UTC 2023
redacted@GT-AX6000-8EB8:/tmp/home/root# AdGuardHome --check-config -c "/opt/etc/AdGuardHome/AdGuardHome.yaml.err" --no-check-update
2023/12/14 11:21:25.417334 [info] AdGuard Home, version v0.108.0-b.51
2023/12/14 11:21:25.461540 [info] This is the first time AdGuard Home is launched
2023/12/14 11:21:25.461583 [info] Checking if AdGuard Home has necessary permissions
2023/12/14 11:21:25.463732 [info] AdGuard failed to bind to port 53: listen tcp 127.0.0.1:53: bind: address already in use

Please note, that this is crucial for a DNS server to be able to use that port.
2023/12/14 11:21:25.463790 [info] AdGuard Home can bind to port 53
2023/12/14 11:21:25.468950 [info] safesearch default: disabled
2023/12/14 11:21:25.469772 [info] Initializing auth module: /tmp/mnt/AX6000-USB/entware/etc/AdGuardHome/data/sessions.db

 

[SomeWhereOverTheRainBow]

While it was broken, I tried running the above command to see if it might be the infamous broken .yaml formatting issue, but my installation threw a different error, see below:

ASUSWRT-Merlin GT-AX6000 3004.388.5_0 Sat Dec  2 17:49:54 UTC 2023
redacted@GT-AX6000-8EB8:/tmp/home/root# AdGuardHome --check-config -c "/opt/etc/AdGuardHome/AdGuardHome.yaml.err" --no-check-update
2023/12/14 11:21:25.417334 [info] AdGuard Home, version v0.108.0-b.51
2023/12/14 11:21:25.461540 [info] This is the first time AdGuard Home is launched
2023/12/14 11:21:25.461583 [info] Checking if AdGuard Home has necessary permissions
2023/12/14 11:21:25.463732 [info] AdGuard failed to bind to port 53: listen tcp 127.0.0.1:53: bind: address already in use

Please note, that this is crucial for a DNS server to be able to use that port.
2023/12/14 11:21:25.463790 [info] AdGuard Home can bind to port 53
2023/12/14 11:21:25.468950 [info] safesearch default: disabled
2023/12/14 11:21:25.469772 [info] Initializing auth module: /tmp/mnt/AX6000-USB/entware/etc/AdGuardHome/data/sessions.db

The problem is you have to physically stop/start AGH before you use the file checker to ensure something else does not occupy port 53 netstat -nlp | grep ':53 '. The install script has code in place that will physically stop/start Adguardhome, before it does the .YAML check. I don't know if you guys are using "additional" scripting that hinders AGH from stopping, but if AGH does not stop/start before running the .YAML checker runs, then the YAML checker may FAIL. I remember @privacyguy123 mentioned having alot of IPsets inside their .YAML, I don't know if this causes Adguardhome to take an unusual amount of time to perform all these steps. Maybe I have to add additional check in the installer to ensure the local AGH is actually stopped/started, before running the .YAML checker. The .YAML check is a critcal check for know if something is broken in the .YAML setup.

 

[SomeWhereOverTheRainBow]

Running this command on current .yaml shows "no error" - running it on the error file is senseless as there is obviously an error in that file?

Pushing the update through amtm shows this same BS.


As I said earlier in the thread: this bug is new (past 2 updates) and seems to be part of the updating script, not AG home itself. I let AG make a new config file and answer all the questions yet this bug that the config file is "wrong" persists through updates. Explain how that makes sense?

As far as I can tell, you seem to be the only one actually reporting on this issue. I was hoping someone else who shares the same problem would provide more details than just the three lines of terminal log you have reported here. Maybe you can share additional details about your .yaml (such as its contents), your entire ssh terminal session image log (not just the 3 lines), and setup (including other addons you use) in private message. I am willing to go the extra mile on the research end to solve the problem, but all you have shared with me here is three lines. For me, that's not helpful because I am unable to reproduce the problem. The only problem I have ever had with the installer was when I ran it so many dam times in a day trying to troubleshoot this "ghost" issue, I got ratelimited by Github for excessive queries in a day,

 

[SomeWhereOverTheRainBow]

Can someone explain the "right" way to do an upgrade/update (if that has been solved with any workarounds), given the issues with many reports of broken installations (.yaml issues, etc)?

Here is "the only way" to update/upgrade using this script. Let me know if the technique, or method shown in the image below is "complicated" or "complex". I sometimes find it difficult to follow the prompts. I found myself the other day trying to use the option "3) Change Username/Password" to reconfigure the block lists and for some reason I thought the "4) reconfigure" allowed me to change the password.

 

[SomeWhereOverTheRainBow]

SOLVED.
Good morning, i wanted to ask if there is a manual procedure to install the version previous to the current AdGuard Home v0.107.42 ( normal release), with this i am detecting cache times ranging from the usual 0.20ms to values over 90ms having an average on the total dins about 35-40ms. In the AdGuard Home v0.107.41 version with the same settings the average resolution time was around 5-8ms. The settings are the same, 2 TLS DNS servers (Google and Cloudflare) in parallel mode, increased the cache size parameters based on the advice i found here on the forum and activated Oisid Big List and the 2 Adguard. Has anyone else encountered this problem?

Update: In general settings i had the "parental control web service" active, i'm sure i didn't have it before, now i've deactivated it, it could be that it increased the general delay on DNS resolution, let's see if this is the problem.

Update2: it was the "parental control", whit it disabled the Average processing time back to 3-6 ms, probably the Ac86u is too old to process this option without introducing a huge delay.

Yea, the best I could get mine down to was:

with these features turned on:

 

[jsbeddow]

Here is "the only way" to update/upgrade using this script. Let me know if the technique, or method shown in the image below is "complicated" or "complex". I sometimes find it difficult to follow the prompts. I found myself the other day trying to use the option "3) Change Username/Password" to reconfigure the block lists and for some reason I thought the "4) reconfigure" allowed me to change the password.

View attachment 54862

Ok, thanks for what seemed like a snarky reply, that wasn't really what I was looking for.

I know option 1 should do the update, but there seemed to be a few posts roughly a week ago (around Friday, Dec 8th) that indicated they had issues as well with the update, and they implied that they had found a workaround, but perhaps what they were trying to say was that they used the same rollback (from a backup) facility that I ultimately used.

I'll just leave well enough alone for now, I don't really have a strong reason, or "need" to update anyway. It does seem to be a long standing issue with the AGH developers to continually tinker with the .yaml file configuration, not sure of the reasons behind that, but it does seem to cause trouble for user updates.

 

[SomeWhereOverTheRainBow]

Ok, thanks for what seemed like a snarky reply, that wasn't really what I was looking for.

I know option 1 should do the update, but there seemed to be a few posts roughly a week ago (around Friday, Dec 8th) that indicated they had issues as well with the update, and they implied that they had found a workaround, but perhaps what they were trying to say was that they used the same rollback (from a backup) facility that I ultimately used.

I'll just leave well enough alone for now, I don't really have a strong reason, or "need" to update anyway. It does seem to be a long standing issue with the AGH developers to continually tinker with the .yaml file configuration, not sure of the reasons behind that, but it does seem to cause trouble for user updates.

Sorry if my reply came off as a little snarky. No harm was intended. I am in the same boat you are with the limbo of the .yaml battle. The changes that introduce to the yaml syntax can create issues. Especially since they don't honor legacy options when they make the changes. The only way to support legacy syntax in the .yaml file is to rollback to an older schema version. Then you run the risk of missing out on new features. So really there is no "win" "win" or even an single "win". A lot of times the AdGuardHome will not allow you to use a rollback schema version. They only allow it for very short period of time. Most the time people even miss that time window. When you run adguardhome, be prepaired to be their beta tester as well. Especially if you intend to run updates every single time you see an update is available. Again, I do apologize.

Here is the command I had to craft just to pull their schema version from the upstream releases:

curl -sL "https://api.github.com/repos/AdguardTeam/AdGuardHome/releases" | grep -m1 -oE 'schema.*to[[:space:]][0-9]{1,2}' | awk '{ print $NF }'

I don't even know how long this will be a viable method for updating the schema version since they don't always publish the schema version every release.

 

[SomeWhereOverTheRainBow]

Running this command on current .yaml shows "no error" - running it on the error file is senseless as there is obviously an error in that file?

Pushing the update through amtm shows this same BS.


As I said earlier in the thread: this bug is new (past 2 updates) and seems to be part of the updating script, not AG home itself. I let AG make a new config file and answer all the questions yet this bug that the config file is "wrong" persists through updates. Explain how that makes sense?

I pushed a few minor fixes, I hope this time it fixes it for you. Please let me know the outcome if you choose to roll the dice again.