I just updated Beryl Ax to 4.8.1, and as with 4.8.0 and 4.7.4, starting from 4.7.3, “keep settings” freezes my GUI and Luci, and I have to reset.
Okay, I customize it a lot, even touching the gl etc, but you could consider an incremental upgrade, based on the individual lines modified in /etc, or publish the list of modified files.
You could also do more on the restore. I made a script that restores the overlay to a tgz I set, and I linked it to the switch button, but you could implement it in the reset button, letting us choose a point where we set passwords, wifi, and stable scenarios, without going through Luci or SSH, and above all, letting you manage upgrades.
I say this because I am enthusiastic about the product and find it absurd that such simple aspects are missing.
I'll add this here, even though it might be a separate issue, because it may be related to the problem of settings being lost with every upgrade.
/overlay/fs_state -> 2 ... is there cause for concern? It usually 2 indicates a critical problem, and since I suspected that the cause was my recovery method, I tried everything: two firmware versions, both from the GUI and from uboot, each time trying the reset from the GUI, from the button, from the shell with firstboot with and without umount and reboot. On reboot, it even forgot the serial “nick” it adds to the end of the default ssid, but fs_state remained at 2. Maybe this is normal, but I'm asking for confirmation or a method to bring it to 1, like seems could be. The link and dir show the firmware date, if that's useful.
@9b9e69c2-4b75-4420 So I'm not the only one. But not just the GUI, what does it take to do it in the reset button in 4 seconds instead of that network reset that is only useful for exiting the access point. GL really does the impossible in the GUI, but if you want to clean up massive things that leave residues, you have to start from scratch and even put in the SSIDs. And then only they can handle the upgrade.
I couldn't tell you. The deeper I dig into these GL devices the more I'm inclined to treat them ((hen using the stock GL firmware) as a simple appliance rather than a SBC. I track my deviations/customizations quite closely because I've nearly bricked once or twice due to unexpected differences in the confs.
After I'm done setting up Slate AX's v4.8.90-beta9 in preparation for a stable release I'm just going to flash back to pure OWRT as I'm not travelling. I'll use GL firmware+tarball before I do again. I'm really starting to think it's not worth the hassle for a stationary router/gateway/AP/whatever... not if one intends to push the limits of this pretty damn nice hardware.
The hardware should work better with GL firmware. But personally, with OpenWRT 24, released by GL on the MT3000 for GUI support, admittedly not with their drivers but with the native OpenWRT ones, I haven't noticed any difference in performance. But I have noticed that GL integration takes a lot of the burden off, as their pre-packaged solution takes care of making service configurations that would otherwise block each other work together.
I don't know what to tell you about SBC. VoIP is now only cused by companies to distinguish themselves from spam, and mobile costs are now only data. If by stationary you mean large, the same applies, for 2.5Gbps, you can do without it, but if you want to take advantage of 10Gbps, okay, but don't just choose the size. It's like talking about smartphones being more powerful than PCs, unless you really spend money on your PC.
"Better" throughout put as advertised I would suppose but at the cost of the flexibility modern, pure OWRT provides. The Slate AX still relies on QSDK to meet GL's marketing. The Beryl AX relies on MTSDK but as you noted there's v4.8.0-op24 also available for that particular model. The Opal relies on the Siflower SDK which runs on OWRT 18.x IIRC.
I mean stationary as in not changing locations/not travelling/not relying on Wi-Fi hotspots/captive portals (eg: hotels).
The pure openwrt issue seems to be the answer to fs_state->2 ... the MTSDK drivers are loaded on the overlay and their errors pass as overlay_fs errors, so without MTSDK fs_state would be 1.
However, the problem remains that with every upgrade “keep setting” crashes, I have to reset and redo everything, even a backup is useless.
Sorry for misunderstanding SBC, but we were talking about routing. I tried the NanoPi R5C, which costs more than the Beryl AX on Amazon, and it's great for running Linux, but its routing performance is really poor. As for Linux, I'll just run a VM on my PC. I consider them just toys, while I consider the Beryl a device.
... that should most definitely not be happening. I'd really open a new thread & post logs, output & whatever else you can so GL can try to replicate & confirm the issue. You may have stumbled on a bug.
IIRC 4.7.x -> 4.8.0 was a 'breaking' upgrade due to the introduction of PBR as various confs were rewritten. I think it was mentioned in a changelog but I can't exactly recall if/when it was for the Beryl AX. That would render all previous tarballs/backups incompatible but that only applies to backups & not the 'keep settings' component.
Sure, 4.8.0 came out just as I was going crazy with pbr via Luci, until I read that 21 has a bug on domain-based policies. It solved everything for me, and I was able to close adguard, which I only used for DoH.
However, I have no log if I have to do a hard reset during the upgrade, because I can't even access it via ssh. I am basing myself on the scientific concept of repeatability/madness (hoping that something will change, trying in many different ways... an isolated setting). These are total problems, like on the be3600, and I can provide the obvious inconsistencies or the comparison of scenarios, but the developer should indicate the grep to put on dmesg. If the problem were limited, such as “the pbr is distracted,” you would usually get the grep even from an expert user.
Going back to IoT... I was planning to switch to the NanoPi M6, but at that price you can find HP mini PCs, which consume little power and you can leave on, and good used Android devices, put Tasker on them and run a factory! But I found the GL while visiting them, it appeared in searches for OpenWRT One.
Between you & I IDK how I could properly manage these devices without git. I keep my tarballs in a backup dir as 'known good' for restore points but I'm not exactly faced with the same troubles you're experiencing.
I think my next router is going to be a NanoPi R6S. It's been tested to 1.1+ Gbps over WG. The form factor & fanless construction is more appealing to me but you make an excellent argument for a HP 800 mini Gen-whatever & OWRT x86_64.
I used to store them on my PC, then install sftp ... but the cgnat of the new ISP (I hope they accept my request for a dedicated IP) forces me to go through the firewall via Vi first. So now I leave the tgz in /overlay and restore it even after a reset, even in the event of a crash, using a script in the switch button. Obviously, for the fs_state tests, I left it clean and only entered the root password. As for the complete setup, it is very heavy but does not cause any problems until the upgrade. Next time, if it happens again, I will look for a way to save debug information.
The R6S should do 2.5Gb, like the R5C, which only did 0.4Gb for me on the ISP where Beryl reached 1Gb, both in pppoe on the ont. If I had to spend money, I would definitely get an M6 from NanoPi, with or without a screen, as it is powerful and fully supported by Armbian. The R5C in VNC is powerful, but I repeat, it's a curiosity for enthusiasts, like a bonsai for a florist. For practical uses, there are more suitable products... unless you get it without a box for electronics testing, like an Arduino.