Jan Birk <jb@hulen.biz> wrote in message news:<3F73CADF.5090406@hulen.biz>...
> I use this device for my keyring ramdisk (USB1):
> mount -F pcfs /dev/dsk/c3t0d0s2:1 /usb

The problem isn't the command, per se.
The problem is I can't figure out, for the life of me,
WHAT device to use (controller, target, disk, slice:fat).

To answer an earlier question, YES I did plug in various USB
devices to each of the two USB ports on the SunBlade1000:
csh% uname -a
REPORTS:
SunOS eunice 5.8 Generic_108528-16 sun4u sparc SUNW,Sun-Blade-1000

I'm a pretty lousy admin (and worse, yet, I hate not knowing how to
do something which should be simple).

Posted below is the mess I've gotten myself into (it's worse than
when I started, it seems as now no USB devices are even noted).
************************************************** **************************
How to install a USB flash stick on a Sun Solaris SunBlade UNIX workstation

work in progress ... unfinished ... this is a mess ...
************************************************** **************************
================================================== ==========================
Reference URLs:
http://docs.sun.com/doc/816-1387?q=scsa2usb (Sun USB Administration Guide)
http://docs.sun.com/db/doc/816-1387/...ew#chapter2-11
http://www.netsys.com/cgi-bin/display_article.cgi?1245
http://www.netsys.com/cgi-bin/man2html?scsa2usb
http://cspry.co.uk/computing/SUN_Bla...iguration.html
================================================== ==========================
WORK IN PROGRESS!

This note is confusing because we are not yet successful in mounting
a USB device to the Sun Solaris 8 workstation named 'eunice'.
Various results are reported below. When we finally get it working, then
we can clean it up and remove extraneous steps.
================================================== ==========================
x. DO NOT PLUG in your USB flash device until told to do so below!
================================================== ==========================
x. Check if your Sun Solaris machine is USB capable:
csh% prtconf -pv | grep 000c03
Which reported: class-code: 000c0310

Note: If this reports a "class-code: 000c0300" line, you have the
UHCI USB controller (typical for Solaris x86).

If there's a "class-code: 000c0310" line, you have the OHCI USB
controller; this controller is typically USB 1.1 at 12 mbit/sec
(which allows, practically, about 1 mbyte per second).

If it reports "class-code: 000c0320", you have the
EHCI (USB v2) controller.
----------------------------------------------------------------------------
x. Display device aliases for all removable mass storage devices:
csh# eject -n
REPORTED:
fd -> floppy0
fd0 -> floppy0
fd1 -> floppy1
diskette -> floppy0
diskette0 -> floppy0
diskette1 -> floppy1
rdiskette -> floppy0
rdiskette0 -> floppy0
rdiskette1 -> floppy1
cd -> cdrom0
cd0 -> cdrom0
cd1 -> cdrom1
sr -> cdrom0
sr0 -> cdrom0
/dev/sr0 -> cdrom0
/dev/rsr0 -> cdrom0
Note: Why did this not report:
rmdisk0 -> /vol/dev/rdsk/c4t0d0/clik40 (Generic USB storage)
----------------------------------------------------------------------------
x. Check to see if you already have a USB flash drive attached by vold:
csh% df -kl | grep rmdisk:c

Might report an existing 128 Gbyte flash disk such as:
Filesystem /vol/dev/dsk/c4t0d0/unnamed_rmdisk:c
kbytes 126912
used 0
avail 126912
capacity 0%
Mounted on /rmdisk/unnamed_rmdisk

This quicknote assumes there were no devices previously mounted by vold.
----------------------------------------------------------------------------
x. Check (and save) messages from the 'scsa2usb' driver (if any):
csh% dmesg | grep scsa2usb
Typically reports nothing if you've never attached a USB
flash drive to this workstation.
----------------------------------------------------------------------------
x. Disable vold volume-daemon automation for your USB flash disk drive:
csh% su root
csh# /etc/init.d/volmgt stop
csh# cp /etc/vold.conf /etc/vold.conf_`date +%y%m%d`
csh# vi /etc/vold.conf
Comment the line which has the entry "rmdisk" defined.
...
# use rmscsi drive /dev/rdsk/c*s2 dev_rmscsi.so rmscsi%d
...
csh# /etc/init.d/volmgt start
You should see a message of: volume management starting.
csh# exit

