If flashing an up to date version on both partitions and rebooting into one of them doesn't make it stable, consider that you may have a hardware failure, for example bad/marginal RAM chips or corruption in the flash chips or something overheating, unstable power, etc. You also might try replacing the power supply with one of equivalent or improved specs. Random reboots are rarely a user-land software problem and are usually either a buggy driver (but this is kind of ruled out by the fact that others don't experience the same thing) or hardware issues.
4 Likes
thanks, im trying this now
ive never validated the hash before though and not really sure how to
when i go to Flash Firmware, select the file and click next, it gives me:
Checksum
MD5:4d0787cda31621aee7c06ebc339bd70f
SHA256:1f230e7d2091435a7bd19118d438ddde386d18b6c89de684195847123179714c
before the final proceed button
i was trying to use http://onlinemd5.com/
i select my file (downloaded it twice and the results are the same)
i select SHA-256 (MD5 doesnt match either)
it reports the file checksum as: 2DF0EC7A1EBA57EFAAD5EA695F3975B68FCF3B6D2EE1FF4C6BA9ADD53A866459
i expected it to match what openwrt is saying ie 1f230e............
When I go to download your sysupgrade image for your device it's here:
https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/
In the middle column, next to the sysupgrade file is an sha256 hash which says:
1f230e7d2091435a7bd19118d438ddde386d18b6c89de684195847123179714c
which if you compare to what the OpenWrt says when you upload the file indicates that it's the same file as what the download site at the OpenWrt page expects it to be.
Let's ignore the onlinemd5 results for now as all that matters is that you upload to your router what you should be uploading, and you are.
Now, flash this file, making sure do not keep old settings. Then reboot, which will cause your system to boot the new image, and immediately flash again which will overwrite the other partition. Each time you flash make sure to check that SHA256 sum against the one above.
After you've flashed both partitions, then whichever ones boots up next, configure that one the way you like it and see if it has problems.
1 Like
well 1d 18hrs and going strong!
thank you all for the help.
the only thing i haven't set back to the way it was is the exroot/overlay and i have a feeling its a major player in terms of the reboots. I could be wrong, and i probably should test it, but i have been spending a lot of time troubleshooting lately and i just cant spend any more right now
idk if size matters 
but my overlay/exroot is almost 200gb (when its configured). maybe that was too much. or maybe it was the fact that having a data partition, overlay and swap partitions are too much for a single disk. And that was my original configuration, along with another same size hard drive that used rsync to back up my data partition every night.
It sounds like you might want to run a NAS separate from your router. Glad you got your router working.
1 Like
@Owengerig If your problem is solved, please consider marking this topic as [Solved]. (Click the pencil behind the topic...)
1 Like
idk what to say, just had a random reboot, so maybe i marked as solved a little early, ill keep monitoring and updating this post
yesterday i needed to downgrade a driver due to timeouts (see this post for more details on why, Problems with wifi connection)
maybe that is the root cause
ya, it happened again in the middle of the night, issue is NOT solved 
Curious how you know that your router rebooted in the middle of the night? What problem did this cause you? If my router were to reboot at say 2am I'd probably never know it except that I send my logs to a separate log server. In other words, the router comes back up and is functioning normally. Since you have detected that it rebooted I'm guessing there's "something wrong" can you describe what it's doing? it may give a clue about what causes the reboots.
1 Like
i monitor uptime and logs. Its not always in the middle of the night (though it did happen again last night ). I work from home and am in meetings often, so random reboots are a show stopper for me. plus this is "suppose" to be stable, but that doesnt seem to be the case for my device.
I wish i had more concrete information in hopes of a resolution but this whole post started on how to get more information on random reboots and was redirected to reloading.
im sure there is a bug somewhere but i guess i need to test more to find the root cause.
I think it has to do with the driver for the wrt1900ac but even that im not sure on. especially since today my rsync backup script caused another reboot (and the one from last night might be from the scheduled running of that same script). saying that however it ran 8 days without problem (backup scrip included) until i downgraded the driver [due to timeouts in wifi connectivity, see link above]
anyways ill try to investigate further when i have time.
Got it. That makes good sense. I have a WRT1900acsv2 and it never reboots randomly. I find that if I power cycle it every few weeks it prevents some weirdness with wifi eventually becoming mildly unstable (android devices start to constantly reassociate). It doesn't seem like it's enough to reboot it, it actually needs to power cycle. So every couple of weeks or so I power cycle it in the morning. It's not my router though, it's just a fancy AP. If I do this power cycle thing it's pretty rock solid.
EDIT: in case it's not obvious I'm not advocating switching hardware, but rather that your hardware should be able to be pretty darn stable for weeks at a time, but you might want to actually power cycle it every so often.
From your post in the thread of the community build, this thread is the one where the idle issue was resolved. That fix is in master and all the 18.x stable releases.
1 Like
but Davidc502 in post (Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds) is saying I need to upgrade to 18.06.02. Which leads me to think its not fixed in 18.06.01.
Well, the 18.06.1 git log would be the definitive resource. This fix, but no reason to stay on .1 release, but I would not expect it to resolve the issue at hand.
1 Like
Seems to me, and I'm only going on memory, the issue wasn't resolved completely until 5 or 6 months ago. Time goes by so fast I could be way off and not know it.
When I search the git log, it appears a patch was created last March which would mean that .01 would have been covered (patched).
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=5faa9556b1c10a4b21208615bddb7480401fa213
However, it seems to me people were still having issues with .01. This was a post from last December.
Bottom line is, and I agree with you, there is no reason to stay on .01.
1 Like
its funny cuz for 18.06 and 18.06.01 i was watching the boards every day religiously waiting for their release but 02 i missed it completely
at the start of this post i reloaded, and it took a few days maybe even a couple weeks to really start happening (though i will say it seemed to progressively get worse, as it started happening alot more frequently)
but ill report back my results
thanks all!
somewhat of a side question here
does .02 include the latest mwlwifi drivers and firmware?
normally i wait to see timeouts before installing the latest mwlwifi drivers and firmware from:(https://github.com/eduperez/mwlwifi_LEDE/releases)
kmod-mwlwifi_4.14.63+10.3.8.0-20181112-e5e07002-1_arm_cortex-a9_vfpv3.ipkmwlwifi-firmware-88w8864_10.3.8.0-20181112-e5e07002-1_arm_cortex-a9_vfpv3.ipk
when i look at whats installed i see:
kmod-mwlwifi 4.14.95+2018-11-14-81..9-1
mwlwifi-firmware-88w8864 2018-11-14-81413aa9-1
so it looks like the included driver and firmware is newer 4.14.95 vs 4.14.63 and 2018-11-14 vs 20181112
but these seem to be a generic driver and so idk if maybe the ones from the eduperez are better for my device?
my understanding is that as of today (mid Feb 2019) yes the latest drivers are already in 18.06.02
2 Likes
Actually, this commit is the one of interest. If you check the mwlwifi repository there are a few commits after that version, but nothing of interest for this device, which I assume is the reason no-one has bothered to push any of those commits. And there is not really such a thing as generic mwlwifi driver; or, you have the latest and greatest.
1 Like