lvm issues kernel not updated, can't lock the new device.

[Steven E. Protter]

RH 4.4 RHCS 4.4 GFS with clvmd
stock smp kernel
I use fdisk to create a new partition on shared storage.
fdisk reports that the kernel is not updated.

No problem right, just run partprobe.

Partprobe does nothing.

lvcreate does an error:
pvcreate works without protest
vgcreate works without protest.
lvcreate -L +1G vgsep

Error locking on node golan2: Internal lvm error, check syslog
Failed to activate new LV.

This is what the lvscan looks like:

inactive '/dev/vgsep/lvol0' [1.00 GB] inherit
inactive '/dev/vgsep/lvol1' [1.00 GB] inherit
ACTIVE '/dev/vgsch/lvol0' [1.00 GB] inherit
ACTIVE '/dev/vgssr/lvol0' [1.00 GB] inherit
ACTIVE '/dev/vg00/vg00' [4.00 GB] inherit
ACTIVE '/dev/vg00/lvol4' [1.00 GB] inherit
ACTIVE '/dev/vg00/lvol3' [4.00 GB] inherit
ACTIVE '/dev/vg00/lvol5' [4.00 GB] inherit
ACTIVE '/dev/vg00/lv02' [8.00 GB] inherit

If I boot the logical volumes are marked ACTIVE and all is well.

The issue is I'm trying to help with quality control on a script that creates the partitions, volume groups and logical volumes. We dont want to reboot because the script loses control. Yes we could script it to finish after boot but thats disruptive.

How do I kick the kernel in the can and get it to accept the update?

What I've tried:
pvscan
re-running fdisk

SEP

[Steven E. Protter]

Device files are not created in /dev/mapper

I want to force that process.

fdisk warned.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.

partprobe did not help.

SEP

[Steven E. Protter]

Update:

The error from fdisk can be avoided by not mounting anything on the shared storage until completion of fdisk. This apparently triggers the bug.

Once the bug has occurred the kernel can't lock the lvm and we're pretty much done.

Testing the following plan.

Complete all fdisk work, which totally breaks the script I'm doing Q&A on and then see how well partitioning works after that.

Have confirmed the problem does not occur under non-lvm.

Update shortly.

SEP

[Steven E. Protter]

Shalom,

This is clearly an lvm/clvmd issue.

If you do parted/fdisk work all at once instead of sequentially like the script does it works out nicely.

Once you trigger a failed kernel read of the partition table you are done.

This being a clustered installation we can't just upgrade the kernel because this has been proven to destroy clustering functionality, especially on DL380 servers.

I see no patches available either.

SEP