Bug 1171933

Generated patches for upstream :

http://www.redhat.com/archives/libvir-list/2015-March/msg01562.html

The third patch resolves the issue generates the following message:

$ virsh pool-create iscsi-lcl-pool.xml
error: Failed to create pool from iscsi-lcl-pool.xml
error: invalid argument: No LUs found for pool 'iscsi-lcl-pool' target path '/tmp/iscsi' not found

$

Changes were required - posted new series:

http://www.redhat.com/archives/libvir-list/2015-April/msg00050.html

Now you'd get:

$ virsh pool-start iscsi-lcl-pool
error: Failed to start pool iscsi-lcl-pool
error: invalid argument: Non stable target path '/tmp/iscsi' not found for pool 'iscsi-lcl-pool'

$

if the /tmp/iscsi path didn't exist at startup... if it did exist and the pool was empty after trying, then the following would occur:

$ mkdir /tmp/iscsi
$ virsh pool-start iscsi-lcl-pool
error: Failed to start pool iscsi-lcl-pool
error: invalid argument: Non stable target path '/tmp/iscsi' for pool 'iscsi-lcl-pool' found no target volumes

$

After another round of reviews, changes have been pushed upstream:

$ git describe 9832205263d5e3adefc49fe05422db6732409d81
v1.2.14-246-g9832205
$ git show
commit 9832205263d5e3adefc49fe05422db6732409d81
Author: John Ferlan <jferlan>
Date:   Mon Mar 30 18:55:16 2015 -0400

    scsi: Adjust return values from processLU
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1171933
    
    Adjust the processLU error returns to be a bit more logical. Currently,
    the calling code cannot determine the difference between a non disk/lun
    volume and a processed/found disk/lun. It can also not differentiate
    between perhaps real/fatal error and one that won't necessarily stop
    the code from finding other volumes.
    
    After this patch virStorageBackendSCSIFindLUsInternal will stop processing
    as soon as a "fatal" message occurs rather than continuting processing
    for no apparent reason. It will also only set the *found value when
    at least one of the processLU's was successful.
    
    With the failed return, if the reason for the stop was that the pool
    target path did not exist, was /dev, was /dev/, or did not start with
    /dev, then iSCSI pool startup and refresh will fail.

Hi John, 
The reporter said at last:
=====================================================
YangYang found:

The issue is also reproduced in scsi/fc pool startup
=====================================================

I tried with latest libvirt versoin:
libvirt-1.2.15-2.el7.x86_64

[root@localhost ~]# virsh pool-list
 Name                 State      Autostart 
-------------------------------------------
 boot-scratch         active     yes       
 default              active     yes       
 home                 active     yes       
 host6                active     no        

[root@localhost ~]# virsh pool-dumpxml host6
<pool type='scsi'>
  <name>host6</name>
  <uuid>b5abd61d-5791-4483-9c74-571fe4619357</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <adapter type='scsi_host' name='host6'/>
  </source>
  <target>
    <path>/tmp</path>   <=== not /dev /dev/ or a stable path. 
    <permissions>
      <mode>0755</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>

Pls confirm if more modification required.

For type='iscsi' pool, it's working well now.

I found libvirt should also check target path for disk and mpath pool .
For volume in disk pool , it is always created in /dev directory as default; For volume in mpath pool , it is always created in /dev/mapper/ or /dev/ directory as default. 

1.define and start disk pool 
# virsh pool-dumpxml disk-pool
<pool type='disk'>
  <name>disk-pool</name>
  <uuid>48e96788-fd6b-413d-83bf-a644790553e4</uuid>
  <capacity unit='bytes'>16014620160</capacity>
  <allocation unit='bytes'>2148499968</allocation>
  <available unit='bytes'>13866087936</available>
  <source>
    <device path='/dev/sdb'>
      <freeExtent start='2148532224' end='16014620160'/>
    </device>
    <format type='unknown'/>
  </source>
  <target>
    <path>/tmp</path>
  </target>
