2

A regular filesystem check on a Debian Lenny system triggered an fsck, and that nuked a handful of links in the /etc/rc?.d hierarchy (unfortunately I didn't keep a list).

The system seems to boot and run normally, but I'm worried its storing up trouble for the future.

Is there an easy (fairly automatic) way of rebuilding this piece of the system ? As I understand it, the links are generally manipulated by package postinst scripts using update-rc.d (and I haven't made any changes from the installed defaults).

Without any better ideas, my plan is one of:

  • Diff a listing with another similar system to identify which packages need their links repairing.
  • Wait until the system is upgraded to Squeeze (hopefully not too long :^) and assume the mass package upgrade will restore all the missing links.
timday
  • 856
  • 1
  • 10
  • 24
  • Restore from backup. – John Gardeniers Apr 18 '10 at 11:10
  • Yup, that'll teach me. All the data on the machine is regularly backed up, but the system and its config isn't, I think the original justification being that the system is so unmodified from a standard debian install that reinstalling packages or the system would be the easiest way to fix any damage. Unfortunately the rc?.d area turns out to be a bit more complicated so I think it's time to reconsider this policy... – timday Apr 18 '10 at 22:00

1 Answers1

2

If you do not have backups, you could try installing rcconf and see if it will re-create the links. But in reality all Debian init files would have following information at the top of each script:

### BEGIN INIT INFO
# Provides:          inetd
# Required-Start:    $local_fs $remote_fs
# Required-Stop:     $local_fs $remote_fs
# Should-Start:      $syslog
# Should-Stop:       $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start or stop the xinetd daemon.
### END INIT INFO

Based on this information alone you could partially restore everything with some basic shell scripting.

# Default-Start: 2 3 4 5 tells you that the Start symlinks to this init script should go into /etc/init{2,3,4,5}.d/S<XX>blah.

# Default-Stop: 0 1 6 means that Kill links do into/etc/init{0,1,6}.d/K<XX>blah.

The problem here is the <XX> part. This is the order your processes start and stop, so if you do not know the order, you could potentially end up with a hung boot. For example when you are trying to start NFS before the Networking.

solefald
  • 2,303
  • 15
  • 14
  • Thanks for the rcconf tip. Used it to update all links; it got confused by the damaged ones and mapped them to K00 at all runlevels. Removing those and trying again, it creates the correct links. There was also some damage in rc.S (which rcconf doesn't seem to touch), but simply reinstalling initscripts fixed all those. – timday Apr 18 '10 at 21:41