Bug 1292921
| Summary: | [BUG] /etc/xen/scripts/block remove fails - causes loopback exhaustion | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Bill Peck <bpeck> |
| Component: | xen | Assignee: | Xen Maintainance List <xen-maint> |
| Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.11 | CC: | agordeev, dhoward, jburke, jstancek, pbunyan, xen-maint |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-04-18 21:59:48 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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: https://access.redhat.com/support/policy/updates/errata 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. |
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.