[Linux-PowerEdge] SRPMs / spec files
Antman, Jason (CMG-Atlanta)
Jason.Antman at coxinc.com
Mon Apr 7 15:45:34 CDT 2014
Thanks for the tip. Apologies for the delayed response; around the time I sent my last updates to this thread, I got pulled off on a major project and am just coming back to work on the openmanage issues.
So on one test host, I changed my yum repository files from "hardware/latest" to "hardware/OMSA_7.2". After doing that I was able to upgrade from 7.1.0 to 7.2.0, but it was a bit tricky as it seems there was an issue with the "srvadmin-all" metapackage:
Transaction Check Error:
file /opt/dell/srvadmin/lib64/openmanage/libdcsnra.so from install of srvadmin-idrac-snmp-7.2.0-4.481.2.el6.x86_64 conflicts with file from package srvadmin-rac-components-7.1.0-4.220.2.el6.x86_64
It seems that there's some sort of issue with how the metapackage pulls in dependencies, or how files are moved from one package to another (like that error). I was able to use the yum shell to both install srvadmin-all and remove srvadmin-rac-components-7.1.0 in the same transaction, and the upgrade now worked:
# yum shell
> yum install srvadmin-all
> yum remove srvadmin-rac-components-7.1.0
However, I'm seeing some strange behavior with racadm:
[root at djamemdev1 ~]# which racadm
[root at djamemdev1 ~]# ls -l /opt/dell/srvadmin/sbin/racadm
lrwxrwxrwx 1 root root 19 Apr 7 15:58 /opt/dell/srvadmin/sbin/racadm -> racadm-wrapper-rac5
[root at djamemdev1 ~]# rpm -q --whatprovides /opt/dell/srvadmin/sbin/racadm-wrapper-rac5
[root at djamemdev1 ~]# /opt/dell/srvadmin/sbin/racadm-wrapper-rac5 version
RACADM version 7.1.0
Copyright (c) 2003-2012 Dell, Inc.
All Rights Reserved
Even though RPM confirms I have omsa 7.2.0 installed, `racadm version` is returning "RACADM version 7.1.0". I've already run "srvadmin-services.sh restart".
Is there any known reason why racadm would be reporting the wrong version? Is there something left hanging around my system that's causing it to use the wrong racadm?
I'm also seeing something else that seems a bit strange:
[root at opskvmdev1 ~]# which racadm
[root at opskvmdev1 ~]# ls -l /opt/dell/srvadmin/sbin/racadm
lrwxrwxrwx 1 root root 19 Apr 7 16:39 /opt/dell/srvadmin/sbin/racadm -> racadm-wrapper-rac5
[root at opskvmdev1 ~]# rpm -q --whatprovides /opt/dell/srvadmin/sbin/racadm
file /opt/dell/srvadmin/sbin/racadm is not owned by any package
So it looks like `racadm` itself is a symlink that's not actually owned by a package?
Thanks for any assistance,
On 03/11/14 07:14, Manoj_Poonia at Dell.com<mailto:Manoj_Poonia at Dell.com> wrote:
Dell - Internal Use - Confidential
Hi Jason, We offer our apologies for this delay and issue. Looks like you are upgrading from 7.1 to 7.3.2 (and not 7.3.0). We had observed one upgrade issue on 7.3.2 (irrespective of YUM), this is known issue and unfortunately there is no workaround for the same at this moment. Yes, this minor patch was not recommended for the upgrade (and was not covered in test) but can be used as fresh installation. We are planning to post our updated OM version soon!!
If you can do the fresh installation of 7.3.2 by keeping a backup of your user specific configuration, would also help.
From: linux-poweredge-bounces-Lists On Behalf Of Dominguez, Jared
Sent: Tuesday, March 11, 2014 12:15 AM
To: Antman, Jason (CMG-Atlanta)
Subject: Re: [Linux-PowerEdge] SRPMs / spec files
You're welcome. Again, I'm not on the OpenManage team, but I offer my apologies that your January email fell through the cracks. I've already emailed some people on that team, who have already started moving it along to the right engineering people. A call to ProSupport will also help make sure that your issue is tracked.
On Mon, Mar 10, 2014 at 01:30:14PM -0500, Antman, Jason (CMG-Atlanta) wrote:
>Ok, thanks so much. I've never contacted support since I've been with
>my current employer, but I know we have a support contract (we just
>took delivery of about 60 r720's) so I'll follow up on that.
>Sure, I'll give that a try. I'm caught up in a production incident
>today, but sometime in the next few days I'll try and do a clean OS
>install on a machine or two, and try that path.
>Thanks for the time,
>On 03/10/2014 02:26 PM, D. Jared Dominguez wrote:
>> I'm sorry to hear that no one replied. I will pass on your memo to
>> some people I know on the OpenManage team so hopefully someone can
>> look into your email from January. I still would recommend utilizing
>> your support contract (assuming you have one) and contacting ProSupport.
>> In the meantime, are you able to test what happens when you upgrade
>> from OMSA 7.1 to OMSA 7.2 instead of straight from 7.1 to 7.3? I'm
>> not sure if upgrades with skipping minor versions are tested (or even
>> with skipping major versions).
>> On Mon, Mar 10, 2014 at 01:19:02PM -0500, Antman, Jason (CMG-Atlanta)
>>> Thanks for the reply and clarification.
>>> My specific issue is that I have a bunch (hundreds) of servers with
>>> OMSA 7.1.0 installed on them via RPM. We use Puppet to manage
>>> configuration and package installation. If I try to install/upgrade
>>> (well Puppet tries, but same thing) to 7.3.2, it fails because a
>>> bunch of files were moved from srvadmin-omcommon to srvadmin-omacs,
>>> but the spec files were never updated to reflect this. The
>>> documentation sats that I can "yum upgrade" to upgrade srvadmin, but
>>> this is failing if srvadmin-all-7.1.0 is already installed, and I
>>> try to upgrade to 7.3.2.
>>> Rathish's suggestion of manually uninstalling and then reinstalling
>>> simply isn't possible for us - we enforce configuration with Puppet,
>>> which installs the specified version of a package, there's no way to
>>> remove them.
>>> This should be a *simple* fix to the RPM spec file, of adding the
>>> correct provides/obsoletes statements in the spec file. Doing this
>>> would allow an actual update to 7.3, not a remove and reinstall.
>>> Since my suggestion of this on 1/23 seems to have fallen on deaf
>>> ears, I wondered where I could get the RPM spec files and source, so
>>> I could submit a patch to make the fix. I don't really *want* the
>>> source to OMSA itself, but the only way for me to make and test a
>>> change to the spec files would be to have it.
>>> Is this something that, if I get in touch with my sales rep, they'd
>>> know how to approach? I have over a hundred servers that I'm unable
>>> to update OMSA on (and having all sorts of issues with Puppet) all
>>> because of what should be a 3-4 line fix in the spec files...
>>> On 03/10/2014 12:09 PM, Jared_Dominguez at DELL.com<mailto:Jared_Dominguez at DELL.com> wrote:
>>> To my knowledge, no they're not open source. Certainly the
>>> software suite
>>> is not. I haven't checked the license on each and every spec
>>> file, though,
>>> and I am not on the OpenManage team. If you have a specific
>>> question or
>>> issue with OMSA, please speak up. As far as I'm aware, companies
>>> do not provide the source for their closed source software upon a
>>> request (as much as I personally prefer FLOSS). However, if you
>>> are having
>>> a specific issue with OMSA, there are Dell people on this list
>>> who will do
>>> their best to help resolve the issue. Also, I think you may
>>> The RPMs are officially supported on RHEL and SLES, not
>>> community-supported. It is the debs for Ubuntu/Debian that are
>>> "community-supported", though you did not inquire about those.
>>> -----Original Message-----
>>> From: Antman, Jason (CMG-Atlanta) [Jason.Antman at coxinc.com<mailto:Jason.Antman at coxinc.com>]
>>> Sent: Monday, March 10, 2014 06:28 AM Central Standard Time
>>> To: linux-poweredge-Lists
>>> Subject: Re: [Linux-PowerEdge] SRPMs / spec files
>>> Yup, still no response. It seems to me that this is "serial
>>> - their meaning of "community support" seems to be that they release
>>> software, and then ignore the community and users until the next
>>> I'm going to go through my contacts, LinkedIn, etc. and see if I
>>> know of
>>> someone sufficiently high up the chain at Dell... we've got 500+ Dell
>>> machines in racks, and I'm more than happy putting whatever
>>> pressure on
>>> Dell that I can. If this isn't a problem they can't solve, fine. But
>>> having emails to the "only official support" (i.e. "don't call your
>>> vendor or the support line") totally ignored is unacceptable. On the
>>> other hand, maybe after this I can finally convince my boss to put in
>>> CapEx for evergreening the whole datacenter, and replace every
>>> last one
>>> of these Dell boxes with energy-efficient HPs. They even officially
>>> support Linux, and I've *never* had an email to their Linux mailing
>>> lists go unanswered...
>>> On 03/04/2014 09:49 AM, Eugene Vilensky wrote:
>>> > On Fri, 31 Jan 2014 12:45:36 +0000
>>> > "Antman, Jason (CMG-Atlanta)" <Jason.Antman at coxinc.com><mailto:Jason.Antman at coxinc.com> wrote:
>>> >> I've been looking around on linux.dell.com, but can't find the
>>> >> RPMs or spec files for OMSA. Can someone please point me to them?
>>> > Are the packaging scripts and specs open-source?
>>> > _______________________________________________
>>> > Linux-PowerEdge mailing list
>>> > Linux-PowerEdge at dell.com<mailto:Linux-PowerEdge at dell.com>
>>> > https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>>> Jason Antman | Systems Engineer | CMGdigital
>>> jason.antman at coxinc.com<mailto:jason.antman at coxinc.com> | p: 678-645-4155
>>> Linux-PowerEdge mailing list
>>> Linux-PowerEdge at dell.com<mailto:Linux-PowerEdge at dell.com>
>>> Click here to report this email as spam.
>>> Jason Antman | Systems Engineer | CMGdigital jason.antman at coxinc.com<mailto:jason.antman at coxinc.com>
>>> | p: 678-645-4155
>Jason Antman | Systems Engineer | CMGdigital jason.antman at coxinc.com<mailto:jason.antman at coxinc.com> |
Server OS Engineering
Dell | Enterprise Solutions Group
Linux-PowerEdge mailing list
Linux-PowerEdge at dell.com<mailto:Linux-PowerEdge at dell.com>
Jason Antman | Systems Engineer | CMGdigital
jason.antman at coxinc.com<mailto:jason.antman at coxinc.com> | p: 678-645-4155
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Linux-PowerEdge