SUMMARY: ufsdump errors (aka Duh!)

From: Derek_Schatz@amat.com
Date: Tue Aug 19 1997 - 16:55:29 CDT


Hello SM's-

Thanks to everyone who responded and confirmed that, yes,
I'm an idiot who shouldn't be trusted around computers. I do
appreciate that I wasn't flamed to a pile of smoldering cinders.
Although I still insist that I have had actual problems with
this tape drive, this time around it's me having problems
with syntax.
Thanks to:
Rodney C. Marable marable@firefly.net
Tim Evans tkevans@eplrx7.es.dupont.com
Mike (?) mike@trdlnk.com

*** Original question ***

I have a SPARCserver 1000E on Solaris 2.5.1 with a Sun 4mm DAT tape
drive attached (Archive Python). I've been getting all sorts of odd
errors with this drive when trying to do a dump. I should mention
that I inherited this drive from elsewhere, and have personally
not yet been able to use it successfully. Other errors I've gotten
seem to indicate that maybe the drive itself is having problems.
It shares the SCSI bus with a Sun multi-pack drive. I have verified
SCSI ID's and termination to be OK. Here's the error:
# ufsdump 0u /dev/rmt/0 /dev/rdsk/c0t1d0s1
  DUMP: Warning - block 16 is beyond the end of `/dev/rmt/0'
  DUMP: Warning - super-block on device `' is corrupt - run fsck
  DUMP: The ENTIRE dump is aborted.
Anyone have any ideas? It's a brand new tape (the second one I've
tried), it's rewound, I just ran a cleaning cartridge through it,
and the device files "should" be OK (but maybe they aren't?).

*** Answer ***
Given the aforementioned syntax, I left out an 'f', i.e. '0uf' for
options, rather than just '0u'. This is because I explicitly gave
the dump destination as /dev/rmt/0. Otherwise, ufsdump just assumes
that's the destination, thus allowing one to specify instead:

   ufsdump 0u /dev/rdsk/c0t1d0s1

and thus resulting in less likelihood of injuring oneself with
unnecessary parameters.

Regards,
Derek Schatz
schatz_derek@amat.com



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:00 CDT