</pool>

2.check volume in disk pool 
# virsh vol-list disk-pool
 Name                 Path                                    
------------------------------------------------------------------------------
 sdb1                 /dev/sdb1                               
 sdb2                 /dev/sdb2                               
 sdb3                 /dev/sdb3 

2.define and start a mpath pool

# virsh pool-dumpxml  mpathp
<pool type='mpath'>
  <name>mpathp</name>
  <uuid>46920cb4-98e5-484f-a4e8-62582ed376da</uuid>
  <capacity unit='bytes'>32218696704</capacity>
  <allocation unit='bytes'>32218696704</allocation>
  <available unit='bytes'>0</available>
  <source>
  </source>
  <target>
    <path>/dev/by-path</path>
  </target>
</pool>


# virsh vol-list  mpathp
 Name                 Path                                    
------------------------------------------------------------------------------
 dm-3                 /dev/mapper/3600a0b80005adb0b0000ab2d4cae9254
 dm-9                 /dev/mapper/3600a0b80005ad1d700002ddc4fa32c87

w/r/t scsi/fc:
scsi/fc/iscsi all share the code the process the stable path. Does the virsh-vol list show anything in that fc pool? Could there be "other" issues with the fc pool that prevent finding luns (see bz 1224233) so that need for a stable path doesn't exist?  IOW: If we don't find any luns, then there's no reason to find their stable path.

BTW: Resolution of this bug does not depend on that question being resolved since this bug is about iscsi and your question is about the fc pool.

w/r/t /dev/mapper:
Separate backend, but it seems to ignore the target.path value and provides it's own based on what's shown in the output when the pool is running.

