The /dev/dm-* device names are non-persistent device names used by the device-mapper subsystem. Alone, they are rather uninformative: running "dmsetup ls --tree" and comparing the device numbers (major:minor) to disk device nodes in /dev might help in identifying them.
There is a tweak that would make LVM use more informative device names: edit /etc/lvm/lvm.conf and find the "preferred_names" option. By default the list of preferred device names is empty, but there should be an example configuration line with a comment like "Try to avoid using undescriptive /dev/dm-N names". Comment out the empty default, and uncomment the example line. Then run "vgscan" to refresh the LVM metadata cache. Now run "pvs" again to hopefully get a more informative result.
Looks like the VolGroup15 is not active, yet the system is trying to run fsck on it.
Is this system part of a cluster?
The "_netdev" option tells the system "this filesystem requires network to be operational before it can be activated", which is important if VG activation depends on cluster-wide locks.
Normally the system tries to automatically activate all the VGs it sees, before starting to run file system checks. So something may have caused the activation of VolGroup15 to fail.
You might want to run "vgchange -a y VolGroup15". If the automatic activation failed, this will probably fail too, but it should display a helpful error message in that case. For example, this VG might contain more than one PV.
If the manual VG activation is successful, then I guess your system startup script might just have gone ahead faster than the SAN LUN discovery could complete. If that's the case, inserting a short delay to the FC driver loading procedure might help.
If your server really is RHEL 5.0 (i.e. no updates installed since RHEL 5 original release), then I'd strongly suggest upgrading to RHEL 5.4. There has been several kernel, LVM and dm-multipath updates to improve SAN functionality.
MK
MK
