2

I have a Raspberry Pi which runs a Python script on boot. They initiate and stroke the hardware watchdog at /dev/watchdog. I recently tried cloning the SD card onto two other SD cards. However on those cloned cards, the device gets caught in a reboot cycle, triggering a reboot about 10 seconds after booting up.

Why would this issue pop up with a new SD card? I can access the files on the SD card through my linux system, so I could make changes there. However I don't have enough time to run console commands because it reboots before I can log in.

What should I do to disable the hardware watchdog? Or to fix whatever issue popped up?

UPDATE: So I tried carefully truncating the image and then dd'ing it to a new card but still reset. Then I tried the original (working) SD card and the original (working) power adapter on a new board, and it still reset. Then I tried it on a third RPI, and it still reset. So, it seems that just the act of changing the RPI causes the watchdog to trigger resets. Getting very low on theories. I then removed the watchdog driver from /etc/modules and it still reset. Also disabled the watchdog daemon in /etc/default/watchdog.

Here's some info from /var/log/syslog:

Oct 31 14:17:39 devbox1 shutdown[2510]: shutting down for system reboot
Oct 31 14:17:40 devbox1 init: Switching to runlevel: 6
Oct 31 14:17:43 devbox1 bluetoothd[2147]: Terminating
Oct 31 14:17:43 devbox1 bluetoothd[2147]: Stopping SDP server
Oct 31 14:17:43 devbox1 bluetoothd[2147]: Exit
Oct 31 14:31:45 devbox1 ifplugd(eth0)[1619]: Exiting.
Oct 31 14:31:46 devbox1 ifplugd(wlan0)[1614]: Exiting.
Oct 31 14:31:48 devbox1 avahi-daemon[2132]: Got SIGTERM, quitting.
Improve this question

2 Answers 2

Reset to default
1

most probably you've copied SD cards wrong way or the copy SD size was smaller than original. anyway, watchdog is the visible problem, but there are definitely others you don't see yet. get a new set of SD cards and/or try to copy again.

Improve this answer
2
  • I tried carefully truncating the image and resizing it in gparted, and it still reset. I then even (per update above) tried the original SD card on the new Pi, and it still reset.
    – Anthony Scodary
    Commented Oct 31, 2013 at 20:33
  • could you please try new fresh image downloaded from the raspi web site?
    – lenik
    Commented Nov 1, 2013 at 1:44
1

It seems like the watchdog is not receiving heartbeats "stroke" from the python scripts. For some reason they are not starting up with the Pi or there is another permission issue.

Since you do not have enough to log in and disable the watchdog you will need to try and start in safe mode. This only works on the latest firmware

enter image description here

Mount the SD card. If /mnt doesn't exist then "mkdir /mnt" first.

# mount /dev/mmcblk0p2 /mnt

If you cannot get to safe mode using that method then you can mount the SD card in another Linux OS and remove the line bcm2708_wdog from /etc/modules

You can also disable the watchdog on the image that works, then clone it again to the other cards and try to re-enable it later.

Improve this answer
7
  • 1
    nice pic, but you've lost your capacitor next to the power connector =)
    – lenik
    Commented Oct 31, 2013 at 9:27
  • It is not my board actually. But I noticed there is a wierd tweak with the red wire going into TP1- I bet they had power issues ;) I just wanted to demonstrate the JUMPER method instead of using bare wire to short the pins
    – Piotr Kula
    Commented Oct 31, 2013 at 9:35
  • I had tried modifying /etc/watchdog.conf and watchdog + wd_keepalive in /etc/init.d, but I don't know where the driver/module for the broadcom hardware watchdog itself is. Will try removing from /etc/modules.
    – Anthony Scodary
    Commented Oct 31, 2013 at 20:39
  • 1
    Okay, so I commented out bcm2708_wdog from /etc/modules, and it still reset. I have no idea what is triggering the reset without that driver active.
    – Anthony Scodary
    Commented Oct 31, 2013 at 20:50
  • That is peculiar. All I can suggest is disable it all on the master image and clone it again for test. See if it still does it.. Maybe there is another issue. You can try and scan the logs and see if there is a kernel panic or something
    – Piotr Kula
    Commented Oct 31, 2013 at 22:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.