Note: For Solaris 8, depending on when you perform these tasks, you
may need to fake a change on the vold.conf configuration file,
otherwise a subsequent HUP signal is ignored:
csh# touch /etc/vold.conf
csh# pkill -HUP vold
Note: There may be a problem with vold and the use or non-use of fdisk
partition tables on the media. For example with the Olympus xx40
series of digital cameras (these are seen by the OS as a USB storage
device handled by the S8 scsa2usb driver), the FAT filesystem on the
smart media card is inside an fdisk parition, but vold refuses to use
the fdisk partition information. vold only checks the whole
'/dev/dsk/...p0' (x86) or '/dev/dsk/...s2' (sparc) device for a
filesystem, does not detect any filesystem and offers to format the
media. You have to manually mount the FAT filesystem from the camera
using the /dev/dsk/...p0:c (or /dev/dsk/...s2:c) syntax:
mount -r -F pcfs /dev/dsk/c2d0s0p0:c /camera
----------------------------------------------------------------------------
-x. Begin determining the device your USB flash drive will be once attached:
csh% prtconf -D > /tmp/device_tree_1
----------------------------------------------------------------------------
x. Plug the USB 1.1 flash stick into one of the USB ports on your machine:

Note: In this case, we used an IBM 256 Gbyte flash key, plugged into
a USB extension wire, into a Sun Solaris 8 SunBlade 1000,
---------------------------------------------------------------------------
x. Check which new USB device entries are added (if any) as a result:
csh% prtconf -D > /tmp/device_tree_2
csh% prtconf -D | grep usb
csh% diff /tmp/device_tree_1 /tmp/device_tree_2

If this is the first USB device to be plugged into this machine,
you may see differences of the type shown below:
... ... ... ... ... ... ... ... ... ...
usb, instance #0 (driver name: ohci)
keyboard, instance #2 (driver name: hid)
mouse, instance #3 (driver name: hid)
hub, instance #0 (driver name: hubd)
storage, instance #0 (driver name: scsa2usb)
disk, instance #45 (driver name: sd)
device
... ... ... ... ... ... ... ... ... ...

Notice the OHCI USB controller & the scsa2usb driver.

Note: I'm not sure of the value of this step; please advise as I get
vastly different circumstances depending on unknown circumstances.
----------------------------------------------------------------------------
x. Check for messages from the 'scsa2usb' driver:

csh% dmesg | grep scsa2usb
WHICH REPORTED:
Sep 25 01:14:09 eunice scsi: [ID 193665 kern.info]
sd45 at scsa2usb0: target 0 lun 0

Sep 25 01:14:09 eunice genunix: [ID 408114 kern.info]
/pci@8,700000/usb@5,3/hub@3/storage@1 (scsa2usb0) online

Sep 25 09:09:21 eunice genunix: [ID 408114 kern.info]
/pci@8,700000/usb@5,3/hub@3/storage@1 (scsa2usb0) offline

Notice the "scsa2usb" driver; and notice the "usb@5,3" information.

Note: If you plug and remove the device, you may get additional warnings:
Sep 24 18:46:43 eunice genunix: [ID 408114 kern.info]
/pci@8,700000/usb@5,3/hub@4/storage@1 (scsa2usb1) online

Sep 24 18:46:43 eunice scsi: [ID 193665 kern.info]
sd46 at scsa2usb1: target 0 lun 0

Sep 24 18:46:52 eunice genunix: [ID 408114 kern.info]
/pci@8,700000/usb@5,3/hub@4/storage@1 (scsa2usb1) offline

Sep 24 18:46:58 eunice usba: [ID 464422 kern.warning]
WARNING: /pci@8,700000/usb@5,3/hub@3/storage@1
(scsa2usb0): reinserted device is accessible again

Note: When I reboot, I don't get any of this above anymore. Sigh.
----------------------------------------------------------------------------
x. Determine the SCSI channel the USB device is using:
csh% ls -alrt /dev/rdsk | grep "pci@8,700000/usb@5,3/hub@3/storage@1"
Which reported, in my test, controller c4, target t0, disk d0,
slices s0 thru s7 with sub-slice ":a" thru ":h"
(of which slice "s2" sub-slice ":c" appears to be most significant):

lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s7 ->
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:h,raw

lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s6 ->
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:g,raw

lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s5 ->
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:f,raw

lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s4 ->
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:e,raw

lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s3 ->
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:d,raw

lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s2 ->
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:c,raw

lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s1 ->
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:b,raw

lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s0 ->
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:a,raw

Q: Which DEVICE is the one to mount?
/dev/dsk/c4t0d0s7:h
/dev/dsk/c4t0d0s6:g
/dev/dsk/c4t0d0s5:f
/dev/dsk/c4t0d0s4:e
/dev/dsk/c4t0d0s3:d
/dev/dsk/c4t0d0s2:c
/dev/dsk/c4t0d0s1:b
/dev/dsk/c4t0d0s0:a
A: Presumably we mount c4t0d0s2:c or do we use c4t0d0s2:5 ???
---------------------------------------------------------------------
x. Double-check the selected device to mount:

Q: What does this command actually tell us?
A: ???

csh% fdisk -W - /dev/rdsk/c4t0d0s2
Which reported: fdisk: Cannot open device /dev/rdsk/c4t0d0s2.
csh% fdisk -W - /dev/rdsk/c4t0d0s2:5
Which reported: fdisk: Cannot stat device /dev/rdsk/c4t0d0s2:c.
csh% fdisk -W - /dev/rdsk/c4t0d0s2:c
Which reported: fdisk: Cannot stat device /dev/rdsk/c4t0d0s2:c.

Q: Why does this report information? (Where did the device come from?)
csh% fdisk -W - /dev/rdsk/c1t1d0s2
Which reported:
* /dev/rdsk/c1t1d0s2 default fdisk table
* Dimensions:
* 512 bytes/sector
* 107 sectors/track
* 27 tracks/cylinder
* 24620 cylinders
*
* systid:
* 1: DOSOS12
* 2: PCIXOS
* 4: DOSOS16
* 5: EXTDOS
* 6: DOSBIG
* 7: FDISK_IFS
* 8: FDISK_AIXBOOT
* 9: FDISK_AIXDATA
* 10: FDISK_0S2BOOT
* 11: FDISK_WINDOWS
* 12: FDISK_EXT_WIN
* 14: FDISK_FAT95
* 15: FDISK_EXTLBA
* 18: DIAGPART
* 65: FDISK_LINUX
* 82: FDISK_CPM
* 86: DOSDATA
* 98: OTHEROS
* 99: UNIXOS
* 101: FDISK_NOVELL3
* 119: FDISK_QNX4
* 120: FDISK_QNX42
* 121: FDISK_QNX43
* 130: SUNIXOS
* 131: FDISK_LINUXNAT
* 134: FDISK_NTFSVOL1
* 135: FDISK_NTFSVOL2
* 165: FDISK_BSD
* 167: FDISK_NEXTSTEP
* 183: FDISK_BSDIFS
* 184: FDISK_BSDISWAP
* 190: X86BOOT
*
* Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect
--------------------------------------------------------------------
x. Find your unix device for the newly installed USB flash stick:
csh% su root
csh# devfsadm -v -i sd
csh# iostat -En | more
Which reported a DVD-ROM device:
c0t6d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Vendor: TOSHIBA Product: DVD-ROM SD-M1401 Revision: 1007
Serial No: 06/22/00
Size: 18446744073.71GB <-1 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0

Illegal Request: 0 Predictive Failure Analysis: 0

And which reported many attached disks:
c2t2d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Vendor: SEAGATE Product: ST373405LW Revision: 0003
Serial No: 3EK1CT9Z00007238
Size: 73.40GB <73404694528 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0

And which reported (some times) the USB device:

Q: What does this command tell us?
A: ???

Q: My key question is what DEVICE shall I mount?
csh# mkdir /flash
csh# mount -F pcfs /dev/dsk/????????? /flash
csh# mount -F pcfs /dev/dsk/c4t0d0s2:5 /flash
csh# ls -lR /mnt
--------------------------------------------------------------------
x. Verify your USB device has been added.
csh# ls /dev/rdsk/cntndnsn

