mount shows mounted partition as /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3

[jd1008]

On 10/10/2014 04:21 PM, Rick Stevens wrote:
> On 10/10/2014 12:32 PM, jd1008 issued this missive:
>> On 10/08/2014 03:16 AM, Ed Greshko wrote:
>>> On 10/08/14 11:37, jd1008 wrote:
>>>> On 10/07/2014 09:11 PM, Ed Greshko wrote:
>>>>> lvm pvdisplay
>>>>> lvm vgdisplay
>>>>> lvm lvdisplay
>>>> # lvm pvdisplay
>>>> # lvm pvdisplay -v
>>>>       Scanning for physical volume names
>>>> # lvm pvdisplay -vvv
>>>>         Setting activation/monitoring to 1
>>>>           Processing: pvdisplay -vvv
>>>>           O_DIRECT will be used
>>>>         Setting global/locking_type to 1
>>>>         Setting global/wait_for_locks to 1
>>>>         File-based locking selected.
>>>>         Setting global/locking_dir to /run/lock/lvm
>>>>         Setting global/prioritise_write_locks to 1
>>>>       Scanning for physical volume names
>>>>           Asking lvmetad for complete list of known PVs
>>>>         Setting response to OK
>>>>         Setting response to OK
>>>>           Completed: pvdisplay -vvv
>>>> # lvm vgdisplay
>>>>     No volume groups found
>>>> # lvm lvdisplay
>>>>     No volume groups found
>>>>
>>> Well there are no lvm related file systems.
>>>
>>> But, you said you had this....
>>>
>>> # mount | grep sdc3
>>> /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3 on /sdc3 type ext4
>>> (rw,relatime,journal_checksum)
>>>
>>> So, the file system defined by
>>> /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3 is mounted on the
>>> mount point /sdc3.   /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
>>> is probably a link to some thing else which may give a clue.
>>>
>>> /dev/mapper, AFAIK, is only used for lvm, part of a RAID, or dm-crypt
>>> partitions.
>>>
>>> Do you know what this disk is supposed to contain?  If nothing is
>>> valuable I'd just wipe it clean and repartition everything.
>>>
>>> You mention problems talked about on blogs and things....but don't
>>> cite references so nobody can vet the information.
>>>
>>>
>> I discovered the cause of this Cr*P!
>>
>> The Dell Latitude E6500 BIOS has 4 different settings fo the operation
>> of the eSATA chipset.
>> It was set on /Intel Raid Recovery/
>> Even though no raid was configured, and disk operations were in plain
>> disk mode.
>>
>> The weird part of this is that the disk partition sdc3 is the only
>> partition on the drive.
>> But was being treated by linux as a raid partition.
>>
>> Turns out that the drive was partitioned this way when the bios eSATA
>> operation mode was
>> set to Intel Raid Recovery mode. I ave no idea what effect this has on
>> the physical drive's
>> partitioning scheme. But apparently it does seem to have some such effect.
>> So, what I did, I changed the BIOS setting of the eSATA Operation mode
>> to AHCI.
>> Now, if I boot the system with the drive connected via the eSATA port,
>> the system will not boot.
>> If I disconnect the drive, the system boots and I get into the grub menu.
>> So, for now, what I am doing is
>> while I am in the grub menu (the time-out of which I have increased to
>> 30 seconds),
>> I connect the external eSATA drive, and proceed to boot normally.
>> Now Linux detects /dev/sdc and /dev/sdc3.
>> I have been scouring the web for a fix for this weird anomaly of the
>> Dell BIOS.
>> I have not found it yet, but search continues.
> You probably have the boot order set to look at the eSATA port first,
> then the internal drives. On my N7110, you can hit F12 during boot and
> select the boot device, or go down to "Setup" and set the boot order
> there permanently.
>
> Remember that if eSATA is above the internal disk in that list and you
> have an eSATA drive plugged in, then the system will try to boot from
> eSATA. Pretty obvious. I typically have the order permanently set to:
>
> 	USB
> 	CD/DVD
> 	Internal Disk
> 	eSATA
> 	Network
> 	(anything else)
>
> and if I need to alter it for a specific boot, I hit F12 and change it.
> Set it up however you want it.
Hmmm. I might have missed that.
I will check  on the next boot and get back on this.

Thanx Rick.