On a old decstation 3100 I was deleting last semesters users to try to dig up some disk space, I also deleted some test users at the same time.

One user took longer then usual, so I hit control-c and tried ls. 

"ls: command not found"

Turns out that the test user had / as the home directory and the remove user script in ultrix just happily blew away the whole disk. ftp, telnet, rcp, rsh, etc were all gone. Had to go to tapes, and had one LONG rebuild of X11R5.

Well, we had one system on which you couldn't log in on the console for a while after rebooting, but it'd start working sometimes. What was happening was that the manufacturer had, for some idiot reason, hardcoded the names of the terminals they wanted to support into getty (this manufacturers own terminals, that I can understand, but also a handful of common types like adm3a) so getty could clear the screen properly (I guess hacking that into gettydefs was too obvious or something). If getty couldn't recognise the terminal type on the command line, it'd display a message on the console reading "Unknown terminal type pc100". We ignored this flamage, which was a pity. Cos that was the problem.

It did this *before* opening the terminal, so if it happened to run between the time rc completed and the getty on the console started the console got attached to some random terminal somewhere, so when login attempted to open /dev/tty to prompt for a password it failed.

Moral: always deal with error messages even when you *know* they're bogus.

Moral: never cry wolf.

I heard this from a fellow sysadmin friend.  My friend was forced to work with some sysadmins who didn't have their act together.  One day, one of them was "cleaning" the filesytem and saw a file called "vmunix" in /. "Hmm, this is taking up a lot of space - let's delete it".  "rm /vmunix".

My friend had to reinstall the entire OS on that machine after his coworker did this "cleanup".  Ahh, the hazards of working with sysadmins who really shouldn't be sysadmins in the first place. When this happened to a colleague (when I worked somewhere else) he restored vmunix by copying from another machine.

Unfortunately, a 68000 kernel does not run very well on a Sparc...

At one place where I worked, someone had set up cron to delete any file named "core" more than a few days old, since disk space was always tight and most users wouldn't know what core files were or care about them.  Unfortunately not everyone knew about this and one user lost a plain text file (a project proposal) he'd spent a one lot of time working on because he called it "core". 

Here's one that will show that you shouldn't work on a system that you don't thourghly understand.

At my "previous" employer I was instructed to install a new (larger) disk drive in a RS/6000 system. Since a full backup of the system was done the previous day I just looked at the file systems vi a df to see which were on the drive that I was replacing. After this I did a tape backup of these filesystems, ran smit and did a remove of these filesystems.  I then installed the new disk and brought the system back up.  When I ran smit and when I was able to do the installation of the new drive and setup the file systems I was figuring that this was going to be an easy one.

WRONG!!  I was aware that you could expand filesystems under AIX but was not aware that it would expand them 'across physical drives'!!! I first realized that I was in trouble when I went to read in the backup tape and cpio was not found. I did an ls of the /usr/bin directory and it said that the file was there but when I tried to run it it was not found. and of course when I went looking for the original install tape it was not to be found....