mount shows mounted partition as /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3

[jd1008]

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.