2

So we had a couple of Arch guys hack a Debian install up for an embedded system (that is no longer so embedded) and they disabled Sysvinit in favour of using multiple linked /etc/rc.* files. Unfortunately I can't do a fresh install at this point in time which would be much preferred but I am guessing it would less effort to re-enable Sysvinit.

I can see that Sysvinit is still installed, but I can't find the method by which booting would be handed off to it. /boot/grub/grub.cfg offers no clues. There is a /boot/kexec.sh file with the following in it:

kexec vmlinuz --command-line="root=/dev/sda5 \
init=/sbin/init \
console=ttyS0,38400n8f elevator=deadline" -f

With a commented out line:

# kexec vmlinuz --command-line="root=/dev/sda5 \
# loglevel=0 console=ttyS0,38400n8 init=/etc/rc.start irqpoll" -f

But I'm not even sure if kexec.sh gets loaded or not...

So how can I get Sysvinit running again so it boots using the rc[0-6].d folders?

Thanks in advance.

EDIT inittab looks like this: https://gist.github.com/hamstar/6161321

hamstar
  • 529
  • 8
  • 11

1 Answers1

1

What is in your /etc/inittab?

Since your init= value is point at init, that is the program that is first ran when the system boots. The traditional init, uses the /etc/inittab to configure what happens next. Your inittab will look something like this on a stock Debian setup.

# The default runlevel.
id:2:initdefault:
# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS
# /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.
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2

The output of /proc/cmdline would also confirm what boot parameters are being passed to the kernel.

Zoredache
  • 20,438