Q: Why do I sometimes see 'sd45' instead of the 'c4t0d0s0:c' I'm expecting?
(Is it because I turned off vold for these devices?)
----------------------------------------------------------------------------
x. Read directly from that USB 1.0 flash drive:
csh# od -xc /dev/rdsk/???????? | sed 20q
----------------------------------------------------------------------------
x. Identify the device as 'removable media' for vold support:
csh# format -e /dev/rdsk/????????
> scsi
> inquiry
Make sure "yes" is on the line for removable media:
Vendor: UsbFlash
Product: Drive
Revision: 1.00
Removable media: yes
Device type: 0
ISO version: 0
ECMA version: 0
ANSI version: 0
Async event notification: no
Terminate i/o process msg: no
Response data format: 0
Additional length: 0
Relative addressing: no
32 bit transfers: no
16 bit transfers: no
Synchronous transfers: no
Linked commands: no
Command queueing: no
Soft reset option: no
----------------------------------------------------------------------------
x. Mount that USB 1.0 flash drive:
csh% su root
csh# mkdir /flash
csh# mount -F pcfs /dev/dsk/?????????? /flash
Which reported: mount: /dev/dsk/c1t1d0s2:c is not a DOS filesystem.

Note: I'm trying to find the 'magical' line of the syntax:
csh# mount -F pcfs /dev/dsk/c1t1d0s2:5 /flash
----------------------------------------------------------------------------
x. Add that device to your normal mounting tables:
/dev/dsk/c2t0d0s2:1 - /rmdisk pcfs - no
----------------------------------------------------------------------------
x. Use that USB flash drive:
----------------------------------------------------------------------------
x. Eject that USB flash device:
----------------------------------------------------------------------------


I guess I've screwed it up so badly now but I think the major stumbling
block is HOW DOES ONE DETERMINE WHICH DEVICE THE USB CARD IS PLUGGED INTO?

Please help the needy,
Eunice

Eunice Santorini wrote:
> I guess I've screwed it up so badly now but I think the major stumbling
> block is HOW DOES ONE DETERMINE WHICH DEVICE THE USB CARD IS PLUGGED INTO?

Look in /dev/dsk. Do an "ls -l".

Everything in there will be a symbolic link to something; just what
it's a symbolic link to will depend on how it's attached.
Hopefully with all the other information you've already found, you'll
be able to determine which device(s) are USB-related and which aren't.

You may end up with a list of several devices that are all the same
except for slice numbers. If so, you might have to just try them
all.

Alternatively, I don't know if this works with USB drives (since I've
never tried a USB drive on Solaris), but you could run "format"
and look at the list of disks it gives you.

Hope that helps.

- Logan

unixasaurus@yahoo.com (Eunice Santorini) writes:

> x. Determine the SCSI channel the USB device is using:
> csh% ls -alrt /dev/rdsk | grep "pci@8,700000/usb@5,3/hub@3/storage@1"
> Which reported, in my test, controller c4, target t0, disk d0,
> slices s0 thru s7 with sub-slice ":a" thru ":h"
> (of which slice "s2" sub-slice ":c" appears to be most significant):
>
> lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s7 ->
> ../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:h,raw
>
> lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s6 ->
> ../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:g,raw
>
> lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s5 ->
> ../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:f,raw
>
> lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s4 ->
> ../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:e,raw
>
> lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s3 ->
> ../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:d,raw
>
> lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s2 ->
> ../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:c,raw
>
> lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s1 ->
> ../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:b,raw
>
> lrwxrwxrwx 1 root root 65 Sep 23 15:24 c4t0d0s0 ->
> ../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:a,raw
>
> Q: Which DEVICE is the one to mount?
> /dev/dsk/c4t0d0s7:h
> /dev/dsk/c4t0d0s6:g
> /dev/dsk/c4t0d0s5:f
> /dev/dsk/c4t0d0s4:e
> /dev/dsk/c4t0d0s3:d
> /dev/dsk/c4t0d0s2:c
> /dev/dsk/c4t0d0s1:b
> /dev/dsk/c4t0d0s0:a
> A: Presumably we mount c4t0d0s2:c or do we use c4t0d0s2:5 ???

It depends on the data stored on the device.

A standard SunOS disk label might exist on the device, with upto eight
different slices, and each slice might contain a different filesystem.
Similar to your HDD.

