3:52 p.m.
# mount | grep sdc3
/dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3 on /sdc3 type ext4
(rw,relatime,journal_checksum)
So, how come I do not see it listed as I see /dev/sda3. To wit:
# mount | grep sda3
/dev/sda3 on / type ext4 (rw,relatime,data=ordered)
If I unmount /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
# umount /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
and I try
# mount /dev/sdc3 /sdc3
mount: special device /dev/sdc3 does not exist
# grep sdc3 /etc/fstab
UUID=e64d7b94-1ffb-4a2e-ae59-5f8e54b6cab9 /sdc3 ext4
noauto,data=ordered,journal_checksum 3 3
# blkid /dev/sdc3
/dev/sdc3: UUID="e64d7b94-1ffb-4a2e-ae59-5f8e54b6cab9" TYPE="ext2"
PARTUUID="96e20bf8-03"
dmesg shows these errors:
[ 25.083098] systemd-udevd[385]: inotify_add_watch(7, /dev/sdc3, 10)
failed: No such file or directory
[ 25.084057] systemd-udevd[386]: inotify_add_watch(7, /dev/sdc4, 10)
failed: No such file or directory
[ 25.085042] systemd-udevd[384]: inotify_add_watch(7, /dev/sdc2, 10)
failed: No such file or directory
[ 25.087052] systemd-udevd[381]: inotify_add_watch(7, /dev/sdc1, 10)
failed: No such file or directory
Runing partprobe:
# partprobe
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF4
failed: Device or resource busy
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF3
failed: Device or resource busy
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF2
failed: Device or resource busy
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF1
failed: Device or resource busy
Warning: parted was unable to re-read the partition table on
/dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF (Device or resource
busy). This means Linux won't know anything about the modifications you
made.
device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF1
failed: Device or resource busy
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF1
failed: Device or resource busy
device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF2
failed: Device or resource busy
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF2
failed: Device or resource busy
device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF3
failed: Device or resource busy
device-mapper:remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF3
failed: Device or resource busy
device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF4
failed: Device or resource busy
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF4
failed: Device or resource busy
device-mapper: remove ioctl on WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83p3
failed: Device or resource busy
Warning: parted was unable to re-read the partition table on
/dev/mapper/WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83 (Device or resource
busy). This means Linux won't know anything about the modifications you
made.
device-mapper: create ioctl on WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83p3
failed: Device or resource busy
device-mapper: remove ioctl on WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83p3
failed: Device or resource busy
So, whatmight be causing this?
6:42 p.m.
New subject: mount shows mounted partition as /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
On 10/07/2014 05:23 PM, Junk wrote:
On 7 October 2014 21:52:05 GMT+01:00, jd1008 <jd1008(a)gmail.com>
wrote:
> # mount | grep sdc3
> /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3 on /sdc3 type ext4
> (rw,relatime,journal_checksum)
>
> So, how come I do not see it listed as I see /dev/sda3. To wit:
> # mount | grep sda3
> /dev/sda3 on / type ext4 (rw,relatime,data=ordered)
>
> If I unmount /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
>
> # umount /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
>
> and I try
> # mount /dev/sdc3 /sdc3
> mount: special device /dev/sdc3 does not exist
>
> # grep sdc3 /etc/fstab
>
> UUID=e64d7b94-1ffb-4a2e-ae59-5f8e54b6cab9 /sdc3 ext4
> noauto,data=ordered,journal_checksum 3 3
>
> # blkid /dev/sdc3
> /dev/sdc3: UUID="e64d7b94-1ffb-4a2e-ae59-5f8e54b6cab9"
TYPE="ext2"
> PARTUUID="96e20bf8-03"
>
>
> dmesg shows these errors:
>
> [ 25.083098] systemd-udevd[385]: inotify_add_watch(7, /dev/sdc3, 10)
> failed: No such file or directory
> [ 25.084057] systemd-udevd[386]: inotify_add_watch(7, /dev/sdc4, 10)
> failed: No such file or directory
> [ 25.085042] systemd-udevd[384]: inotify_add_watch(7, /dev/sdc2, 10)
> failed: No such file or directory
> [ 25.087052] systemd-udevd[381]: inotify_add_watch(7, /dev/sdc1, 10)
> failed: No such file or directory
>
>
> Runing partprobe:
>
> # partprobe
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF4
> failed: Device or resource busy
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF3
> failed: Device or resource busy
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF2
> failed: Device or resource busy
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF1
> failed: Device or resource busy
> Warning: parted was unable to re-read the partition table on
> /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF (Device or resource
> busy). This means Linux won't know anything about the modifications
> you
> made.
> device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF1
> failed: Device or resource busy
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF1
> failed: Device or resource busy
> device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF2
> failed: Device or resource busy
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF2
> failed: Device or resource busy
> device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF3
> failed: Device or resource busy
> device-mapper:remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF3
> failed: Device or resource busy
> device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF4
> failed: Device or resource busy
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF4
> failed: Device or resource busy
> device-mapper: remove ioctl on WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83p3
> failed: Device or resource busy
> Warning: parted was unable to re-read the partition table on
> /dev/mapper/WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83 (Device or resource
> busy). This means Linux won't know anything about the modifications
> you
> made.
> device-mapper: create ioctl on WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83p3
> failed: Device or resource busy
> device-mapper: remove ioctl on WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83p3
> failed: Device or resource busy
>
> So, whatmight be causing this?
>
> --
> users mailing list
> users(a)lists.fedoraproject.org
> 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
What's the output of lsblk?
It looks a bit like your using LVM
--
Junk
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 128M 0 part
├─sda2 8:2 0 32G 0 part
├─sda3 8:3 0 891.4G 0 part /
└─sda4 8:4 0 8G 0 part [SWAP]
sdb 8:16 0 1.8T 0 disk
└─sdb3 8:19 0 1.8T 0 part
sdc 8:32 0 465.8G 0 disk
├─sdc1 8:33 0 41.8G 0 part
├─sdc2 8:34 0 202M 0 part
├─sdc3 8:35 0 416G 0 part
├─sdc4 8:36 0 1K 0 part
└─sdc5 8:37 0 7.8G 0 part
sr0 11:0 1 1024M 0 rom
I have no LVM's configured.
12:10 p.m.
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(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- Do you know where _your_ towel is? -
----------------------------------------------------------------------
9:06 p.m.
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
7:59 p.m.
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.
5:21 p.m.
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.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- Okay, who put a "stop payment" on my reality check? -
----------------------------------------------------------------------
1:51 p.m.
New subject: mount shows mounted partition as /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
What does 'ls -l /dev/sd*' say?
Have you tried 'tune2fs -l /dev/sdc3' (if there is one)? That should give you the
UUID.
Bill
On 10/8/2014 8:00 PM, Junk wrote:
Well if it's not lvm that leaves raid, luks encrypted partitions,
docker or using an ssd as a cache for a magnetic
disk. dm-raid, dm-crypt, dm-mapper and dm-cache. Having said that, I'd expect lsblk
to show a bit more and you've
proved the UUID matches the raw partition. Do you have a link to the blog you mentioned
earlier? -- Junk
2:32 p.m.
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.
7 p.m.
New subject: mount shows mounted partition as /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
On 8 October 2014 04:37:19 GMT+01:00, jd1008 <jd1008(a)gmail.com> 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
--
users mailing list
users(a)lists.fedoraproject.org
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
Well if it's not lvm that leaves raid, luks encrypted partitions, docker or using an
ssd as a cache for a magnetic disk. dm-raid, dm-crypt, dm-mapper and dm-cache.
Having said that, I'd expect lsblk to show a bit more and you've proved the UUID
matches the raw partition. Do you have a link to the blog you mentioned earlier?
--
Junk
4:16 a.m.
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.
--
If you can't laugh at yourself, others will gladly oblige.
10:37 p.m.
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
10:02 p.m.
On 10/07/2014 08:25 PM, Ralf Corsepius wrote:
On 10/07/2014 10:52 PM, jd1008 wrote:
> and I try
> # mount /dev/sdc3 /sdc3
> mount: special device /dev/sdc3 does not exist
Well, you'd have to manually create a directory /sdc3 (The "mount
point") before mounting to make this work.
> # grep sdc3 /etc/fstab
>
> UUID=e64d7b94-1ffb-4a2e-ae59-5f8e54b6cab9 /sdc3 ext4
> noauto,data=ordered,journal_checksum 3 3
Ralf
Sorry Ralf - I know that, and the directory exists.
But this, according to many blogs, forums, support lists, is
not a new problem. It is all over google.
The funny thing about it is the amazing silence of
the fedora devs (who also read this list), about this problem :)
Maybe they know something?? :) :)
9:25 p.m.
On 10/07/2014 10:52 PM, jd1008 wrote:
and I try
# mount /dev/sdc3 /sdc3
mount: special device /dev/sdc3 does not exist
Well, you'd have to manually create a directory /sdc3 (The "mount
point") before mounting to make this work.
# grep sdc3 /etc/fstab
UUID=e64d7b94-1ffb-4a2e-ae59-5f8e54b6cab9 /sdc3 ext4
noauto,data=ordered,journal_checksum 3 3
Ralf
9:12 p.m.
New subject: mount shows mounted partition as /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
On 10/07/2014 05:23 PM, Junk wrote:
On 7 October 2014 21:52:05 GMT+01:00, jd1008 <jd1008(a)gmail.com>
wrote:
> # mount | grep sdc3
> /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3 on /sdc3 type ext4
> (rw,relatime,journal_checksum)
>
> So, how come I do not see it listed as I see /dev/sda3. To wit:
> # mount | grep sda3
> /dev/sda3 on / type ext4 (rw,relatime,data=ordered)
>
> If I unmount /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
>
> # umount /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
>
> and I try
> # mount /dev/sdc3 /sdc3
> mount: special device /dev/sdc3 does not exist
>
> # grep sdc3 /etc/fstab
>
> UUID=e64d7b94-1ffb-4a2e-ae59-5f8e54b6cab9 /sdc3 ext4
> noauto,data=ordered,journal_checksum 3 3
>
> # blkid /dev/sdc3
> /dev/sdc3: UUID="e64d7b94-1ffb-4a2e-ae59-5f8e54b6cab9"
TYPE="ext2"
> PARTUUID="96e20bf8-03"
>
>
> dmesg shows these errors:
>
> [ 25.083098] systemd-udevd[385]: inotify_add_watch(7, /dev/sdc3, 10)
> failed: No such file or directory
> [ 25.084057] systemd-udevd[386]: inotify_add_watch(7, /dev/sdc4, 10)
> failed: No such file or directory
> [ 25.085042] systemd-udevd[384]: inotify_add_watch(7, /dev/sdc2, 10)
> failed: No such file or directory
> [ 25.087052] systemd-udevd[381]: inotify_add_watch(7, /dev/sdc1, 10)
> failed: No such file or directory
>
>
> Runing partprobe:
>
> # partprobe
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF4
> failed: Device or resource busy
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF3
> failed: Device or resource busy
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF2
> failed: Device or resource busy
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF1
> failed: Device or resource busy
> Warning: parted was unable to re-read the partition table on
> /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF (Device or resource
> busy). This means Linux won't know anything about the modifications
> you
> made.
> device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF1
> failed: Device or resource busy
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF1
> failed: Device or resource busy
> device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF2
> failed: Device or resource busy
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF2
> failed: Device or resource busy
> device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF3
> failed: Device or resource busy
> device-mapper:remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF3
> failed: Device or resource busy
> device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF4
> failed: Device or resource busy
> device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF4
> failed: Device or resource busy
> device-mapper: remove ioctl on WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83p3
> failed: Device or resource busy
> Warning: parted was unable to re-read the partition table on
> /dev/mapper/WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83 (Device or resource
> busy). This means Linux won't know anything about the modifications
> you
> made.
> device-mapper: create ioctl on WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83p3
> failed: Device or resource busy
> device-mapper: remove ioctl on WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83p3
> failed: Device or resource busy
>
> So, whatmight be causing this?
>
> --
> users mailing list
> users(a)lists.fedoraproject.org
> 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
What's the output of lsblk?
It looks a bit like your using LVM
--
Junk
It seems this is not a new problem.
I see blogs and complaints about it in multiple distros.
And here we are in fc20, and the problem persists!
6:23 p.m.
New subject: mount shows mounted partition as /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
On 7 October 2014 21:52:05 GMT+01:00, jd1008 <jd1008(a)gmail.com> wrote:
# mount | grep sdc3
/dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3 on /sdc3 type ext4
(rw,relatime,journal_checksum)
So, how come I do not see it listed as I see /dev/sda3. To wit:
# mount | grep sda3
/dev/sda3 on / type ext4 (rw,relatime,data=ordered)
If I unmount /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
# umount /dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF3
and I try
# mount /dev/sdc3 /sdc3
mount: special device /dev/sdc3 does not exist
# grep sdc3 /etc/fstab
UUID=e64d7b94-1ffb-4a2e-ae59-5f8e54b6cab9 /sdc3 ext4
noauto,data=ordered,journal_checksum 3 3
# blkid /dev/sdc3
/dev/sdc3: UUID="e64d7b94-1ffb-4a2e-ae59-5f8e54b6cab9" TYPE="ext2"
PARTUUID="96e20bf8-03"
dmesg shows these errors:
[ 25.083098] systemd-udevd[385]: inotify_add_watch(7, /dev/sdc3, 10)
failed: No such file or directory
[ 25.084057] systemd-udevd[386]: inotify_add_watch(7, /dev/sdc4, 10)
failed: No such file or directory
[ 25.085042] systemd-udevd[384]: inotify_add_watch(7, /dev/sdc2, 10)
failed: No such file or directory
[ 25.087052] systemd-udevd[381]: inotify_add_watch(7, /dev/sdc1, 10)
failed: No such file or directory
Runing partprobe:
# partprobe
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF4
failed: Device or resource busy
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF3
failed: Device or resource busy
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF2
failed: Device or resource busy
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF1
failed: Device or resource busy
Warning: parted was unable to re-read the partition table on
/dev/mapper/HGST_HTS721010A9E630_JR10006P0BSEEF (Device or resource
busy). This means Linux won't know anything about the modifications
you
made.
device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF1
failed: Device or resource busy
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF1
failed: Device or resource busy
device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF2
failed: Device or resource busy
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF2
failed: Device or resource busy
device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF3
failed: Device or resource busy
device-mapper:remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF3
failed: Device or resource busy
device-mapper: create ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF4
failed: Device or resource busy
device-mapper: remove ioctl on HGST_HTS721010A9E630_JR10006P0BSEEF4
failed: Device or resource busy
device-mapper: remove ioctl on WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83p3
failed: Device or resource busy
Warning: parted was unable to re-read the partition table on
/dev/mapper/WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83 (Device or resource
busy). This means Linux won't know anything about the modifications
you
made.
device-mapper: create ioctl on WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83p3
failed: Device or resource busy
device-mapper: remove ioctl on WDC_WD20NPVX-00EA4T0_WD-WXV1E53KAE83p3
failed: Device or resource busy
So, whatmight be causing this?
--
users mailing list
users(a)lists.fedoraproject.org
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
What's the output of lsblk?
It looks a bit like your using LVM
--
Junk
4:53 a.m.
On Tue, 2014-10-07 at 21:02 -0600, jd1008 wrote:
The funny thing about it is the amazing silence of
the fedora devs (who also read this list), about this problem :)
AFAIK the devs tend to read the Test list and many don't read the Users
list. That said, take this to the Test list only if it also affects a
development version of Fedora or one of the tools.
poc
3492
days inactive
3498
days old
16 comments
7 participants
participants (7)
-
Bill Shirley -
Ed Greshko -
JD -
Junk -
Patrick O'Callaghan -
Ralf Corsepius -
Rick Stevens