I was busy with something else today so when my Flint2 suggested a firmware update to v4.7.0 I (perhaps unwisely) just accepted the update via my WiFi-connected phone without thinking too much about it.
10 minutes later I got that "oh no..." feeling when I realised the router had dropped the network (no surprise in itself) but was showing no signs of coming back. The front panel LED was alternating between white and pale blue (such a subtle colour change that it's actually hard to see), but I could not talk to the router over wired or wireless connections.
Wary of bricking the router I left it, in case it was just a really slow upgrade process, but after 20+ minutes I gave up and power cycled the router. To my relief it came back up, but it booted back up into the previous version (v4.6.8). It again offered me the v4.7.0 upgrade, but now i'm wary of risking this upgrade and having a dead home network for Christmas.
Can anyone enlighten me on-
Does the v4.7.0 firmware have known auto-update issues?
Does the Flint2 do a form of "atomic update" and roll back automatically if an update fails, or did the v4.7.0 update simply not happen in this case, but get stuck somewhere early in the process?
Is there anything I can do to give myself a safety net before I attempt an update, or is the risk of a bricked router always there and one just has to hope?
I gonna play the devils advocate here, the awnser is yes there are certain risks involved therefor with normal openwrt automatic updates don't exist by default for this reason.
Is it supposed to be bad?, no.
But the issue hides in that the images are not always checked manually, it is a build server so the images are auto generated, i'd still think they should test images more, and i mean more on multiple platforms with the same gl sdks.
Not certainly, but yes openwrt has some sort rollback as safeguard against unaware users which might plug the router, but don't trust me on that, i only know it from my own experience when i immediately plugged the coord after realizing i was using the wrong img, sometimes you are very lucky and it rolled back, but 100% you are finding yourself at a edge corner which could easily brick.
^ though images are checksum checked, so you don't have to worry for a damaged firmware it will warn
I recommend to always hold a older image which works, preferly with u-boot too, luckily most gl routers have u-boot this makes debricking very easy.
You can expect the images to be safe, but not 100% due to the automations, often when a router has less attention/popularity drive, then you should be more aware of this, i think devs should test all builds and not blindly assume it will work on consumer equipment which i see sometimes happen or i get that assumption this occurs, but that is my opinion.
It looks as if the router didn't quite return to a clean version of the previous firmware (v4.6.8).
I have the router set up to stream music from a flash drive via MiniDLNA, but i'm now finding that-
If I stream an album, after about 6 tracks the MiniDLNA service seems to go offline and the music stops.
If I look at the router admin pages when this has happened, the bottom of the "Network Storage" page is unpopulated. I.e. the status for MiniDLNA and Samba is not shown
After refreshing this page a few times and trying to access the files over Samba from a client, the router comes up with an error saying "Unknown error occurred. Please check the network environment or reboot the device.", if I try to reboot from the UI nothing happens.
So, looks like one way or another this update has damaged my existing firmware. I'm not sure how to proceed at this point. I could try a factory reset of v4.6.8 and redo all my configuration, which would be a pain. Or I could try the upgrade to 4.7.0 again but i'm very wary of that as this version triggered the fault in the first place.
Unfortunately i don't have much knowledge about the 2 features only that samba does buffer on memory especially when transfering files and for a long time it can crash.
Honestly i think samba shouldn't be a process running on a router due to it's heavily cpu utilisation and caching, maybe im wrong its just my opinion
@bruce do you know if this can be a bug in op's situation?
I would say disable all plugins in the future firmware but be unlock to warning message to unlock for use plugins.
Most people not use plugin as standard router.
hmm recently i managed to have something similar on my own build environment (without gl software).
What just happened to me is:
I upload sysupgrade, i see the ui and 3s later crash, i reset and i make some changes and reboot, after reboot it shows like it was reset.
^ kinda like a ramdisk
but what i think:
maybe there is some kind of build env contamination going on in correlation with the recent apk commits, but then more people would have this issue.
or it happened due to invalid symbols into the configuration like < >.
make dirclean and rm -rf tmp/ did not work still outputed these strange images where filesystem showed as readonly, it only fixed it when i attempted a clean git clone from openwrt.
Never seen this before, but wanted to share in case it is some weird unknown build env contamination or symbol issue on the config files on the router.
On my own second Flint 2 (op24) serving as backup vpn server, and my MT3000 (MTK) they both run fine on 4.7
When we release the firmware version, the GL SDKs have been undergoing regression tested.
Flint 2 or other models has not received more issues feedback about upgrade failed. At present, probably the custom configuration may affect the upgrade.
If this issue occurs again, please export the configuration to us, let us try the pressure test in the lab to reproduce this issue. Thank you.
This is my suspicioun to, i recently upgraded my own baked config with placeholder text in the config with symbols like: <, > in the network configuration on fields for wireguard endpoints (luci-proto-wireguard).
Maybe these symbols caused these strange symptoms like op is experiencing aswell.
message to unlock for use plugins.
