Path: utzoo!utgpu!watmath!iuvax!mailrus!husc6!rice!sun-spots-request
From: thomas@shire.cs.psu.edu (Angela Marie Thomas)
Newsgroups: comp.sys.sun
Subject: Late night system administration == trouble on SunOS 4.x
Keywords: SunOS
Message-ID: <1845@brazos.Rice.edu>
Date: 30 Sep 89 05:33:31 GMT
Organization: Sun-Spots
Lines: 26
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 8, Issue 148, message 5 of 10

It's another late night of system administration.  Tonight the task is
time consuming, but relatively simple:  Repartition the disks on a
Sun4/280 running 4.0.3 to distribute the load to a new disk.  No big deal.

I partitioned the new disk and dump|restore'd most of the stuff from the
old disk onto it and rebooted off of the new disk.  I then proceeded to
repartition and newfs the old disk.  No problems so far.

I was about to dump|restore /usr from the new disk back to the old disk
(yes, / and /usr are on two different disks) so I mounted xy0g onto /mnt.
At least, that's what I *intended* to do.  My fingers typed "mount
/dev/xy0a /usr" instead.  OOPS!  Well, no real harm done.  I'll just pop
over to /sbin and umount the device.  WRONG!  It seems that /sbin has
enough programs in it to get you into trouble, but not enough to get you
out of it.  No dump, no restore, no umount.  I couldn't even
sync;sync;halt the system.  Oh, mount is there.  I could mount more newly
newfs'd filesystems onto /usr until my face turned blue.  I can't believe
it.  It was as if I had just stumbled into a cul-de-sac.  The only damage
done was to me, not the machine.  Sigh.

Sun, if you're listening, please, please, please put statically linked
umount, dump, restore, sync and halt in /sbin.  Nine times out of ten,
those are the programs I want when I *need* /sbin.

Angela Thomas                   NSFNET: thomas@shire.cs.psu.edu
"If you refuse, you die, she dies, everybody dies."  --Aard