I messed up the boot on a raspberry pi that is meant to run an important project.

It started when I was trying to get a script to run at boot. I tried creating a daemon and I successfully started and stopped the script using:

/etc/init.d/daemon_name start and /etc/init.d/daemon_name stop

the problem with this was when I added this to /etc/init.d and the actual script to/usr/local/bin

This is the content of the init.d script (I did it according to a tutorial, so I'm not expecting the problem to come from here):

#! /bin/sh
# Provides:          main
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: RPi Heating Controller
# Description:       This file is used to run the heating controller script
#                    at boot time.

# Author: 

# Change the next 3 lines to suit where you install your script and what you want to call it

# Add any command line options for your daemon here

# This next line determines what user the script runs as.
# Root generally not recommended but necessary if you are using the Raspberry Pi GPIO from Python.

# The process ID of the script when it runs is stored here:

. /lib/lsb/init-functions

do_start () {
    log_daemon_msg "Starting system $DAEMON_NAME daemon"
    start-stop-daemon --start --background --pidfile $PIDFILE --make-pidfile --user $DAEMON_USER --chuid $DAEMON_USER --startas $DAEMON -- $DAEMON_OPTS
    log_end_msg $?
do_stop () {
    log_daemon_msg "Stopping system $DAEMON_NAME daemon"
    start-stop-daemon --stop --pidfile $PIDFILE --retry 10
    log_end_msg $?

case "$1" in



        status_of_proc "$DAEMON_NAME" "$DAEMON" && exit 0 || exit $?
        echo "Usage: /etc/init.d/$DAEMON_NAME {start|stop|restart|status}"
        exit 1

exit 0

After this I updated the rc.d defaults with : update-rc.d defaults

I can't be sure, but I think after this it didn't boot...

I also tried at some point using a cronjob @reboot python script-name and I'm pretty sure I forgot the & at the end to run on a different thread. I tried editing the cron from the SD card though and nothing changed...

How can I disable these boot scripts directly from the SD Card so i can boot the Pi again and fix this?

I've been going through the logs, but I'm not sure what to look for...

I'm running Raspbian. Anything else that I can get from the SD card and can help you, just ask and I'll post it here.


After posting this question I realised that ike goldilocks said, update-rc-d creates simlinks in the runlevel directories, which I proceded to remove all that refered to my script.

Like I said in a comment to his answer, I once used the following script in rc.local to update the ssh (I'm posting the whole rc.local to prevent people from saying it misses the exit 0):

#!/bin/sh -e
# rc.local
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
# In order to enable or disable this script just change the execution
# bits.
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP" // (I edited this as a test, it now reads: echo "My IP address is %s\n" "$_IP" > /etc/IPFLAG)

if [ -e /etc/SSHFLAG ]; then
  /usr/sbin/update-rc.d -f ssh defaults
  /bin/rm /etc/SSHFLAG
  /sbin/shutdown -r now

exit 0

It currently boots to a point where I can ping it from my computer, but I can't ssh to it...

After the edits i can say:

rc.local is not even running (the SSHFLAG was not deleted and IPFLAG was not created. I can still ping to the pi though...)

The pi shows activity on the SD Card and the ethernet port

Like mazianni asked, the content of my inittab (confirms default runlevel is 2):

# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

# The default runlevel.

# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.

# What to do in single-user mode.

# /etc/init.d executes the S and K scripts upon change
# of runlevel.
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.

# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

# Action on special keypress (ALT-UpArrow).
#kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work."

# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop

# /sbin/getty invocations for the runlevels.
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
# Format:
#  <id>:<runlevels>:<action>:<process>
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
1:2345:respawn:/sbin/getty --noclear 38400 tty1 
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

# Example how to put a getty on a serial line (for a terminal)
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

# Example how to put a getty on a modem line.
#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3

#Spawn a getty on Raspberry Pi serial line
T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

Now the content of the rc2.d directory:

$ ls -l
total 4
lrwxrwxrwx 1 root root  17 Sep  8  2014 K01lightdm -> ../init.d/lightdm
lrwxrwxrwx 1 root root  20 Sep 17  2014 K06nfs-common -> ../init.d/nfs-common
lrwxrwxrwx 1 root root  17 Sep 17  2014 K06rpcbind -> ../init.d/rpcbind
-rw-r--r-- 1 root root 677 Jul 14  2013 README
lrwxrwxrwx 1 root root  24 Oct 16 21:24 S01binfmt-support -> ../init.d/binfmt-support
lrwxrwxrwx 1 root root  18 Sep  8  2014 S01bootlogs -> ../init.d/bootlogs
lrwxrwxrwx 1 root root  20 Sep  8  2014 S01cgroup-bin -> ../init.d/cgroup-bin
lrwxrwxrwx 1 root root  17 Sep  8  2014 S01ifplugd -> ../init.d/ifplugd
lrwxrwxrwx 1 root root  14 Sep  8  2014 S01motd -> ../init.d/motd
lrwxrwxrwx 1 root root  18 Sep 19  2014 S01php5-fpm -> ../init.d/php5-fpm
lrwxrwxrwx 1 root root  17 Sep  8  2014 S01rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root  14 Mar 26 17:18 S01sudo -> ../init.d/sudo
lrwxrwxrwx 1 root root  22 Sep  8  2014 S01triggerhappy -> ../init.d/triggerhappy
lrwxrwxrwx 1 root root  17 Sep 24  2014 S02apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root  14 Sep 24  2014 S03cron -> ../init.d/cron
lrwxrwxrwx 1 root root  14 Sep 24  2014 S03dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root  24 Sep 24  2014 S03dphys-swapfile -> ../init.d/dphys-swapfile
lrwxrwxrwx 1 root root  14 Oct 16 21:24 S03lirc -> ../init.d/lirc
lrwxrwxrwx 1 root root  15 Sep 24  2014 S03mysql -> ../init.d/mysql
lrwxrwxrwx 1 root root  13 Sep 24  2014 S03ntp -> ../init.d/ntp
lrwxrwxrwx 1 root root  20 Sep 24  2014 S03postgresql -> ../init.d/postgresql
lrwxrwxrwx 1 root root  15 Sep 24  2014 S03rsync -> ../init.d/rsync
lrwxrwxrwx 1 root root  13 Sep 24  2014 S03ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root  22 Oct 16 21:24 S04avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root  17 Sep 24  2014 S04postfix -> ../init.d/postfix
lrwxrwxrwx 1 root root  18 Sep 24  2014 S05plymouth -> ../init.d/plymouth
lrwxrwxrwx 1 root root  18 Sep 24  2014 S05rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root  19 Sep 24  2014 S05rmnologin -> ../init.d/rmnologin

As you can see, they are all symlinks but the README file.

So, I just got access to an HDMI TV that I used as a monitor for the pi, for the lack of a better medium, here are some screenshots and what I think might be happening:

First stop

The first stop is a locale related issue. I have had locale issues before, but they didn't keep me from booting. I find it strange thought the message: cannot open locale archive "/usr/lib/locale/locale-archive": Read-only file system It says then that it cannot remove the same file

Second Stop

This image shows some problems with the filesystem... i believe the SD might become corrupted anytime soon... It took a pounding already, so no surprise there... Then, there's the configuring network interfaces, again, problems related to the locales... I don't know what to think of this. Also, there is an error referring to init.d

Last Stop

It finally cleans up temps, Sets up ALSA, and then it hangs... I don't know what was supposed to happen after this as i had never witnessed a pi boot screen.

  • thank you, it was improved after some requests :) Still, no right answers :/ Do you have any idea of what could be happening? Apr 7, 2015 at 8:59
  • I would suspect a corrupted SD Card at this point, the log messages indicate that the system cannot find "sudo", which isn't normally expected. Can you also post the contents of /usr/local/bin/heating/main (which I believe is the actual daemon you tried to run). I believe that this may have some functionality in it that deleted some core files from your filesystem.
    – Doug Edey
    Apr 11, 2015 at 2:34
  • @DougEdey that is my heating control system main script, it does nothing but calling other scripts and writing/reading to and from a database. It has access to the GPIO and logs to a text file, that's it, no access to files or directories not related to the control of the heating. Apr 13, 2015 at 16:10
  • Could you provide it so we have the complete picture of what had changed please?
    – Doug Edey
    Apr 13, 2015 at 23:52

2 Answers 2


As goldilocks noted, you can determine your run level from /etc/inittab.

Assuming it's run level 2, and assuming nothing was changed in /etc/rc2.d, S03ssh gets called before S05rc.local. Presumably something is going wrong well before rc.local is called.

Can you share the contents of /etc/rc2.d (again, assuming that's your default run level)? I'd expect them to look something like this:

K01lightdm     S01cgroup-bin  S01triggerhappy  S03dphys-swapfile  S05rc.local
K05nfs-common  S01ifplugd     S02apache2       S03ntp             S05rmnologin
K05rpcbind     S01motd        S03arpwatch      S03rsync
README         S01rsyslog     S03cron          S03ssh
S01bootlogs    S01sudo        S03dbus          S05plymouth

With the exception of the README, they should all be symlinks.

  • I edited the question accordingly. Upon listing the files in the rc2.d directory, I noticed there's a symlink for postgresql, and I think I removed it last time I could log to the pi, could that be it? It is possible that I used apt-get remove but didn't purge... How should I proceed with this? just remove the symlink? Mar 31, 2015 at 13:12
  • Yeah -- again, that's all there is to it. There are no other records or anything that would create an inconsistency.
    – goldilocks
    Mar 31, 2015 at 13:25
  • 1
    Having a broken symlink in that directory shouldn't prevent the other startup scripts from running. You're getting an IP, so it seems like it's getting as far as S01ifplugd. It sounds like something is preventing the ssh and rc.local scripts from running though. Unless dbus is blowing up for some reason, I'm not sure what that something would be. Your best bet is probably going to be to get a monitor on there and watch the boot.
    – mazianni
    Mar 31, 2015 at 13:40
  • i'm going to connect a monitor, or try to if i can find an hdmi cable :p i'm not ready for connecting a monitor, i've always run the pi headless. I will post the results, but because as I said in the original post, I've been messing with daemons, it might be dbus... Mar 31, 2015 at 14:04
  • Comparing your screen cap to my boot screen, I don't see yours going to runlevel 2. There should've been a message "INIT: Entering runlevel: 2" a few lines past where yours hangs. Yours is stuck somewhere in /etc/rcS.d
    – mazianni
    Apr 2, 2015 at 12:19

How can I disable these boot scripts directly from the SD Card so i can boot the Pi again

What update-rc.d does is create a set of symlinks from /etc/init.d to the runlevel directories, /etc/rcN.d, where N is is from 0-6, or S. These will correspond to what's listed here:

# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6

The start links will look like S50daemon_name, the stop links K50daemon_name, although '50' could be any number between 0 and 99. This determines the order in which scripts are run.

So, to disable stuff by editing the card, you just need to delete the symlinks in the runlevel directories. If you are lazy you can probably just delete the one in /etc/rc2.d, presuming your default runlevel is 2. You can find that at the top of /etc/inittab:


But you might as well erase all of them. My advice to you is that from the looks of things you don't need this, although I am a bit prejudiced: I cannot stand Debian's twist on SysV init and I am very glad they are abandoning it for systemd.

If you just want this to start at boot, edit /etc/rc.local and add your commands there. Make sure your daemon actually forks to the background. You do not need to use sudo as this script is run root after everything in the default runlevel directory.

  • after posting this question I realised that simlinks thing and i deleted all of them. the pi still doesnt boot... I wonder what could be if not that init.d script... I also checked rc.local there's nothing in it... what do you think could be wrong? it boots to a point when i can ping it from my computer, but i can't ssh to it... Because i never connected a monitor to it (always used it headless) i have used an ssh configuration script on rc.local to reset the ssh configurations. I will now make it so that script runs again (it makes use of a file as a flag. I'll post the script as an edit) Mar 31, 2015 at 11:13
  • because cron runs before ssh, i'm adding a cronjob to write to a file to see if it is run or if the problem is before the cron Mar 31, 2015 at 14:02

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.