CentOS 4.x and OMSA 6.1 - Update breaks IPMI --FIXED

[Kaj Niemi]

Hi,

On Jul 3, 2009, at 16:41, Hostmaster wrote:

> I hope someone else finds this useful, or that the nice folks at  
> Dell can please put a clause into this script to identify Centos 4  
> using this string and classify it as RHEL4 equivalent. FWIW, I have  
> tested OMSA 6.1 on some CentOS 5.3 servers, and they all seem  
> unaffected.


Thanks for the tip. I hit this one as well. Should have been reading  
this list more closely instead of just hitting "mark all read" in  
Mail ;-)

The easiest way to fix this without resorting to vi magic on every  
system is to do the following.

DISCLAIMER: If you break your/someone else's system(s) you really get  
to keep all the pieces. It worked for me.

1. install srvadmin-hapi-6.1.0-648.i386.rpm somewhere, preferably 32- 
bit platform (as package is i386 arch)
2. fix /opt/dell/srvadmin/hapi/bin/instsvcdrv on that system
3. rpmrebuild it [1] and increment the release field only
4. diff the two rpms that the --scripts and contained files are  
identical (as one would expect) with the exception of one
5. copy the new srvadmin-hapi-6.1.0-648.1.i386.rpm to your local  
repository under hardware/OMSA_6.1/anywhere
6. find all occurrences of srvadmin-hapi-6.1.0-648.i386.rpm and  
hardlink/symlink the file in step 5 to all the same directories (to  
pe2950/rh40_64/srvadmin for example)
7. run createrepo on each of those directories (if in #6 you did the  
sym/hardlink magic in pe2950/rh40_64/srvadmin run createrepo in pe2950/ 
rh40_64)
8. yum update happily [2]

[1] http://rpmrebuild.sourceforge.net/
[2] packages from the dell repositories are by default required to be  
signed so gpgcheck needs to be off as well.

The above can be done for fix dell_inventory_collector 6.1.0 to fix  
its requirements dependency problem, too.

My frustrations with the dell repositories are that:

1. I get to do easy Q&A (okay since my /etc/redhat-release doesn't say  
what a real RHEL system says this one is on me)

2. I get to do hard Q&A (cross fingers every time I sync the dell  
repositories) so in reality I pretty much have to try install from  
scratch and upgrade on the same kind of systems (PE1950/2950, etc.)  
each time to see what happens both in package resolving and how  
omreport/omconfig behave
- smbios dependencies, dell_inventory_collector, etc.

3. Firmware updates get installed but do not update on rhel4 & rhel5  
(bios, perc at least) very realiably
- output claims things work great but a perc doesn't really get  
flashed in 2 seconds no matter what

4. Someone at dell runs createrepo on a much more recent system so  
people running yum get again hit by weird errors
- every time I sync I must run createrepo for the lowest common  
denominator in use (rhel4)

A few years ago the situation was much better. Still, this is much  
better than what the competition has so I guess I should be  
thankful. :-)



Kaj
-- 
Kaj J. Niemi
<kajtzu at basen.net>
FI +358 45 63 12000
KSA +966 54 52 43277



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20090717/a6dddfa0/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3833 bytes
Desc: not available
Url : http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20090717/a6dddfa0/attachment-0001.p7s