Sysadmin Stories: Dealing with dev files

by Stephen on October 19, 2009 · 0 comments

in Sysadmin Stories

1

From: nickp@BNR.CA (“Nick Pitfield”, N.T.)

One of my colleagues had been itching to get into sys admin for some time,
so last week he was finally sent on a 5-day sys admin course run by HP in
Bracknell.

On the following Sunday, he decided to try out his new-found knowledge by
trying to connect and configure a DAT drive on one of our critical test
systems. He connected the cables up okay, and then created the device file
using ‘mknod’.

Unfortunately, he gave the device file the same minor & major device numbers
as the root disk; so as soon as he tried to write to this newly installed
‘DAT drive’, the machine went tits up with a corrupt root disk….ho hum.

2

From: philip@haas.berkeley.edu (Philip Enteles)
Organization: Haas School of Business, Berkeley

As a new system administrator of a Unix machine with limited space I
thought I was doing myself a favor by keeping things neat and clean. One
day as I was ‘cleaning up’ I removed a file called ‘bzero’. Strange
things started to happen like vi didn’t work then the complaints started
coming in. Mail didn’t work. The compilers didn’t work. About this time
the REAL system administrator poked his head in and asked what I had
done. Further examination showed that bzero is the zeroed memory without
which the OS had no operating space so anything using temporary memory
was non-functional. The repair? Well things are tough to do when most of
the utilities don’t work. Eventually the REAL system administrator took
the system to single user and rebuilt the system including full
restores from a tape system. The Moral is don’t be to anal about things
you don’t understand. Take the time learn what those strange files are before
removing them and screwing yourself.

3

From: broberts@waggen.twuug.com (Bill Roberts)
Organization: Brite Systems

My most interesting in the reguard was when I deleted “/dev/null”. Of
course it was soon recreated as a “regular file”, then permission problems
started to show up.

I was new at the game at the time and couldn’t figure out what happened!
It look good to me. I didn’t know about “special files” and “mknod” and
major and minor device codes. A friend finally helped out and started
laughing and put me on the right track. That one episode taught me a
lot about my system.

4

From: Frank T Lofaro
Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Well one time I was installing a minimal base system of Linux on a
friends PC, so that we would have all the necessary utlitities to bring
over the rest of the stuff. His 3 1/2 inch disk was dead, so when had to
get the 5 1/4 inch version of the boot/root disk. Too bad that version,
having to fit in 1.2M instead of 1.44, didn’t have tar. We could get a
version of tar, but it was in a tar file (nice chicken and egg
scenario). I said, okay, since we don’t have tar, we can’t use that to
copy the files from floppy to the hard disk, I’ll use cp instead (bad
move). It actually seemed to work for a while, then the machine
rebooted! I did it again, the same thing happened. Then I realize cp
wouldn’t work on device files! (this is what happens when you try to
install un*x at 3 AM). It just read the contents of the device and made
a file containing such, which is undesireable in any event. (when it
read /dev/port, the device file that references I/O ports, it must’ve
did something to reboot the machine, that was the file that was causing
the reboots).

I finally got it working by having him get the tar archive of the
linux binaries (including the tar we needed), and untarring it on one of
the public decstations here, so we could ftp tar to his PC using his dos
tcp/ip stuff. A funny aside was that it untarred into ~/bin, and
superseded all his normal commands. We were wondering why everything
wouldn’t run. Luckily it wasn’t too hard to fix after we realized what
happened.

5

From: hirai@cc.swarthmore.edu (Eiji Hirai)
Organization: Information Services, Swarthmore College, Swarthmore, PA, USA

A consultant we had hired (and not a very good one) was installing Unix
on one our workstations. He was mucking with creating and deleting
/dev/tty* files and made /dev/tty a regular file. Weird things started to
happen. Commands would only print their output if you pressed return twice,
etc. Fortunately, we solved the problem by re-mknod-ing /dev/tty. However,
it took a while to realize what was causing this problem.

6

From: lingnau@math.uni-frankfurt.de (Anselm Lingnau)
Organization: University of Frankfurt/Main, Dept. of Mathematics

broberts@waggen.twuug.com (Bill Roberts) writes:
[story about deleting /dev/null deleted. -ed.]

Years ago when I was working in the Graphics Workshop at Edinburgh University,
we used to have a small UNIX machine for testing. The machine wasn’t used too
much, so nobody bothered to set up user accounts, and so everybody was running
as root all the time. Now one of the chaps who used to come in was fond of
reading fortunes (/usr/games/fortune having been removed from the University’s
real machines along with all the other games). Guess what happened when the
machine said

# fortune
fortune: write error on /dev/null — please empty the bit bucket

Quite a lot of stuff wouldn’t work after the chap was done with the machine
for the day. You bet we put up proper accounts after that!

{ 0 comments… add one now }

Leave a Comment

Previous post:

Next post: