i've seen rm -rf / in many people's sigs and have laughed every time, but now that i think about it, would it be possible to carry out the task or what would it look like?

while issuing that command, some sys files will be deleted, so would linux just suddenly turn off or would certain files not be allowed to be removed?

i only wonder this because the process could never complete (or so i think) since the rm program would eventually have to try to delete itself and that would not work....

*one of these days i will try....

Don't do it. It would start at the top (root or /) and delete everything - including the root directory.

Only do it if you don't mind losing the whole system and your files.

Well... I think it gets deleted from the HDD , not from the memory. So after doing that you wouldn't get any effect until you try to open a file which would give you a File Not Found error or something. When you reboot, though... you'd have no OS

It would complete the execution as I'm sure your familiar with this new technology called Random Access Memory right?

It'll crash in the middle of /proc or /dev probably, as soon as the kernel needs to access something that doesn't exist anymore that's big enough to make it panic... my guess would be somewhere in /dev so in effect you would be left with everything alphabetically after /dev, /etc... /usr, so only half the filesystem.... almost makes me curious enough to set up a crate strictly so I can try!

Cheers,

Finegan

see, a very thought provoking topic indeed....

if finegan is right, then all i'll lose is /bin and that's not bad

as for that random access memory thing... what in the world is that and where can i get it? anything with the word "random" is good!

but anyway, ya, if only i hadn't been in such a rush to format my old redhat and slack partitions on my test harddrives, i could have run a very interesting experiments...

oh dear... i feel the urge.... terminal opened....

**is there a way to restrict anyone from ever issuing rm -rf / ?

I did it about 2 months ago when I was going to rebuild my box. So insteald o powering it off, I did rm -rf in the / directory .

It got through everyting, errored on some things it couldn't delete. And at boot, it tried to boot....probably from whatever was left in the MBR....but it crapped out after posting about 12 lines of crap text.

Do it. It's fun. Plus you get to learn more from having to rebuild your box.

For people that don't know what this does: It deletes the contents of your / partiton. Don't do it unless you want to rebuild your box



Peace,
Whitehat

Alias it from /etc/profile to echo "Don't be a jackass". They could unalias it of course, but it would take a while for them to figure out.

I can't think of a way to make it not a possibility without hacking an if loop into the source for rm, but that would be bad in the long run.

Clocked

cool idea ^^
I'm gonna try it ^^
hrhrhrhrhhrhrhrr
ohhhh...wait a moment...
I'm still scared because of a very unpleasant mistake..
yes....and I did it in my home dir ^^
hope you have a lought...
such a innocent whitespace =]
=P

Another friendly reminder to newbies:

If you're tempted to try this and you dual-boot, make sure that you unmount your other partition first, or you might wipe out your /dev/hda1 (or similar) and end up reloading both OSs!

That said, I've never done it, which seems strange, because I think I've done or seen every other way to wipe out (and rebuild) both Linux and Windows...

Looks like a good project for a lazy (cold!) sunday afternoon. My question is whether every Distro does the same thing, or if some have "idiot-proofed" this, and how far it actually gets. While your system may not reboot, that may not mean you lost everything. On the other hand, rebuilding /dev by hand isn't exactly a walk in the park, either. (I'd rather chew my own arm off than repeat the mistake I made when trying to switch to devfs without following ALL the instructions. )

Also, I'm not sure it would have much effect if a normal user did it, as they'd likely only wipe out their own /home/<name>. They'd just get permission errors from everything they didn't have rw access to (including or not including those dual boot partitions).

Finally, does FreeBSD do the same thing?

I did it on a redhat box, a while ago, I was going to do a fresh re-install, so I thought I would try it to see what happend. I got a bunch error messages saying that some file could not be deleted. It did take out quit a bit, but it did not remove everything like I thought it would. I did not try to reboot. The next time I do a fresh re-install, I will have to try it.

On the topic of killing your machine in an interesting way. I trashed my VectorLinux machine yesterday because I can never remember if the link name or the target name are first in 'ln'. A couple of
~> ln -sf ...
in my /boot directory later and I had no kernel. Whoops!

It's days like these that you appreciate tomsrtbt.
http://www.toms.net/rb/

Martin

I could *never* remember it either (used to fire up mc just to do it to be safe) until I finally hit my mnemonic. 'File first, link last.'

Alright,

I have/had this dual-boot slack 9, slack 9.1 machine. /boot was a seperate partition on /dev/hda1 shared as /boot on both. The root filesytem on 9.1 is a raid0 array of /dev/hda2 and /dev/hdc2, swap all lives on /dev/sda2, and the root filsystem of 9.0 was /dev/sda1.

So... I booted 9.1, copied over anything interesting from /dev/sda1, then booted 9.0 and unmounted /boot so that would survive (we all know that'll get wiped out easily).

then I issued "rm -rf /*"

I took about 10 minutes to obliterate 3.3Gb.

It complained about not being able to delete some /dev entries and later some /proc entries. I could still switch ttys, but of course not login... since /bin/login was gone and of course maybe /etc/shadow had eaten it by then. It completed, didn't crash, but of course I couldn't execute ls or dmesg, they were gone, but the machine was up, and I could ping it remotely.

Rebooted it with the stinky finger, went to the slack 9.1 partition and mounted /dev/sda1 on /mnt/hd. Here's some ls'in:
There we go then, question answered.


Cheers,

Finegan

In retrospect I should have done more then just ping it and actually hammered at some of the daemons in ram. I wonder what an nmap would have done to it... especially since its log files were gone... and it wouldn't have anywhere to log all that to.

Eh, whatever, that's the kind of thing that takes a lot of prep to find out about, or in my case, the coincence of having a bootable partition that was about to get mkfs -f -t xfs anyway.

Cheers,

Finegan