(In reply to John Ferlan from comment #8)
> w/r/t scsi/fc:
> scsi/fc/iscsi all share the code the process the stable path. Does the
> virsh-vol list show anything in that fc pool? Could there be "other" issues
> with the fc pool that prevent finding luns (see bz 1224233) so that need for
> a stable path doesn't exist?  IOW: If we don't find any luns, then there's
> no reason to find their stable path.
> 
> BTW: Resolution of this bug does not depend on that question being resolved
> since this bug is about iscsi and your question is about the fc pool.
> 
> w/r/t /dev/mapper:
> Separate backend, but it seems to ignore the target.path value and provides
> it's own based on what's shown in the output when the pool is running.

Hi John, 
Actually my scsi pool is not a fc pool, i used a usb disk for testing. 
Following is the test result for both scsi and fc pool. Seems when target path is unstable, both pools can be created anyway. 

tested with libvirt-1.2.16-1.el7.x86_64


=================================================================
scsi pool
=================================================================
# lsscsi
...
[6:0:0:0]    disk    SanDisk  Cruzer Blade     1.26  /dev/sdb

CORRECT TARGET DIR SCENARIO:
1. # cat scsipool.xml
<pool type='scsi'>
  <name>host6</name>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <adapter type='scsi_host' name='host6'/>
  </source>
  <target>
    <path>/dev/disk/by-path/</path>   
    <permissions>
      <mode>0755</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>


2. # virsh pool-create scsipool.xml
Pool host6 created from scsipool.xml

3. # virsh vol-list host6
 Name                 Path                                    
------------------------------------------------------------------------------
 unit:0:0:0           /dev/disk/by-path/pci-0000:00:1a.0-usb-0:1.4:1.0-scsi-0:0:0:0

INCORRECT TARGET DIR SCENARIO:
1. # cat scsipool.xml
<pool type='scsi'>
  <name>host6</name>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <adapter type='scsi_host' name='host6'/>
  </source>
  <target>
    <path>/nowhere</path>    <!-- dir which does not exist  -->
    <permissions>
      <mode>0755</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>


2. # virsh pool-create scsipool.xml   <=== no error produced with invalid path
Pool host6 created from scsipool.xml

3. # virsh vol-list host6
 Name                 Path                                    
------------------------------------------------------------------------------


=================================================================
fc pool (tested with your fix of bz 1224233) 
=================================================================
CORRECT TARGET DIR SCENARIO:
1. # cat fc_pool.xml
<pool type='scsi'>
    <name>fc_pool</name>
    <source>
        <adapter type='fc_host' parent='scsi_host5'  wwnn='2101001b32a90002' wwpn='2101001b32a90002'/>
    </source>
    <target>
        <path>/dev/disk/by-path/</path>
        <permissions>
          <mode>0755</mode>
          <owner>-1</owner>
          <group>-1</group>
        </permissions>
    </target>
</pool>

2. # virsh pool-create fc_pool.xml
Pool fc_pool created from fc_pool.xml
3. # virsh vol-list fc_pool
 Name                 Path                                    
------------------------------------------------------------------------------
 unit:0:2:0           /dev/disk/by-path/pci-0000:04:00.1-fc-0x203600a0b85b5dd4-lun-0


INCORRECT TARGET DIR SCENARIO:
1. # cat fc_pool.xml
<pool type='scsi'>
    <name>fc_pool</name>
    <source>
        <adapter type='fc_host' parent='scsi_host5'  wwnn='2101001b32a90002' wwpn='2101001b32a90002'/>
    </source>
    <target>
        <path>/nowhere</path>
        <permissions>
          <mode>0755</mode>
          <owner>-1</owner>
          <group>-1</group>
        </permissions>
    </target>
</pool>

2. # virsh pool-create fc_pool.xml
Pool fc_pool created from fc_pool.xml

3. # virsh vol-list fc_pool
 Name                 Path                                    
------------------------------------------------------------------------------

While I don't have similar resources for setting up some sort of "valid" pool - I was able to use my scsi_host1 (which ends up being a DVD drive) in order to create a pool using your example.  When I change to a bad path with my debug session running I get:

2015-06-23 18:26:55.397+0000: 15016: error : virStorageBackendSCSINewLun:183 : invalid argument: unable to use target path '/nowhere' for dev 'sr0'

But yet the pool is started.  That's because the SCSI path ignored the error in virStorageBackendSCSIRefreshPool (see what I get for assuming and not looking).

It's a simple change and I posted a fix for this already:

http://www.redhat.com/archives/libvir-list/2015-June/msg01186.html

If it doesn't reviewed/accepted for this upstream libvirt release cycle (end of the month code freeze), then I'd need a new bug; otherwise, I'll push through to get it accepted for SCSI and SCSI/FC.

Since the issue is fixed for 'iSCSI', then I would think this particular bug is resolved though.

(In reply to John Ferlan from comment #10)
> While I don't have similar resources for setting up some sort of "valid"
> pool - I was able to use my scsi_host1 (which ends up being a DVD drive) in
> order to create a pool using your example.  When I change to a bad path with
> my debug session running I get:
> 
> 2015-06-23 18:26:55.397+0000: 15016: error : virStorageBackendSCSINewLun:183
> : invalid argument: unable to use target path '/nowhere' for dev 'sr0'
> 
> But yet the pool is started.  That's because the SCSI path ignored the error
> in virStorageBackendSCSIRefreshPool (see what I get for assuming and not
> looking).
> 
> It's a simple change and I posted a fix for this already:
> 
> http://www.redhat.com/archives/libvir-list/2015-June/msg01186.html
> 
> If it doesn't reviewed/accepted for this upstream libvirt release cycle (end
> of the month code freeze), then I'd need a new bug; otherwise, I'll push
> through to get it accepted for SCSI and SCSI/FC.
> 
> Since the issue is fixed for 'iSCSI', then I would think this particular bug
> is resolved though.

Yes, in the debug log, I can find same errors for scsi(cdrom/usb disk) and fc
# tailf /var/log/libvirtd-debug.log  | grep -i error
2015-06-24 10:46:06.547+0000: 2967: error : virStorageBackendSCSINewLun:183 : invalid argument: unable to use target path '/nowhere' for dev 'sr0'
2015-06-24 10:46:33.737+0000: 2967: error : virStorageBackendSCSINewLun:183 : invalid argument: unable to use target path '/nowhere' for dev 'sr0'
2015-06-24 10:47:02.161+0000: 2966: error : virStorageBackendSCSINewLun:183 : invalid argument: unable to use target path '/nowhere' for dev 'sdb'
2015-06-24 10:52:32.791+0000: 7347: error : virStorageBackendSCSINewLun:183 : invalid argument: unable to use target path '/nowhere' for dev 'sdg'


If you want to use current bug to track the fc/scsi pools' issues, pls assign it back to you for now then you may not ignore it in future. If you think a new bug is required, please let me know and I'll create a new bug to track it.

This bug is about the "iscsi" pool. The "scsi" pool has different sources (although they share the stable path validation API). The 'scsi' pool just didn't fail when the API returned a -1.

In any case, my upstream patch was accepted and has been pushed, so I won't ignore it and it will be in the libvirt version which will become the basis for the next RHEL release:


commit 1b695be173356d720bbc3de96bf0208ca7d531f0
Author: John Ferlan <jferlan>
Date:   Tue Jun 23 14:40:31 2015 -0400

    scsi: Force error for SCSI pools on virStorageBackendSCSIFindLUs failure
    
    Related to :
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1171933
    
    Rather than ignore the return status from virStorageBackendSCSIFindLUs,
    cause a failure to start the pool if a -1 is returned. Issue was noted
    during testing of the bz for iscsi that 'scsi' and 'fc' pools don't fail.

diff --git a/src/storage/storage_backend_scsi.c b/src/storage/storage_backend_scsi.c
index b426145..a593a2b 100644
--- a/src/storage/storage_backend_scsi.c
+++ b/src/storage/storage_backend_scsi.c
@@ -935,7 +935,8 @@ virStorageBackendSCSIRefreshPool(virConnectPtr conn ATTRIBUTE_UNUSED,
     if (virStorageBackendSCSITriggerRescan(host) < 0)
         goto out;
 
-    ignore_value(virStorageBackendSCSIFindLUs(pool, host));
+    if (virStorageBackendSCSIFindLUs(pool, host) < 0)
+        goto out;
 
     ret = 0;
  out:


If you decide to create a new bug to address the scsi pool directly, it will only need to be a "test only" type case.

(In reply to John Ferlan from comment #12)
> This bug is about the "iscsi" pool. The "scsi" pool has different sources
> (although they share the stable path validation API). The 'scsi' pool just
> didn't fail when the API returned a -1.
> 
> In any case, my upstream patch was accepted and has been pushed, so I won't
> ignore it and it will be in the libvirt version which will become the basis
> for the next RHEL release:
> 
> 
> commit 1b695be173356d720bbc3de96bf0208ca7d531f0
> Author: John Ferlan <jferlan>
> Date:   Tue Jun 23 14:40:31 2015 -0400
> 
>     scsi: Force error for SCSI pools on virStorageBackendSCSIFindLUs failure
>     
>     Related to :
>     
>     https://bugzilla.redhat.com/show_bug.cgi?id=1171933
>     
>     Rather than ignore the return status from virStorageBackendSCSIFindLUs,
>     cause a failure to start the pool if a -1 is returned. Issue was noted
>     during testing of the bz for iscsi that 'scsi' and 'fc' pools don't fail.
> 
> diff --git a/src/storage/storage_backend_scsi.c
> b/src/storage/storage_backend_scsi.c
> index b426145..a593a2b 100644
> --- a/src/storage/storage_backend_scsi.c
> +++ b/src/storage/storage_backend_scsi.c
> @@ -935,7 +935,8 @@ virStorageBackendSCSIRefreshPool(virConnectPtr conn
> ATTRIBUTE_UNUSED,
>      if (virStorageBackendSCSITriggerRescan(host) < 0)
>          goto out;
>  
> -    ignore_value(virStorageBackendSCSIFindLUs(pool, host));
> +    if (virStorageBackendSCSIFindLUs(pool, host) < 0)
> +        goto out;
>  
>      ret = 0;
>   out:
> 
> 
> If you decide to create a new bug to address the scsi pool directly, it will
> only need to be a "test only" type case.

Hi John, it's not me who'd like an extra bug  ~_~ the reporter explicitly mentioned scsi/fc pool as "The issue is also reproduced in scsi/fc pool startup"
So current fix in libvirt 1.2.16-1 is not fully satisfied reporter's bug report. I cannot just set this bug "verified" if not everything mentioned by reporter is fully covered by test. Would you please move the issue to next libvirt version, thanks.

Hm... re-read the description - it goes through in detail all about iscsi, then as almost an addendum - it's noted it's also reproduced in scsi/fc, which I missed. As painful as it can be, there is a reason why there is a desire to have separate bugs for issues found in each of the various storage drivers. While scsi, iscsi, and fc do share some code, there are enough differences to very easily overlook such a comment that has a fully described iscsi issue. 

So, I'll just place back in POST now since the code is upstream.

verified on libvirt 1.2.17-1.el7.x86_64


=================================================================
iscsi pool
=================================================================
CORRECT TARGET DIR SCENARIO:
1. #cat iscsipool.xml
<pool type='iscsi'>
  <name>test-iscsi</name>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <host name='xxx' port='3260'/>
    <device path='xxx'/>
  </source>
  <target>
    <path>/dev/disk/by-id</path>
    <permissions>
      <mode>0755</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>

2. # virsh pool-create iscsipool.xml 
Pool test-iscsi created from iscsipool.xml

3. # virsh vol-list test-iscsi
 Name                 Path                                    
------------------------------------------------------------------------------
 unit:0:0:1           /dev/disk/by-id/scsi-1IET_00010001      
 unit:0:0:2           /dev/disk/by-id/scsi-1IET_00010002      
 unit:0:0:3           /dev/disk/by-id/scsi-1IET_00010003      
 unit:0:0:4           /dev/disk/by-id/scsi-1IET_00010004      
 unit:0:0:5           /dev/disk/by-id/scsi-1IET_00010005      


INCORRECT TARGET DIR SCENARIO:
1. # cat iscsipool.xml 
<pool type='iscsi'>
  <name>test-iscsi</name>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <host name='xxx' port='3260'/>
    <device path='xxx'/>
  </source>
  <target>
    <path>/nowhere</path>
    <permissions>
      <mode>0755</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>

2. # virsh pool-create iscsipool.xml 
error: Failed to create pool from iscsipool.xml
error: invalid argument: unable to use target path '/nowhere' for dev 'sdf'

3. # virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
<===  pool not created as expected

4. # lsscsi
[0:0:0:0]    disk    ATA      WDC WD2502ABYS-1 3B04  /dev/sda 
[1:0:0:0]    disk    IBM      1726-4xx  FAStT  0617  /dev/sdb 
[1:0:1:0]    disk    IBM      1726-4xx  FAStT  0617  /dev/sdc 
[1:0:2:0]    disk    IBM      1726-4xx  FAStT  0617  -        
[1:0:3:0]    disk    IBM      1726-4xx  FAStT  0617  -        
[3:0:0:0]    cd/dvd  PLDS     DVD-ROM DH-16D3S SD11  /dev/sr0 
[5:0:0:0]    disk    IBM      1726-4xx  FAStT  0617  -        
[5:0:1:0]    disk    IBM      1726-4xx  FAStT  0617  -        
[5:0:2:0]    disk    IBM      1726-4xx  FAStT  0617  /dev/sdd 
[5:0:3:0]    disk    IBM      1726-4xx  FAStT  0617  /dev/sde 
<===== no iscsi disk attached as expected. 



=================================================================
scsi pool
=================================================================
# lsscsi
...
[6:0:0:0]    disk    SanDisk  Cruzer Blade     1.26  /dev/sdb

CORRECT TARGET DIR SCENARIO:
1. # cat scsipool.xml
<pool type='scsi'>
  <name>host6</name>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <adapter type='scsi_host' name='host6'/>
  </source>
  <target>
    <path>/dev/disk/by-path/</path>   
    <permissions>
      <mode>0755</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>


2. # virsh pool-create scsipool.xml
Pool host6 created from scsipool.xml

3. # virsh vol-list host6
 Name                 Path                                    
------------------------------------------------------------------------------
 unit:0:0:0           /dev/disk/by-path/pci-0000:00:1a.0-usb-0:1.4:1.0-scsi-0:0:0:0

INCORRECT TARGET DIR SCENARIO:
1. # cat scsipool.xml
<pool type='scsi'>
  <name>host6</name>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <adapter type='scsi_host' name='host6'/>
  </source>
  <target>
    <path>/nowhere</path>    <!-- dir which does not exist  -->
    <permissions>
      <mode>0755</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>


2. # virsh pool-create scsipool.xml   
rror: Failed to create pool from scsipool.xml
error: invalid argument: unable to use target path '/nowhere' for dev 'sdb'


3. # virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
<=== pool not created as expected. 

=================================================================
fc pool 
=================================================================
CORRECT TARGET DIR SCENARIO:
1. # cat fc_pool.xml
<pool type='scsi'>
    <name>fc_pool</name>
    <source>
        <adapter type='fc_host' parent='scsi_host5'  wwnn='2101001b32a90002' wwpn='2101001b32a90002'/>
    </source>
    <target>
        <path>/dev/disk/by-path/</path>
        <permissions>
          <mode>0755</mode>
          <owner>-1</owner>
          <group>-1</group>
        </permissions>
    </target>
</pool>

2. # virsh pool-create fc_pool.xml
Pool fc_pool created from fc_pool.xml
3. # virsh vol-list fc_pool
 Name                 Path                                    
------------------------------------------------------------------------------
 unit:0:2:0           /dev/disk/by-path/pci-0000:04:00.1-fc-0x203600a0b85b5dd4-lun-0


INCORRECT TARGET DIR SCENARIO:
1. # cat fc_pool.xml
<pool type='scsi'>
    <name>fc_pool</name>
    <source>
        <adapter type='fc_host' parent='scsi_host5'  wwnn='2101001b32a90002' wwpn='2101001b32a90002'/>
    </source>
    <target>
        <path>/nowhere</path>
        <permissions>
          <mode>0755</mode>
          <owner>-1</owner>
          <group>-1</group>
        </permissions>
    </target>
</pool>

# virsh pool-create fc_pool.xml 
error: Failed to create pool from fc_pool.xml
error: invalid argument: unable to use target path '/nowhere' for dev 'sdf'


3. # virsh vol-list fc_pool
 Name                 Path                                    
------------------------------------------------------------------------------
<=== fc_pool not created

4.  #lsscsi  <== san disk not connected. 
[0:0:0:0]    disk    ATA      WDC WD2502ABYS-1 3B04  /dev/sda 
[1:0:0:0]    disk    IBM      1726-4xx  FAStT  0617  /dev/sdb 
[1:0:1:0]    disk    IBM      1726-4xx  FAStT  0617  /dev/sdc 
[1:0:2:0]    disk    IBM      1726-4xx  FAStT  0617  -        
[1:0:3:0]    disk    IBM      1726-4xx  FAStT  0617  -        
[3:0:0:0]    cd/dvd  PLDS     DVD-ROM DH-16D3S SD11  /dev/sr0 
[5:0:0:0]    disk    IBM      1726-4xx  FAStT  0617  -        
[5:0:1:0]    disk    IBM      1726-4xx  FAStT  0617  -        
[5:0:2:0]    disk    IBM      1726-4xx  FAStT  0617  /dev/sdd 
[5:0:3:0]    disk    IBM      1726-4xx  FAStT  0617  /dev/sde

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html