There will be other messages of relevance in the log - please attach the whole thing (use the Advanced Editor to get the Attach option)
The underlying reason the deploy failed:
12/06/15 20:43:01.353 INFO bldeploy - [New RPM Group] [stdout: 2] Running yum from /var/tmp/stage/61e85a7c138430629231644f8ceae152 and yum used is blyum... 12/06/15 20:44:02.993 WARN bldeploy - [New RPM Group] [stderr: 2]
Error Downloading Packages:
rp-pppoe-3.10-11.el6.x86_64: Caching enabled but no local cache of //var/tmp/stage/61e85a7c138430629231644f8ceae152/blrepos/repo/packages/rp-pppoe-3.10-11.el6.x86_64.rpm from repo
12/06/15 20:44:03.040 INFO bldeploy - [New RPM Group] [stdout: 2] yum deploy failed.
If you cannot determine the solution form this information, and no-one else can contribute on the communities, you should open a support case
you may need to enable the keepcache=1 option in the /etc/yum.conf configuration file on target server to avoid the caching errors and try to execute job.
please explain how will adding the keepcache=1 help ?
what version of bsa is this ? this is likely related to a defect w/ the include list handing where rpms are included in the include list and yum commands but the corresponding payload is not present in the catalog or not added to the deploy package from bsa during remediation.
yum updates the header files and always download the headers, even if we are installing the package multiple times. To avoid redundancy, we can enable header and package file caching. To do so, we need to enable the keepcache=1 option in the /etc/yum.conf configuration file and then call yum with the -C option, yum will access the cache regardless of the /etc/yum.conf settings. Of course, this will only work if you really do have the required resources in the cache. If resources are missing, yum will give you the message Caching enabled but no local cache type of errors.
when using yum via bsa, is any of what you said true ?
that's not about BSA. its all about target server.
The customer is using BSA 86 SP1 build 66.
Also, can we check if the RPM "rp-pppoe-3.10-11.el6.x86_64" is present in the catalog and is not a part of irrelevant patches.
We have seen issues in the past where some patches are removed to irrelevant patches after filters were modified on an existing catalog.
We can also have a look at a filters that are used while creating the catalog and also verify if a change was made recently or not
why is it not about bsa? this is a deploy job, generated by bsa, from a redhat patching job right ?
correct. But if the keepcache=0 is set on target server and the same job will fail on target server as well when they run manually. That's why we need to enable keepcache=1 to avoid the cache errors.
you clearly have no idea how bsa works.
during the deploy job that's based on patching results the following happens:
- a copy of the repo (patch catalog) metadata is copied over to the target
- a custom yum.conf file is generated that points to the copy of the repo metadata
- the rpm payloads identified as missing by the analysis job are copied to the target
- if an include list was used during the analysis that is generated for the deploy
- blyum is called (which is bsa's version of yum) using the generated yum.conf - using the -C (cache) option since there is not actually a yum repo available via http/nfs/ftp/etc - and any include list is passed.
so using the 'keepcache' will do nothing here because we are already using the cache. the problem here is that one or more packages are mentioned in the include list but they are not present on the target.
typically this happens because the rpm file is present on the repo file system and include in the repo metadata but flagged as irrelevant in the catalog or was removed from the catalog. there are a couple defects that cause this - one is related to the deploy include list not being pruned properly (to only include the latest version of the rpm in the include list) and another is due to the filter options causing the rpm to be tagged as irrelevant incorrectly. there may be a couple other causes.
Bill Robinson wrote:
there are a couple defects that cause this - one is related to the deploy include list not being pruned properly (to only include the latest version of the rpm in the include list) and another is due to the filter options causing the rpm to be tagged as irrelevant incorrectly. there may be a couple other causes.
From the attached log:
12/06/15 20:43:01.313 INFO bldeploy - [New RPM Group] [stdout: 2] Using Includes List =
So, the includes list issue can be eliminated
yeah - so expanding on what rohit said - rp-pppoe-3.10-11.el6.x86_64 is part of this errata: https://access.redhat.com/errata/RHEA-2014:0424
this is an 'enhancement'. if you look at the catalog filter options and 'enhancement' is not checked that will likely be the root of the problem. you should also look to see if rp-pppoe-3.10-11.el6.x86_64 shows up in the RPMs or Irrelevant Patches smart groups.