#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

Reply via email to