On 10/10/2014 07:06 PM, jd1008 issued this missive: > > 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. Glad to be of service! ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Do you know where _your_ towel is? - ---------------------------------------------------------------------- -- 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
