In fairness I have some sympathy for that mistake in this case. If you’re just looking for Beryl and don’t know about the unreleased AX model, that’s understandable.
I have been able to load 4.1 going the Uboot way.
Thanks for this
1 Like
Installed 4.1.0 beta3 2 weeks ago, and I’m happy to report that the device is running smoothly. No disconnect whatsoever.
What I do with the device:
- Configuring extroot using USB Disk
- Repeater Mode, connect to Main Router 5G Wifi at home
- Repeater Mode, connect to Ubiquiti AP (2.4G), WPA-Enterprise PEAP-MSCHAPv2 at office
- MAC Clone
- Setting AdGuardHome, and update it manually to latest version: v0.107.20
The only problem when I installed it first time was Update Package failed - trying wget Packages.gz return Connection error: Invalid SSL certificate.
What I did:
opkg install libopenssl --no-check-certificate
opkg install openssl-util --no-check-certificate
opkg --force-depends remove libustream-wolfssl20201210
wget https://downloads.openwrt.org/releases/22.03.2/packages/mipsel_24kc/base/libustream-openssl20201210_2022-01-16-868fd881-2_mipsel_24kc.ipk
opkg install libustream-openssl20201210_2022-01-16-868fd881-2_mipsel_24kc.ipk
opkg update
I had a nice long post with details, but as a “new user” it would not let me post.
(“can only post two links” - what does that mean? I had no links, just some quoted SSH output blocks, and removing the quoted blocks did not help).
The short version is I have started to see squashfs errors after 4+ days of Beta 3 uptime.
The router is still working to provide fire-walled internet over WiFi, but LuCI is not accessible, and some of the main web interface pages say “Not found”.
‘logread’ in SSH shows these types of errors:
Sun Dec 11 08:30:51 2022 kern.err kernel: [406181.099712] SQUASHFS error: xz decompression failed, data probably corrupt
Sun Dec 11 08:30:51 2022 kern.err kernel: [406181.106817] SQUASHFS error: Failed to read block 0x102d9be: -5
Sun Dec 11 08:30:51 2022 kern.err kernel: [406181.112837] SQUASHFS error: Unable to read fragment cache entry [102d9be]
Sun Dec 11 08:30:51 2022 kern.err kernel: [406181.120168] SQUASHFS error: Unable to read page, block 102d9be, size 36d48
I will reboot the router to see if the squashfs errors go away.
So hopefully the Nor flash is not going bad, you can try to reinstall the firmware again. Did you use uboot or GUI Upgrade. Did you keep settings?
I do not work for and I am not directly associated with GL.iNet 
It is easier to get an exchange and return the one back to me to do some investigation.
Can you talk with the customer service? If possible return back to me to HK. Otherwise just return it where you bought it.
MT1300 takes longer, e.g. 10 mintues because it has 32MB Nor flash.
Nand flash routers takes 2 minutes only.
This is a brand-new device, so it seems impossible that the flash would be going bad. Is this something that is common with GL.iNET devices? The flash should have hardly any write cycles on it - and certainly not in the section that is holding the read-only squashfs root filesystem.
I used LuCI from the 3.215 firmware to upgrade to Beta 3, and did not save any settings.
That was on Dec 3, and not until Dec 11 did I notice anything wrong. The GL web interface and LuCI worked properly, and no squashfs errors showed up in the system log - until Dec 11.
The device had been up for over four days at that point.
I was poking around in SSH trying to figure out which ‘/romfs’ files were generating squashfs errors, and as I was doing that things got worse.
So I finally rebooted, and it seemed to be bricked over several power cycles, but eventually I was able to log in and get internet through it again. ‘logread’ shows some squashfs errors early on, and the GL web interface is only partially functional. LuCI lets me log in, but gives an error soon after.
I will try U-Boot to re-install Beta 3 and see what happens.
I was having a lot of WiFI disconnect/reconnect issues with Stable 3.215, so I don’t really want to go back to that.
Finally got Beta 3 re-flashed with U-Boot. Didn’t seem to work the first time - waited 20+ minutes, and when I re-tried accessing 192.168.1.1 with my browser it went back to the U-Boot firmware load screen. I tried again with the Beta 3 firmware .bin file, and after a while it worked. I had to power-cycle the router to get it to provide my laptop a 192.168.8.1 DHCP address.
Soon after getting the DHCP IP, I SSH’d into the router and did a logread.
There were a few squashfs errors at that point, but both GL and LuCI web interfaces seemed to be fully working.
I did another reboot (not power cycle), and logread that time showed a lot more squashfs errors, and now both GL and LuCI web pages show “This site can’t be reached”. SSH still works, but no web interface.
So somehow I guess my NOR flash is damaged?
I’ve worked in embedded HW/SW for many years - including with U-Boot and embedded Linux using NOR/NAND flash, JFFS2 and squashfs, and can’t comprehend how NOR flash could get “damaged” so early in the life of a device, and just by updating firmware?
I guess this router is now useless for the rest of my remote work trip.
It was purchased through Amazon US. At this point I’m not sure that I want a replacement, but if I decided to do it, should that all be done through Amazon? Or does GL.iNET want my router to be sent somewhere else for examination?
This is very similar to my experience I described above
I think if you u-boot 3.215 firmware your router will work fine without errors
So far I found several discussion for this error in openwrt forums and my take from there is:
- Once you get a SQUASHFS error it will persist until reboot because SQUASHFS corrupt the cache and doesn’t attempt to re-read the media. Essentially, if you hit it, it’s fatal, the affected package won’t work until you reboot or there might be kernel panic. You might get the same error after reboot or it might happen later. There is a patch that helps to minimise the impact by forcing SQUASHFS to invalidate corrupted page in memory and forcing it to re-read so transient read errors don’t cause fatal errors
- There were many reports of suddenly experiencing this error when upgrading openwrt from 19.x to 21.x and it might be something in moving from kernel 4.xx to 5.xx
I won’t be able to return until the end of January. I purchased via Amazon Australia and they have returns extended until 31st of January so I guess the most viable option will be to send it back to Amazon
I don’t think it’s damaged but more like the hardware design of this router is not fully compatible with Openwrt 21.x / 22.x - there are many reports of exact same issue and when rolling back to the older firmware the error disappears completely
You can always back to up within Warranty period.
Thank you for that. I hadn’t thought to look at the OpenWrt forums.
This is a Beta release after all. I was just frustrated that after upgrading to Beta 3 I thought my short-term problems were over (WiFi disconnects). That was the case, but then seemingly all of the sudden this squashfs thing appears.
I’ll use U-Boot to go back to 3.215 for the time being, and only use it when I need the Ethernet ports.
An issue I have with beta 3 is that all Wifi clients loose the connection to the Beryl Router. They don’t re-connect by switching the wifi on-off. You need to reboot the router. LAN clients stay connected. Anybody else with this bug and anybody an idea how to fix it?
Thx!
My LAN-side WiFi connections didn’t have any issues that I noticed in the 8+ days that I ran Beta 3.
I did have unstable WAN-side WiFi (connected to a router that I don’t control, which in turn is connected to a cable modem). Mostly the WAN-side WiFi was fine, but at one point it was having trouble staying connected. As I just wanted to work, I simply changed the Beryl WAN-side connection to Ethernet. It may not have been a Beryl Beta 3 WiFi issue at all.
Beta 3 worked well for me overall - except for the squashfs issues that eventually made me give up.
Unfortunately, I’m remote at the moment. I’m able to access the router via GoodCloud and see that all Wifi clients lost connection. Any idea how I could trigger a re-connection? I don’t want to reboot, since the router is tethered to the internet and after a reboot, the tethering will not be re-established automatically. Any idea? Thanks!
can you turn off wifi and turn it on again via cloud?
Yes, I tried that already. Also changing some parameters like Wifi channel, 2.4GHz/5GHz. Unfortunately without success, the clients don’t re-connect.
Can you export the logs? Does the router contains logs that the client reconnect?
If no logs about this, it seems that the wifi signal is gone so wireless clients do not connect.
It is nice to check the log if there is anything causing this problem.
If you can ssh to the router via cloud, also try reboot the wifi using command “wifi”.