On Wed, Feb 27, 2013 at 10:52 AM, ed stuckems <edstuckems [ at ] gmail [ dot ] com> wrote:
> On Wed, Feb 27, 2013 at 9:49 AM, Shawn H Corey <shawnhcorey [ at ] gmail [ dot ] com> wrote:
> <snip>
>> When you plug in the drive, does /dev/disk/ get a new entry?
>
> Yes it does. Actually, it gets 3 new entries. Sorry, this is new
> territory for me and I can't derive any insight from the new entries.
> Maybe someone here can so I've copied them below
>
> /dev/disk/by-path/pci-0000:00:1a.0-usb-0:1.2.1:1.0-scsi-0:0:0:0
> /dev/disk/by-id/wwn-0x5XXXXXXXXXXXXXf
> /dev/disk/by-id/ata-WDC_WD10EADS-22M2B0_WD-XXXXXXXXXXXX
>
> If I had to guess what this means, I'd have to guess that:
> (1) the cable is properly connected because the first entry above
> seems to indicate there are connections between usb subsystem and scsi
> subsystem. I don't believe these would have been created if the
> hardware didn't recognize the physical cable connection.
> (2) the physical drive is detected. The third entry is based on the
> drive's serial number (blotted out because 1984 scared the crap out of
> me ;-)
>
> Now my question is, can I use any of these entries with something like
> parted or mkfs?
>
> (I think this was an excellent question! I hope my responses lead somewhere.)
>
YES, YES I CAN! At least parted seems to work. Accessing the drive
via one of the above device files still seems risky to me.
Okay, I saved the draft e-mail, dug around a little more and I think I
was able to answer some of my own questions. So I'm back in the
e-mail to tell you all what I discovered.
It appears that I was wrong about what I had seen earlier ... the
drive was being attached to a device file but I failed to catch it.
Here's how I discovered my problem (it was all thanks to Shawn's most
excellent question. Shawn I owe you one!)
I poked around the /dev/disk directory and discovered it contains the
following directories:
- by-id
- by-label
- by-partlabel
- by-partuuid
- by-path
- by-uuid
Each directory contains sym-links back some device file in /dev!
Since parted worked on one of these sym-links, it meant that one of
the /dev/sd{a,b,c,d,e,f,g} files was connected to the drive, in
particular the link was to /dev/sdg. Once I realized this, I went
back to see what I had done. It turns out that running:
for f in /dev/sd{a,b,c,d,e,f,g}; do parted -s $f; done
produces error messages for those devices that weren't mapped (and
nothing for those device files that were mapped). I failed to notice
that /dev/sdg didn't return an error, ie it did map. While there was
a device file connected to the drive, there was no /dev/sdg1 because
the partition wasn't correctly created.
Sorry for my mistake (but I did learn something from it ;-)
regards,
eds.