But these usb removable media devices often come from the
"DOS/Windows" world, so they don't contain SunOS disk labels. When a
valid SunOS disk label is missing, the SunOS disk driver creates a
"fake" slice table. It creates a slice table with slices "s0" and
"s2", and both can be used to access all of the data sectors contained
on the device.

Here's an example for an USB 256MB flash memory device. The command
"prtvtoc" prints the SunOS slice table for the device:

# prtvtoc /dev/rdsk/c4t0d0s2
* /dev/rdsk/c4t0d0s2 partition map
*
* Dimensions:
* 512 bytes/sector
* 32 sectors/track
* 64 tracks/cylinder
* 2048 sectors/cylinder
* 0 cylinders
* 250 accessible cylinders
*
* Flags:
* 1: unmountable
* 10: read-only
*
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 0 00 0 512000 511999
2 0 00 0 512000 511999


With this slice table, you can use the devices /dev/rdsk/c4t0d0s0
and /dev/rdsk/c4t0d0s2 to access the device. All other slices on
that device (s1, s3, ..., s7) cannot be used.

> ---------------------------------------------------------------------
> x. Double-check the selected device to mount:
>
> Q: What does this command actually tell us?
> A: ???
>
> csh% fdisk -W - /dev/rdsk/c4t0d0s2
> Which reported: fdisk: Cannot open device /dev/rdsk/c4t0d0s2.
> csh% fdisk -W - /dev/rdsk/c4t0d0s2:5
> Which reported: fdisk: Cannot stat device /dev/rdsk/c4t0d0s2:c.
> csh% fdisk -W - /dev/rdsk/c4t0d0s2:c
> Which reported: fdisk: Cannot stat device /dev/rdsk/c4t0d0s2:c.

The fdisk command probably cannot open the disk device because you're
not logged in as user "root".

The output from the fdisk command gives a hint if the media contains
a "DOS" FDISK partition table.

Using my usb 256MB flash memory device as an example:

# fdisk -W - /dev/rdsk/c4t0d0s2

* /dev/rdsk/c4t0d0s2 default fdisk table
* Dimensions:
* 512 bytes/sector
* 32 sectors/track
* 64 tracks/cylinder
* 250 cylinders
*
* systid:
....
* 6: DOSBIG

* Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect
6 128 1 1 0 16 32 1000 32 511967


The important information is printed after the "* Id Act Bhead ...."
line. This USB device contains one FDISK partition entry, the partition
is type 6 (Id 6 == DOSBIG), the partition is marked "Active" (128),
it starts at sector 32 (Rsect) and contains 511967 (Numsect) sectors.


To mount the "BIGDOS" FAT filesystem from the FDISK partition starting
at sector 32, the mount command would be

mount -F pcfs /dev/dsk/c4t0d0s2:c /mnt


If no data is printed following the "Id Act Bhead..." line, then
there's no valid DOS FDISK table on that media. In that case you
cannot use the ":c" logical drive suffix with the mount pcfs command.
But the media could still contain a DOS FAT filesystem, starting at
sector #0 of the device. To mount such a device, you would use the
command

mount -F pcfs /dev/dsk/c4t0d0s2 /mnt

> > Q: Which DEVICE is the one to mount?
> > /dev/rdsk/? vs /dev/dsk/?
> > c4t0d0s0 ? vs c4t0d0s1 vs c4t0d0s2 etc. ???
> > c4t0d0s2:c vs c4t0d0s2:1
> > etc.
> When a valid SunOS disk label is missing, the SunOS disk driver creates
> a "fake" slice table. It creates a slice table with slices "s0" and
> "s2", and both can be used to access all of the data sectors contained
> on the device. ... stuff removed ...
> mount -F pcfs /dev/dsk/c4t0d0s2 /mnt

With your expert advice, I was able to get one of two USB slots to work
on my Sun Solaris 8 SunBlade1000 assuming the following caveats! Thanks!
Here's a summary (as always) for others to benefit (we're not done yet).

a) I'm sorry I ever touched the vold.conf file in the first place.
Nothing worked the same once I did. I put it all back the way it
originally was and rebooted. The pertinent vold.conf line is currently:
use rmdisk drive /dev/rdsk/c*s2 dev_rmdisk.so rmdisk%d

