I need help troubleshooting random reboots
I have been monitoring the system and kernal logs but never see the cause of the reboot. Any suggestions on how to further troubleshoot?
openwrt 18.06.01
wrt 1900ac
If this was some general issue, there would be more similar reports. I would start with a standard config and no packages added, and later would change the config and add more packages, to try to find where is the issue.
2 Likes
i guess i was hoping for better understanding of the logging then
kernal log starts from 0 so i guess it always starts fresh on boot
where as system log has timestamps and so i figure its persistent through reboots
i know most linux distros have 'last' but not openwrt
which i guess probably doesnt matter because im not seeing any errors about the reboot
idk maybe i should up the log level but errors are what would cause a crash so idk how much itll help.
i also dont get that there are gaps in the log
Wed Jan 23 12:30:16 2019 daemon.info dnsmasq-dhcp[3018]: DHCPACK(br-lan) 192.168.1.115 14:10:9f:d4:ad:fb Das-MacBook-Pro
Mon Jan 28 05:47:31 2019 user.notice transmission: Starting with 126016000 virt mem
I have another question on here (Usb drives missing)
when this happens i lose my overlay and some settings
maybe thats where the gaps are coming from, idk
I strongly suggest re-flashing from scratch without keeping configs and then see what happens, perhaps you have some kind of corruption issue. Most people with WRT1900AC are having zero random reboots.
1 Like
Incorrect.
I also advice you start working from default settings.
i have a few times over (Missing libc dependencies)
but i always reload the same apps (ddns, network shares, transmission, and minidlna)
and reuse configs
Your other thread suggests you get different behavior each time you flash the device. I believe that this device has two partitions, and you may be booting randomly into one and then the other, and getting confused about what version you're running or whatnot. My suggestion is to flash the device, boot into the newly flashed partition, and then re-flash the device once more and reboot. This will put the same up to date confirmed version on both partitions. Make sure you use sha256 hash to ensure you are flashing a non-corrupt version.
2 Likes
When your router boots, as virtually no all-in-one wireless routers have a battery-backed RTC, time is set to the time of the most-recent file in /etc/ -- usually sometime in the past. Once NTP sync is obtained, time is adjusted to the current time.
Logs are in kernel memory, by default, so they do not persist over boots. /tmp/ and /var/ are memory-backed file systems, so they are not preserved over boots. The easiest approach is to run logread -f (as I recall) in a terminal and hope that the error is logged before the SSH connection fails. Remote logging, or logging to a robust file system mounted on the device is another way to see "crash logs". Flash file systems are not recommended for the kind of writing that logging generates; it will dramatically reduce the flash life.
3 Likes
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