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.
You were right Rick!
I just changed the boot order so that as far as hard drives go,
the internal drive is before the esata and the dock.
Thanx again Rick.
Cheers,
JD
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
