Does rm -rf / traverse /mnt/*

[eivinn]

Hi,

I'm thinking I might have tried to remove a directory with the command

Code: Select all

rm -rf dir_name /

The current working directory was a tmp dir on my backup drive which was at the time mounted as rw on /mnt/backup.
As the server is not responding I'm thinking I might have done the above error. Will the command have deleted all the files under /mnt/backup as well? Then I'm fucked

EDIT: Obviously I was root at the time...

[cptmorgan]

you deleted whatever you typed after rm -rf... it means remove files recursively and force. so you deleted whatever "dir_name" was and im sure you started deleting files from your system root "/" if you didnt kill the process.

good luck :/

[eivinn]

good luck :/

I'm still hoping that something else is to blame and that all the data is still there

Luckily I've got some older backups on CD as well, but a whole lot of "unimportant" e-mail is probably gone. At least nothing we can't afford to loose was there (or so I like to tell myself).

[DNAspark99]

ouch!

[eivinn]

Well, I am quite happy now. My data is still there and .bash_history does not contain any strange input for root.
This brings me to the question why this happened. This is the second time the server is doing this. I have not touched it since a fresh install, and last day the e-mail server stopped serving requests.

Error from fsck:

Code: Select all

livecd mnt # fsck /dev/hda3
fsck 1.37 (21-Mar-2005)
e2fsck 1.37 (21-Mar-2005)
/dev/hda3 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes

Inode 201892 was part of the orphaned inode list.  FIXED.
Inode 201893 was part of the orphaned inode list.  FIXED.
Inode 330835 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Inode bitmap differences:  -201889 -(201892--201893) -330835
Fix<y>? yes

Free inodes count wrong for group #12 (8387, counted=8390).
Fix<y>? yes

Free inodes count wrong for group #20 (10168, counted=10169).
Fix<y>? yes

Free inodes count wrong (914651, counted=914655).
Fix<y>? yes


/dev/hda3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda3: 239521/1154176 files (1.4% non-contiguous), 1293887/2307060 blocks

As I have been told there was a power outage over a week ago, and suddenly it stopped functioning yesterday.

Although it now works after a fsck and a reboot I'm worried. What is happening?

The only extra info I've got is that the server is now complaining about an outdated libclamav engine on boot.