I hope this topic is okay to ask in here. It may just be a Linksys hardware type question and not an OpenWRT question, so my apologies in advance if this is inappropriate.
Several times when I went in via Luci to either change or add something, or to do a sysupgrade I was surprised to find I was booted to the older version on the other partition (I have advanced reboot installed so it is easy to see what is installed and what partition I am on). This is rather dismaying because the security issues I upgraded to before were not implemented.
I pondered on this for the longest time and then realized this seems to happen after we have a power outage. I do have a UPS, but when the power goes out I still have to shut down. What it does when shut down I think is boot back up to the other partition. I know now that when this happens I must log in and switch it back to the most current partition.
My question is, is this normal behavior for a WRT1900acs running OpenWRT with luci-app-advanced-reboot installed? I have read the following article, and when you scroll down to the part about the power switch you can see what must be done to get it switched over to the other partition (I needed to do this once, so I am familiar with how precisely you must follow the directions). It makes no sense this is just switching partitions on a power cycle. Hence my asking in here...
The only other thing I can add is that when the power goes out I have been turning it off by turning off the UPS and not first turning off the power switch. Hence, I am effectively just 'unplugging it'. I wouldn't do this if I had realized this before now, but it just hit me as I wrote this up that that was what I was doing. Any thoughts on this, or tests I can run would be appreciated.
It doesn't happen if you just lose power once, it only happens if you lose power three times in a row before it manages to boot up completely at least once. This is a basic feature of these dual-firmware Linksys devices and works independently of luci-app-advanced-reboot being installed or not.
Have you let the UPS run dry and watch what happens?
Some UPS (like Schnider power pro) cut power and stay that way until power line is restored. Some donât.
Since thay have lead acid batt the batt voltage will rise when the battery is emtied and the UPS cut off output. And when the batt voltage raise a little the UPS see life again and turn on the output. The batt runs dry quicker and quicker every time this happens. Finaly the UPS is going on-off-on-off-on-off every second or so. Can be doing this for daysđ
And what do the UPS do with the output when you turn the power on again?
Try to put a manual power switch on the UPS power output and cut the mains.
Turn the router off with the manual power switch and let the UPS stay on. Reset power lines to the UPS and turn on the manual power switch to the router. Is the problem solved?
And the funny thing with these routers are that when they emergency boots on the other boot up they copies the working side to the non working side. So then you have the old boot on both boot partitions.
Yes! Tried it both by accident and by choice on my WRT3200ACM. It is the routers fail safe function. It assumes the boot partition is corrupt when it canât boot and when it manage to start in any boot partitions it will install a âworkingâ boot copy to both partitions.
The whole purpouse of the function is to have a working partition (the original Linksys) in the unused boot partition. If you get cought outside the router with OpenWRT you just save the day with this.
These routers was built only to make it easy for the customers to install OpenWRT. They never had any real idea to work with Linksys firmware so I guess the original firmware is 1.0 even today.
Never, ever, seen that behaviour on any of the 3 different wrtpac devices I have owned (mamba, shelby, rango). When I have created a non-booting partition, it stays that way until I explicitly deal with getting a working image installed to the bad partition.
As far as I know, and my own experience shows, the device will try to boot three times into one partition, then just boot into the other one; I have never experienced or read about any copying between partitions. And both partitions on my device have OpenWrt installed.
B/c the current snapshot failure, when using ImageBuilder with my list of packages, it doesn't fail but instead generates a non-bootable image
Symptom is that it boots and nothing happens, no LAN/WIFI connectivity and does not auto-restart
Had to do the 3 times power cycle thing to get it back to my old firmware
After that, in luci-advanced-reboot, shows that the other partition has the latest firmware (5.4.98), so I assume it's not wiped after a failed boot attempt
I believe it will stay permanently on the "old" partition, UNTIL you flash a new firmware into the "new" partition; so the fact that the "new" partition has the broken firmware doesn't really matter, since it will not try to boot from it UNLESS you manually specify it via luci-advanced-reboot. You're supposed to fix it by flashing in a good firmware that will overwrite the "broken" firmware in the new partition
This is on a rango but I also tried it on a mamba, exact same behavior
The behaviour you describe would be expected of an image that boots fine, but has an issue, so that would be expected. But what is this current build failure, I just built a 5.10.x image from current master and everything seems OK.
Sorry, mis-spoke here, not sure what to call this kind of failure.
Ran into two issues with the current Image Builder/pre-built firmware:
Image builder with luci + acme + a few of my normal packages builds successfully, but resulting in a firmware that boots but doesn't have LAN connectivity (thanks to linksys's dual firmware, saved my ass)
Installed the pre-built firmware of snapshot (downloads.openwrt.org), and tried installing luci with opkg. opkg goes through without error, but uhttpd is broken b/c it cannot find libubox.so. Something to do with the new ABI version changes Error loading shared library libubox.so: No such file or directory (needed by /usr/sbin/uhttpd)
Trying to compile the image now from source instead of Image Builder...
Thanks for all the replies. I really need to run some experiments like @flygarn12 suggests, and some others. My process so far has been the power goes out (usually expected based on the conditions outside), the UPS starts to beep, I shut my comps down, then turn off the power button on the UPS. I then unplug the UPS so they (I actually have several) don't have to take any surges when the power comes back on. I then plug them back in after the power is restored, and then hit the UPS power button to send juice to the battery protected outlets.
I was just wary of experimenting for fear of messing things up. Hence I was hoping others had seen this and I wouldn't have to try some things myself. What I will do is try some powering down with the power off switch on the router, as well as what I have been doing (without realizing it), which is just pulling the plug on it (powering off the UPS). I will also just literally pull the plug out of the UPS, and also try this when the UPS is activated i.e. pull the UPS cord from the outlet first. I'll report back what I find. I could have done all this first, but was hoping there was an easy answer already known on this. It may take me some time since taking the entire household off the Internet is going to garner me some flack.
There have been a few power outages that happened in the middle of the night and although the UPS was nowhere near depleted, it had run for a bit before the beeping woke me up. It is possible, although I'd think unlikely, this caused some issue that rebooted the router multiple times in a row. And since I didn't figure this out until recently, I don't know if this issue has happened every time the power went out, or just some subset of times...
I have thought about that as a possible solution, and it may be the approach I take. I could also test an upgrade for a few days and if it works then double up on it, just to have a little assurance. I could always attempt to revert if it started to have some issues. I assume you can do a sysupgrade to an earlier version without issue?
