Bug 138487 - /dev/mapper/control incorrect after module load: Inappropriate ioctl for device
/dev/mapper/control incorrect after module load: Inappropriate ioctl for device
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: device-mapper (Show other bugs)
4.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Alasdair Kergon
Cluster QE
: FutureFeature
Depends On:
Blocks: 143501
  Show dependency treegraph
 
Reported: 2004-11-09 11:07 EST by Corey Marthaler
Modified: 2010-01-11 21:14 EST (History)
0 users

See Also:
Fixed In Version: RHBA-2005-192
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-24 09:52:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Corey Marthaler 2004-11-09 11:07:45 EST
Description of problem:
I have my cluster in a state where a simple lvcreate will fail:

[root@morph-03 root]# lvcreate -l 408 joe
  device-mapper ioctl cmd 0 failed: Inappropriate ioctl for device
  striped: Required device-mapper target(s) not detected in your kernel
  lvcreate: Create a logical volume
  .
  .
  .

dm-mod is loaded, clvmd is happy on all nodes:

[root@morph-03 root]# cat /proc/cluster/services
Service          Name                              GID LID State     Code
Fence Domain:    "default"                           1   2 run       -
[1 3 4 2 5]

DLM Lock Space:  "clvmd"                             2   3 run       -
[1 3 4 2 5]

[root@morph-03 root]# vgdisplay
  --- Volume group ---
  VG Name               joe
  System ID
  Format                lvm2
  Metadata Areas        4
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                4
  Act PV                4
  VG Size               1.59 TB
  PE Size               4.00 GB
  Total PE              408
  Alloc PE / Size       0 / 0
  Free  PE / Size       408 / 1.59 TB
  VG UUID               5mJF1h-dTDx-Or11-J0LS-HiK1-O5av-rRgWiR

root@morph-03 root]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda1
  VG Name               joe
  PV Size               408.00 GB / not usable 0
  Allocatable           yes
  PE Size (KByte)       4194304
  Total PE              102
  Free PE               102
  Allocated PE          0
  PV UUID               oRrGio-aYnh-cOfV-n3eP-HoSJ-ShT1-ETQruo

  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               joe
  PV Size               408.00 GB / not usable 0
  Allocatable           yes
  PE Size (KByte)       4194304
  Total PE              102
  Free PE               102
  Allocated PE          0
  PV UUID               nZPSpY-MvE3-YXGT-w6ly-3yps-Mgl8-nDcV8w

  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               joe
  PV Size               408.00 GB / not usable 0
  Allocatable           yes
  PE Size (KByte)       4194304
  Total PE              102
  Free PE               102
  Allocated PE          0
  PV UUID               LF5iSJ-zdS4-x57N-WkND-22Qw-iif3-BjmD04

  --- Physical volume ---
  PV Name               /dev/sda5
  VG Name               joe
  PV Size               408.00 GB / not usable 0
  Allocatable           yes
  PE Size (KByte)       4194304
  Total PE              102
  Free PE               102
  Allocated PE          0
  PV UUID               Eu1Cdj-RuKB-iVaj-o30f-TM7g-T53a-QV4RvV



How reproducible:
Sometimes
Comment 1 Christine Caulfield 2004-11-10 11:12:20 EST
Just a wild guess, have you checked that the device-mapper char device
has the right minor number. This could be related to #138491
Comment 2 Corey Marthaler 2004-11-10 17:43:16 EST
they are the exact same major/minor:
[root@morph-01 mapper]# ls -l /dev/misc/dlm-control
crw-------  1 root root 10, 63 Nov 10 16:07 /dev/misc/dlm-control
[root@morph-01 mapper]# ls -l /dev/mapper/control
crw-------  1 root root 10, 63 Nov 10 14:55 /dev/mapper/control

What should they be?
Comment 3 Alasdair Kergon 2004-11-16 11:56:46 EST
They're dynamic - can change on each boot and should be recreated in
init scripts (or after module load with a post-install trigger, if
you're using device-mapper as a module).  See INSTALL,
scripts/devmap_mknod.sh, /proc/devices & /proc/misc.
Comment 4 Corey Marthaler 2004-11-16 17:26:00 EST
We were able to work around this by always removing
/dev/mapper/control before we load the dm_mod and then running
scripts/devmap_mknod.sh afterwards as suggested. 

How is this going to be delievered to the customer? Are they going to
have access to scripts/devmap_mknod.sh and have to run it if they get
into this problem?

It's probably a good idea for the modprobe of dm_mod to just always
run scripts/devmap_mknod.sh afterward, rather than just when
/dev/mapper/control doesn't exist, that way one shouldn't get into the
senario where the major/minor numbers are out of sync. 

Comment 5 Alasdair Kergon 2004-11-19 08:57:26 EST
The LVM2 INSTALL instructions have always explained how to do this.

If that isn't happening properly, we need to work out which RPM is
supposed to take responsibility for installing scripts - whichever
one installs the kernel module or module utilities maybe - and get
it fixed.
Comment 6 Alasdair Kergon 2005-01-05 17:38:58 EST
OK.  The resolution for this one is going to be to perform the
function of devmap_mknod.sh transparently from inside libdevmapper
whenever an attempt to access /dev/mapper/control fails.  That's
probably more resilient than connecting it to module load/unload, even
though it's more work.
Comment 7 Alasdair Kergon 2005-01-06 13:47:46 EST
patch included in dm 1.00.20

Note You need to log in before you can comment on or make changes to this bug.