This is now the default behaviour of 'rm' on Intrepid (and, it seems, on Hardy, since both package coreutils 6.10):
(I have to say that I ran this test, huh, worried, even if I was setting '-i' ;-)
hggdh@xango2:/usr/src/buildd/coreutils-6.10/coreutils-6.10 $ lsb_release -r
hggdh@xango2:/usr/src/buildd/coreutils-6.10/coreutils-6.10 $ rm -ri /
rm: cannot remove root directory `/'
Also, the following notice in the info pages is relevant here:
"2.9 Treating / specially
Certain commands can operate destructively on entire hierarchies. For
example, if a user with appropriate privileges mistakenly runs `rm -rf
/ tmp/junk', that may remove all files on the entire system. Since
there are so few legitimate uses for such a command, GNU `rm' normally
declines to operate on any directory that resolves to `/'. If you
really want to try to remove all the files on your system, you can use
the `--no-preserve-root' option, but the default behavior, specified by
the `--preserve-option', is safer for most purposes.
The commands `chgrp', `chmod' and `chown' can also operate
destructively on entire hierarchies, so they too support these options.
Although, unlike `rm', they don't actually unlink files, these commands
are arguably more dangerous when operating recursively on `/', since
they often work much more quickly, and hence damage more files before
an alert user can interrupt them. Tradition and POSIX require these
commands to operate recursively on `/', so they default to
`--no-preserve-root', but using the `--preserve-root' option makes them
safer for most purposes. For convenience you can specify
`--preserve-root' in an alias or in a shell function.
Note that the `--preserve-root' option also ensures that `chgrp' and
`chown' do not modify `/' even when dereferencing a symlink pointing to
As such, I am closing this bug as "Fix Released". Please feel free to reopen if you do not agree.