Bug 1292921 - [BUG] /etc/xen/scripts/block remove fails - causes loopback exhaustion
[BUG] /etc/xen/scripts/block remove fails - causes loopback exhaustion
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Xen Maintainance List
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2015-12-18 13:31 EST by Bill Peck
Modified: 2017-04-18 17:59 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-04-18 17:59:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill Peck 2015-12-18 13:31:49 EST
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):

How reproducible:

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 @@
-        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.
Comment 1 Chris Williams 2017-04-18 17:59:48 EDT
Red Hat Enterprise Linux 5 shipped it's last minor release, 5.11, on September 14th, 2014. On March 31st, 2017 RHEL 5 exited Production Phase 3 and entered Extended Life Phase. For RHEL releases in the Extended Life Phase, Red Hat  will provide limited ongoing technical support. No bug fixes, security fixes, hardware enablement or root-cause analysis will be available during this phase, and support will be provided on existing installations only.  If the customer purchases the Extended Life-cycle Support (ELS), certain critical-impact security fixes and selected urgent priority bug fixes for the last minor release will be provided.  For more details please consult the Red Hat Enterprise Linux Life Cycle Page:

This BZ does not appear to meet ELS criteria so is being closed WONTFIX. If this BZ is critical for your environment and you have an Extended Life-cycle Support Add-on entitlement, please open a case in the Red Hat Customer Portal, https://access.redhat.com ,provide a thorough business justification and ask that the BZ be re-opened for consideration of an errata. Please note, only certain critical-impact security fixes and selected urgent priority bug fixes for the last minor release can be considered.

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