b) I plugged TWO USB flash cards into the two USB slots in the back of
the SunBlade1000 (figuring that would give me twice as many chances
at hitting just the right combination of dsk vs rdsk and controllers,
targets, disks, slices (0 and 2 only), and FAT sections (either a thru
h or 1 thru 5 apparently). Whew! That's a lot of variables.

d) Mea culpa on the two UNIX newbie mistakes I made in my prior tests.
- I now run 'fdisk' as root only (nothing else will do)
- I won't use 'dmesg' for yesterday's events (I'll use /var/adm/message).
And, just in case, I removed the USB wire extension (Sun says never use
them, but, hey, it's just a wire) in case that was causing one of the
two USB devices to not be seen by UNIX commands suggested in this thread.

Other than that, I basically GUESSED (one by one) at the dsk vs rdsk
combination; combined with a huge variety of controller/target/disk/slice
combinations (thanks for letting me know only slice 0 and 2 were relevant
to DOS-formatted USB flash sticks); combined with FAT sub-slice partitions
of a thru h vs 1 thru 5 (thanks for providing an example which used the
DOS sub-slice of the number 1); etc.

The command which (finally) mounted the 128 Mbyte USB flash card was:
csh# mkdir /usb_128
csh# mount -F pcfs /dev/dsk/c5t0d0s2:1 /usb_128

Of course, I GUESSED at this by testing other dsk/rdsk & controller & DOS
sub-slice combinations until this worked; so, it wasn't at all a rational
process - but the proof of the mount was vividly shown in the log file
below (working backward from success to failure):
csh% cd /usb_128
csh% df -kl . (or df -k /usb_128)
BOTH OF WHICH REPORTED:
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c5t0d0s2:1 126912 2544 124368 3% /usb_128
And:
csh# prtvtoc /dev/dsk/c5t0d0s2
REPORTED:
Partition (i.e., slice) 0 and 2 were the entire device
csh% cd /usb_128
csh% ls -alsF
REPORTED: the DOS data placed there by the WinXP PC.
And:
csh% su root
csh# fdisk -W - /dev/rdsk/c5t0d0s2
REPORTED (condensed to the essentials as you've explained them):
* /dev/rdsk/c5t0d0s2 default fdisk table
...
* 512 bytes/sector
* 32 sectors/track
* 64 tracks/cylinder
* 124 cylinders
...
* systid:
...
* 6: DOSBIG
...
* Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect
6 0 1 16 0 15 32 499 47 253905

QUESTION: Does it bother anyone that the ACTIVE number is ZERO?

And:
csh# devfsadm -v -i sd
csh# iostat -En | more
REPORTED (incorrect size information):
c5t0d0 ... blah ... blah ... blah ...
Vendor: UsbFlash Product: Drive Revision: 1.00
Serial No: Size: 0.00GB <0 bytes>
... and ...
sd45 ... blah ... blah ... blah ...
Vendor: UsbFlash Product: Drive Revision: 1.00
Serial No: Size: 0.00GB <0 bytes>
QUESTION: Is 'sd45' the other flash card (i.e., 256 Mbytes) I plugged in?
And:
csh# od -xc /dev/rdsk/c5t0d0s0 | sed 20q
REPORTED: 20 lines of data available at that 'rdsk' device.
QUESTION: When (please) do I use 'rdsk' vs 'dsk' in this USB process?
And:
csh% prtconf -D > /tmp/device_tree_1
Plug in both USB devices (128 Mb & 256 Mb) sans extension cable.
csh% prtconf -D > /tmp/device_tree_2
csh% diff /tmp/device_tree_1 /tmp/device_tree_2
REPORTED the proper scsa2usb drivers I believe:
> hub, instance #1 (driver name: hubd)
> storage, instance #1 (driver name: scsa2usb)
> disk, instance #46 (driver name: sd)
> device
And:
csh% dmesg | grep scsa2usb
REPORTED (after I plugged in BOTH USB devices):
Sep 26 17:10:10 flow usba: [ID 855233 kern.info]
USB-device: storage@1, scsa2usb0 at bus address 5
Sep 26 17:10:10 flow genunix: [ID 936769 kern.info]
scsa2usb0 is /pci@8,700000/usb@5,3/hub@3/storage@1
Sep 26 17:10:10 flow scsi: [ID 193665 kern.info]
sd45 at scsa2usb0: target 0 lun 0
Sep 26 17:10:10 flow genunix: [ID 408114 kern.info]
/pci@8,700000/usb@5,3/hub@3/storage@1 (scsa2usb0) online
Sep 26 17:10:24 flow genunix: [ID 408114 kern.info]
/pci@8,700000/usb@5,3/hub@3/storage@1 (scsa2usb0) offline
Sep 26 17:10:27 flow usba: [ID 855233 kern.info]
USB-device: storage@1, scsa2usb1 at bus address 5
Sep 26 17:10:27 flow genunix: [ID 936769 kern.info]
scsa2usb1 is /pci@8,700000/usb@5,3/hub@4/storage@1
Sep 26 17:10:27 flow genunix: [ID 408114 kern.info]
/pci@8,700000/usb@5,3/hub@4/storage@1 (scsa2usb1) online
Sep 26 17:10:27 flow scsi: [ID 193665 kern.info]
sd46 at scsa2usb1: target 0 lun 0

QUESTION: The command below was suggested (based on the ouput from the
previous command above; but I have no clue what this tells me)?

csh% ls -alrt /dev/rdsk | grep "pci@8,700000/usb@5,3/hub@3/storage@1"
WHICH REPORTED:
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:h,raw
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:g,raw
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:f,raw
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:e,raw
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:d,raw
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:c,raw
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:b,raw
../../devices/pci@8,700000/usb@5,3/hub@3/storage@1/disk@0,0:a,raw

Note: I removed the "eject -n" command for the same reason; I don't see
what it tells me with respect to USB debugging (do you)?

In summary, the high-priority QUESTIONS which remain are:
Q: Where is the SECOND USB device? Is it at something called sd45?
If it's sd45, how do I find the mount "/dev/?dsk/c?t?d?s?:?" argument?
What is "sd45" if it's not the second USB flash card I plugged in?
Q: Should vold.conf be modified or not (methinks it should be left alone)?

The low-priority questions which remain are:
Q: What does "ls -alrt /dev/rdsk" tell us about debugging USB devices?
Q: When (please) do I use 'rdsk' vs 'dsk' in the USB-debugging process?
Q: Is it a problem that "fdisk -W - /dev/rdsk/c5t0d0s2 " ACTIVE = ZERO?
Q: Is a USB extension cable really a bad idea?

Thanks for helping me (& everyone else who installs USB on Sun Solaris 8),
Eunice
--
Please note I never read email at this address as it is a spam trap (sorry).

> In summary, the high-priority QUESTIONS which remain are:
> Q: Where is the SECOND USB device? Is it at something called sd45?
> If it's sd45, how do I find the mount "/dev/?dsk/c?t?d?s?:?" argument?
> What is "sd45" if it's not the second USB flash card I plugged in?
> Q: Should vold.conf be modified or not (methinks it should be left alone)?

I don't have the 'hub@' in my device tree so I might be wrong but......


> Sep 26 17:10:10 flow genunix: [ID 936769 kern.info]
> scsa2usb0 is /pci@8,700000/usb@5,3/hub@3/storage@1
^
c5

> Sep 26 17:10:27 flow genunix: [ID 936769 kern.info]
> scsa2usb1 is /pci@8,700000/usb@5,3/hub@4/storage@1
^
c5

The conroller is the same so whatever link(s) in /dev/rdsk/c5* that
points to

.../../devices/pci@8,700000/usb@5,3/hub@4/storage@1......

should be the second flash card.

I'm not sure though where the second card would be indicated in c?t?d?.
c? is controller, so either t? or d? should point to the disk. I'm not
sure how hub & storage map to t? and d?.

I usually look at the dates & times in /dev/rdsk & see which ones were
created/changed about the time that I started installing stuff or when I
ran devfsadm.

--Mike

unixasaurus@yahoo.com (Eunice Santorini) writes:

> csh% su root
> csh# fdisk -W - /dev/rdsk/c5t0d0s2
> REPORTED (condensed to the essentials as you've explained them):

> ...
> * Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect
> 6 0 1 16 0 15 32 499 47 253905
>
> QUESTION: Does it bother anyone that the ACTIVE number is ZERO?

No. That just means the filesystem contained in this fdisk parition is
not bootable.