Now it its working state it is:
root@GL-AXT1800:~# df -h
Filesystem Size Used Available Use% Mounted on
mtd:ubi_rootfs 41.0M 41.0M 0 100% /rom
tmpfs 196.4M 10.2M 186.2M 5% /tmp
/dev/ubi0_2 56.6M 10.3M 43.3M 19% /overlay
overlayfs:/overlay 56.6M 10.3M 43.3M 19% /
tmpfs 512.0K 0 512.0K 0% /dev
/dev/mmcblk0p1 477.4G 283.2G 194.2G 59% /tmp/mountd/disk1_part1
Hm, I see.
While running the script there is a quick check about the storage - may you post the first lines of the running script?
Sure.
┌──────────────────────────────────────────────────┐
| Are you sure you want to continue? (y/N) |
└──────────────────────────────────────────────────┘
y
[2024-08-27 13:06:54] [→] Detecting latest AdGuard Home version
[2024-08-27 13:06:55] [→] Latest AdGuard Home version: 0.107.52
[2024-08-27 13:06:56] [→] Current AdGuard Home version: 0.107.46
[2024-08-27 13:06:56] [!] Updating from version 0.107.46 to 0.107.52
[2024-08-27 13:06:56] [→] Creating backup of AdGuard Home config ...
gzip: write error: No space left on device
tar: write error: Broken pipe
[2024-08-27 13:07:35] [→] Backup created: /root/AdGuardHome_backup.tar.gz
[2024-08-27 13:07:35] [→] Downloading latest Adguard Home version ...
[2024-08-27 13:07:39] [✓] AdGuardHome binary found, download was successful!
[2024-08-27 13:07:39] [→] Stopping Adguard Home ...
[2024-08-27 13:07:44] [→] Moving AdGuardHome to /usr/bin ...
rm: can't remove '/usr/bin/AdGuardHome': No space left on device
mv: can't remove '/usr/bin/AdGuardHome': No space left on device
The lines before this are more interesting 
sorry for drip feeding
HTTP request sent, awaiting response... 200 OK
Length: 16240 (16K) [text/plain]
Saving to: 'update-adguardhome.sh'
update-adguardhome.sh 100%[==================================>] 15.86K --.-KB/s in 0.001s
2024-08-27 13:06:30 (12.3 MB/s) - 'update-adguardhome.sh' saved [16240/16240]
[2024-08-27 13:06:30] [→] Checking if prerequisites are met ...
[2024-08-27 13:06:30] [✓] Firmware version: 4
[2024-08-27 13:06:30] [✓] Architecture: armv7
[2024-08-27 13:06:30] [✓] Available space: 21 MB
[2024-08-27 13:06:30] [✓] curl is installed.
[2024-08-27 13:06:30] [✓] Prerequisites are met.
[2024-08-27 13:06:30] [→] Checking for script updates
[2024-08-27 13:06:30] [✓] The script is up to date
┌────────────────────────────────────────────────────────────────────────┐
│ GL.iNet router script by Admon 
for the GL.iNet community |
| Version: 2024.08.22.03 |
├────────────────────────────────────────────────────────────────────────┤
│ WARNING: THIS SCRIPT MIGHT POTENTIALLY HARM YOUR ROUTER! │
│ It's only recommended to use this script if you know what you're doing.│
├────────────────────────────────────────────────────────────────────────┤
│ This script will update AdGuard Home on your router. │
└────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────┐
| Are you sure you want to continue? (y/N) |
└──────────────────────────────────────────────────┘
y
Hm. This does not fit to the space shown in df -h
Seems like tmpfs and /dev/ubi0_2 are summed up... weird.
Will check it later this week.
The thing is the df -h is after i recovered (Adguard .52 running and backup and script deleted)and includes that i had to install curl and sftp. So there is some discrepancy. I am thinking to execute the script again and see what it detects but not applying it.
1 Like
Would be nice if you can do.
New log:
Saving to: 'update-adguardhome.sh'
update-adguardhome.sh 100%[==================================>] 15.86K --.-KB/s in 0.01s
2024-08-27 14:23:52 (1.41 MB/s) - 'update-adguardhome.sh' saved [16240/16240]
[2024-08-27 14:23:52] [→] Checking if prerequisites are met ...
[2024-08-27 14:23:52] [✓] Firmware version: 4
[2024-08-27 14:23:52] [✓] Architecture: armv7
[2024-08-27 14:23:52] [✓] Available space: 43 MB
[2024-08-27 14:23:52] [✓] curl is installed.
[2024-08-27 14:23:52] [✓] Prerequisites are met.
[2024-08-27 14:23:52] [→] Checking for script updates
[2024-08-27 14:23:53] [✓] The script is up to date
┌────────────────────────────────────────────────────────────────────────┐
│ GL.iNet router script by Admon for the GL.iNet community |
| Version: 2024.08.22.03 |
├────────────────────────────────────────────────────────────────────────┤
│ WARNING: THIS SCRIPT MIGHT POTENTIALLY HARM YOUR ROUTER! │
│ It's only recommended to use this script if you know what you're doing.│
├────────────────────────────────────────────────────────────────────────┤
│ This script will update AdGuard Home on your router. │
└────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────┐
| Are you sure you want to continue? (y/N) |
└──────────────────────────────────────────────────┘
df -h
root@GL-AXT1800:~# df -h
Filesystem Size Used Available Use% Mounted on
mtd:ubi_rootfs 41.0M 41.0M 0 100% /rom
tmpfs 196.4M 10.3M 186.2M 5% /tmp
/dev/ubi0_2 56.6M 10.4M 43.3M 19% /overlay
overlayfs:/overlay 56.6M 10.4M 43.3M 19% /
tmpfs 512.0K 0 512.0K 0% /dev
/dev/mmcblk0p1 477.4G 283.2G 194.2G 59% /tmp/mountd/disk1_part1
includes the downloaded script
Ahhh, you said you have many blocklists. This might be the issue because the backup file will be huge and doubles the needed space.
I will add a secondary check for that.
To avoid this problem, run the script with --ignore-free-space which will omit the backup process.
Yeah sounds like this is the problem.
maybe include a warning in the script text output. The user might not relate the disc space available with the amount that blocklists can consume.
Perhaps, all the user has to do is make a router config backup (in luci) that includes all Adguard settings anyways. Maybe that backup of the Adguard config file through the script is not necessary. The backup of Adguard binary still is necessary.
1 Like
I filed a bug report about it and will work out a solution.
Thanks for reporting!
1 Like
I'm curious. Is there a way for the script to ask for build version or a latest tag? The reason I ask is because I had seen some errors on a specific adguard build and some users recommended a previous build which the errors didn't occur.
1 Like
It should be implementable, I will take a look.
2 Likes
The feature was added.
The script now supports --select-release for interactive release selection.
4 Likes
Works perfectly, great addition.
Question about adguard and upgrading and downgrading the glinet firmware.
When I downgraded / upgrade the FW I noticed adguard wouldn't run again. I ran your script again and pulled the latest adguard and it began to work (the script could detect the original glinet adguard home build number however it wasn't running on the router and wouldn't ever enable). So my question is this.
By choosing to NOT make the adguard script persistent does that mean you have to manually run it if you upgrade / downgrade the firmware to actually make adguard work again. When I upgraded / downgraded the FW I chose keep settings. My guess is that because I have ran your script, it then moves some adguard home files around from their default locations and as a result of restoring the firmware and choosing to keep settings the officially supported glinet adguard home files are not pointing to the correct location? Is that right
I'm guessing the persistence check (if enabled) will force adguard to point to the correct location upon upgrade and downgrades..or maybe it's just a bug because I'm keeping settings and actually I don't want to be keeping the settings for adguard as they are no longer default settings...
Exactly.
If you don't choose to make the changes permanent, every firmware flashing will install the older version of AGH again. Since the config.yaml will not be replaced with an older one, AGH won't start because the config is for a newer version.
"Keeping settings" will not keep installed software, that's the issue but it is by design.
I thought as much. So if we choose the option to NOT make the script permanent then obviously we could unknowingly run into the issue of adguard not running. Now I'm guessing that when you make it persistent then you are adding a run command when the system detects it's been upgraded?
What if you have a different command that either copies the original config.yaml or extracts it's from the backup that your script ends up making prior to upgrading. So for example, we choose not to make it persistent however the script knows it has run and upgraded so therefore it adds a command to replace the config file back to the original or restore the original backup altogether upon upgrading or downgrading?
Maybe the script can create a config yaml backup per version of upgrade and be named as per. Config-v.xx.yaml for example and then the script detects the current adguard (the version that glinet shipped in it's firmware relase) a bit like the script can detect now. Then when the script checks to see how to restore the config it can pull the correct / matching config version for the currently installed adguard home and run a command to rename it back to the default config.yaml? Then the default adguard home should work again?
Again I guess that's only applicable if you choose keep settings? Am I right in thinking, if I hadn't have chosen keep settings then after I had reflashed, the config.yaml would have been the default that glinet used and therefore would have started correctly? (Again, choosing to not make the script permanent)
You think waaaay to complicated about the "Keep settings" thing. It's not intelligent, it's just a pretty dumb thing. By writing files / folders you want to keep to /etc/sysupgrade.conf they won't get overwritten by firmware flashing. That's all.
So my script will add /etc/AdGuardHome (the data storage) and /usr/bin/AdGuardHome (the binary itself) to the /etc/sysupgrade.conf - not more, not less 
I wrote my old instructions about update manual Adguard home and always copy only config.yaml
Inside config.yaml does not match version Adguard home, just simple delete old version and will be installing Adguard home, fill any login and password and port. After that update Adguard home from @admon script or manual update Adguard home. Finally delete config.yaml and paste your original config.yaml which modified with GL UI.
1 Like