3

I'm running Debian... And, I accidentally ran "rm /*" as root (hurray!) - luckily I didn't use -r, so the dirs are still intact. However, when trying to boot, I get...

run-init: /sbin/init: No such file or directory
Kernel panic - not syncing: Attempted to kill init!

...however, after checking the drive from another machine, I can confirm that /sbin/init exists. The only things missing were the files in the root, and I've replaced the sym links (initrd.img and vmzlinuz)...

Perhaps there's some more links I need to replace?

Improve this question
3
  • I have backup only for my storage drive and config files, but rather than reinstalling I figured it'd be best to try and fix first.
    – Nick Bolton
    Oct 22, 2009 at 18:28
  • 1
    echo "alias rm='rm --preserve-root'" >>/root/.bashrc
    – amphetamachine
    Mar 3, 2011 at 6:35
  • 1
    @amphetamachine "Be careful what you type as root" is probably better advice -- you'll find if you are on pretty much anything that isn't Linux with the GNU rm that option doesn't exist (and you'll find yourself in serious trouble when you work on a Linux machine that doesn't have that safety net set up...)
    – voretaq7
    Mar 4, 2013 at 16:27

4 Answers 4

Reset to default
5

Did you really run 

# rm /

or 

# rm /*

Because if you ran the former, you shouldn't have deleted any files, because rm won't delete a directory unless you add -r.

I would suggest running:

# update-initramfs -c -k all
# update-grub

but I don't think this will fix your problem. You probably also want to check your /boot/grub/menu.lst to make sure it is referring to the right kernel and initramfs images.

Improve this answer
3
  • Updated answer, it was actually FOOBAR=/path/to/foobar; rm $FOOBA/* (notice the typo).
    – Nick Bolton
    Oct 22, 2009 at 18:27
  • 6
    Ah, that would explain it. Always run scripts with "set -u" as this will prevent this problem.
    – David Pashley
    Oct 22, 2009 at 18:31
  • Aha, excellent advice.
    – Nick Bolton
    Oct 22, 2009 at 18:35
2

I once wanted to type in rm folder/* but accidentally typed rm folder /* on a running system, either SCO Xenix or SCO UNIX. Since UNIX does not actually delete files which are open, until they are closed, the system continued functioning normally.

I knew that if I put all the missing files back, that a reboot would succeed normally, and nothing bad would happen. Fortunately I had another server with the same OS installed, and I went over to it, copied all the files from the filesystem root onto a floppy, and put them back on the castrated system. Later, that evening after everyone had logged off, I rebooted and there was never a problem.

So you should be able to do similar to fix this. If you don't have a matching running system, but you have a workstation with Virtualbox or XEN, then you could just do a VM install in order to get the matching system.

Of course, I don't suggest using floppy in this day and age when we have SCP and FTP to move files around.

Improve this answer
1
  • Yeah I'll give that a try, thanks. I was hoping Ubuntu would share the same root files, but apparently it doesn't (damn!).
    – Nick Bolton
    Oct 22, 2009 at 19:00
2

Turns out I was missing lib64...

ln -s /lib lib64

...the server now boots! :)

Improve this answer
5
  • 2
    Now that it's running again you may want to reconsider your backup strategy.
    – John Gardeniers
    Oct 22, 2009 at 21:49
  • Yeah absolutely... Hmm what is the best way to back up a system? I tried rsync once but there's a ton of errors because it tries to backup /dev and things like that.
    – Nick Bolton
    Oct 25, 2009 at 20:58
  • --exclude for the win.
    – David Rickman
    Nov 9, 2009 at 14:23
  • 2
    --exclude /media --exclude /dev --exclude /sys --exclude /proc
    – Nick Bolton
    Nov 9, 2009 at 15:31
  • @nbolton I suggest you peruse the backup tag for some ideas on backup strategies & software options.
    – voretaq7
    Mar 4, 2013 at 16:28
2

At the risk of necroing, I came to this answer while trying to resolve the same. It's worth noting that if you try to recover from this while the system's still running, you may not be able to execute 'ln' because you'll be missing a lib - you'll need to do something like:

/lib/ld-2.11.1.so /bin/ln -s /lib/ /lib64/
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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