#22121: Bootloop on CHAOS CALMER caused by S00sysfixtime and a scheduled reboot
-----------------------------+--------------------------------
Reporter: gold-eagle-wifi | Owner: developers
Type: defect | Status: new
Priority: normal | Milestone:
Component: base system | Version: Chaos Calmer 15.05
Keywords: |
-----------------------------+--------------------------------
Hi guys!! it is a pleasure to write here for first time,
I have found that due to the delayed startup of ntpd service and the
sooner run of S00sysfixtime and S50cron we could ended up in a bootloop
after running a cronjob that reboots a router on controlled conditions, (I
know it is not the best idea to schedule a #reboot command, but, in the
other hand, I do not think that I am the only guy in the wold doing such
thing).
So, further explanation
* Lets say it is 1:59:xx and we have a scheduled crontab to run at
2:00:00.
* It is a script which decides to reboot or not, and, this time it decides
to reboot because blablabla or it might be just a scheduled reboot at a
fixed time once a day.
* So we are now rebooting....
* Load kernel and other stuff until it calls /etc/rc.d/S00sysfixtime...
{{{
START=00
boot() {
local curtime="$(date +%s)"
local maxtime="$(find /etc -type f -exec date -r {} +%s \; | sort
-nr | head -n1)"
[ $curtime -lt $maxtime ] && date -s @$maxtime
}
}}}
* Ok, I understand that the person who wrote these lines was some kind in
a hurry to get the system time more or less accurate during the boot.
* Here is the problem, when it sets the time "date -s @$maxtime" it is
setting the clock a lot of seconds slow, furthermore, a router could take
60 seconds to reboot, so one of the first things this device is gonna do
is to set its clock barely a minute slow, ie 1:59:xx so, after a couple of
seconds... guess what...
* reboot...
I am not requesting the dev-team to change it for me, furthermore I could
imagine some reasons to do such kind of things soon during the boot.
I would just like to let you know that this boundary condition is
reachable and we could end up in a bootloop.
It is very hard to fix it via luci, because we have just a bunch of
seconds before the router reboots again, instead, I strongly recommend to
use ssh.
So if anyone falls in this condition:
Forget DHCP and wifi, open 2 terminals, one to keep running a ping to your
router, another to set a static IP on your ethernet wired interface, bring
it up, an as soon as you get ping answers run this command:
{{{
$ ssh root@YOUR_ROUTER_IP "cat /etc/crontabs/root ; rm /etc/crontabs/root"
>> myrouter_crontab.bk
}}}
It will save the root crontab on your PC and then delete it.
Thank you for your work, I really appreciate it, and I also would like to
thank you team for your time.
Cheers,
Gold Eagle Wifi.
--
Ticket URL: <https://dev.openwrt.org/ticket/22121>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets