Bug 138487

Summary:	/dev/mapper/control incorrect after module load: Inappropriate ioctl for device
Product:	Red Hat Enterprise Linux 4	Reporter:	Corey Marthaler <cmarthal>
Component:	device-mapper	Assignee:	Alasdair Kergon <agk>
Status:	CLOSED ERRATA	QA Contact:	Cluster QE <mspqa-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	Keywords:	FutureFeature
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:	RHBA-2005-192	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-05-24 13:52:40 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	143501

Description Corey Marthaler 2004-11-09 16:07:45 UTC

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 16:12:20 UTC

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 22:43:16 UTC

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 16:56:46 UTC

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 22:26:00 UTC

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 13:57:26 UTC

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 22:38:58 UTC

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 18:47:46 UTC

patch included in dm 1.00.20