[geeks] Raw disk access under Solaris

[Mouse]

> [...], so I am throwing myself upon the mercy of the wise Sun geeks
> out there (impress me, Mouse).

Heh.  Unfortunately in this case I fear I'm more likely to impress you
with my ignorance than anything else. :-/

> I'm trying to make an image of a non-Sun Differential SCSI disk on an
> Ultra2 running Solaris 9.  The only HVD controllers I own are the
> fairly standard Sun qLogic controllers, so I'm limited to using this
> platform with what I have.

I take it you're sure the disk is HVD rather than LVD?  AIUI they are
not compatible.  (Edit: see below; this is unlikely to be relevant.)

> I expected it would be as simple as connecting the drive and doing a
> dd on slice2, which I was under the impression was the whole disk,
> but whenever I try I get an 'I/O Error'.

I don't know how Sol 9 handles partitioning.  If a Solaris "slice" is
just another name for what SunOS called a "partition", then slice 2
probably is the whole drive.  But if they're something more
elaborate/elegant/etc, then you may need something else.  For example,
I recall seeing one system - I can't recall whether it was even a Sun
system, never mind details - where the whole disk was something like
/dev/disk/foo, with recursive partitioning support, so you could have
something like /dev/disk/foo/part5 for what older systems would call
partition e, then, if that piece of disk is further partitioned,
something like /dev/disk/foo/part5/part1.  Etc - I've probably got the
details all wrong, but that's what I recall.

I mention here just to say that, if Solaris 9 does anything like that,
the name for the whole disk may not look anything like the names for
the partitions on it.

Another possibility is that Solaris 9 still has the distinction between
raw disk device and block disk devices (what SunOS with, say, an xy
drive would have called /dev/xy0c vs /dev/rxy0c).  On at least some
such systems, access to an unlabeled drive works only if you use the
raw device, not the block device - /dev/rxy0c rather than /dev/xy0a, in
the old naming scheme - and it's possible that Solaris 9 is such a
system and you're getting the wrong device.

It's also possible that Solaris 9 has a conventional whole-disk
partition, but uses something other than partition 2 for it.  Did you
try reading any other slices?

> What I'm wondering is if the reason it's failing is because it's
> _not_ a Sun disk and so while Solaris is enumerating the
> slices/partitions, since there isn't actually a readable partition
> map for Solaris it's bombing out.

Possibly.  But Solaris must have _some_ way to access the raw disk, or
it couldn't write partition tables on new drives to begin with.  (I
suppose it's possible that that way exists only in the kernel, but that
strikes me as unlikely.)

I don't suppose you could do something like boot a NetBSD CD and use
that?  If you have an NFS server on your network, even an install CD
can be used as a live CD (pick the utilities menu, then the option to
run sh, then ifconfig the network and NFS mount your NFS server, then
you can run stuff off the NFS area - chroot is your friend - regardless
of whether it's on the install CD).  SPARCLinux probably has live CDs
as well, though I know just about nothing about SPARCLinux, so that's
strictly a guess.

> I've made certain the /dev/dsk/ drive is pointing to the right
> /devices/ qLogic controller and drive ID, the drive has internal
> terminators enabled so it's a direct SCSI cable between the
> controller and the drive.

Good; I was going to ask about termination if you didn't say.

> The only other thing I'm doing that might be considered out of the
> norm is I have the write protect jumper enabled on the drive itself.

Sounds sensible to me.

> Am I mistaken on my assumption of where this issue is?  Is there
> actually a lower-level access problem with the drive?  (It is
> correctly identified by a probe-scsi-all)

If probe-scsi-all locates it and identifies it correctly, there are a
whole lot of low-level issues that are known to be absent.  For
example, LVD vs HVD is not the problem, since you have working
communication with the drive.

It's conceivable that, for example, it works async but not sync.
However, I don't know how to tell Solaris to force async.  (Heck, I'm
not sure how to tell even NetBSD to force async.)

Since you didn't mention any, I'm assuming Solaris isn't reporting any
device errors when you try to access it.  I'm also assuming you get
_no_ data, as opposed to getting a little bit and then errors.  My best
guess at present, then, is much like yours, that the problem is that
you somehow aren't getting the full-drive disk device.

Anyway, I hope this ends up helping you somehow.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B