Description of problem:
When a guest is rebooted or powered down /etc/xen/scripts/block is called.  When using file: as the backend file device loopback devices are used.  When called with remove it should remove the loopback device that was setup with block add.  90% of the time this fails because the information from

         node=$(xenstore_read "$XENBUS_PATH/node")

does not return any information.  I believe the problem is the claim_lock delays execution long enough that the information from xenstore_read is no longer available.

Version-Release number of selected component (if applicable):
3.0.3-142.el5_9.3

How reproducible:
90%

Steps to Reproduce:
1. Install an hvm guest using a backend file:
2. reboot the guest several times
3. losetup -a

Actual results:

You will have multiple /dev/loop entries 

Expected results:

Only one loopback device should be used (2 if .iso is attached).


Additional info:
anaconda-ks.cfg  install.log  install.log.syslog  NETBOOT_METHOD.TXT  patch.diff  RECIPE.TXT  xen
[root@amd-dinar-09 ~]# more patch.diff 
--- etc/xen/scripts/block	2015-12-18 13:18:51.000000000 -0500
+++ /etc/xen/scripts/block	2015-12-18 13:18:21.000000000 -0500
@@ -303,8 +303,8 @@
 	;;
 
       file)
-        claim_lock "block"
         node=$(xenstore_read "$XENBUS_PATH/node")
+        claim_lock "block"
 	losetup -d "$node"
         release_lock "block"
 	exit 0


This "fix" still doesn't feel right.  It seems to me that the data from xenstore_read should not go away while these scripts are running.  But this change makes things work for every time I've run it.

I've set severity to high since this can cause testing to fail when all loopback devices are exhausted.