On Wed, Feb 27, 2013 at 12:11:15PM -0500, ed stuckems wrote:
> 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
I would have done:
for f in /dev/sd?; do fdisk -l $f; done
which would have given you something useful.
I agree that fdisk is of more and more limited usage these days since it can't
cope with more than 2TB.
> 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 ;-)
I'm sure there are 10 others also reading this who did too, so thanks for
bringing this practical problem to us. :)
> regards,
> eds.
slainte mhath, RGB
--
Richard Guy Briggs -- ~\ -- ~\ <hpv.tricolour.net>
<www.TriColour.net> -- \___ o \@ @ Ride yer bike!
Ottawa, ON, CANADA -- Lo_>__M__\\/\%__\\/\%
Vote! -- <greenparty.ca>_____GTVS6#790__(*)__(*)________(*)(*)_________________