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?

Nick Bolton
  • 5,126
  • 12
  • 54
  • 62
  • 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 '09 at 18:28
  • 1
    `echo "alias rm='rm --preserve-root'" >>/root/.bashrc` – amphetamachine Mar 03 '11 at 06: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 04 '13 at 16:27

4 Answers4

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.

David Pashley
  • 23,497
  • 2
  • 46
  • 73
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/
alexjs
  • 196
  • 1
  • 4
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.

Michael Dillon
  • 1,819
  • 13
  • 16
  • 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 '09 at 19:00
2

Turns out I was missing lib64...

ln -s /lib lib64

...the server now boots! :)

Nick Bolton
  • 5,126
  • 12
  • 54
  • 62