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 only4. 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 <[email protected]> FI +358 45 63 12000 KSA +966 54 52 43277
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Linux-PowerEdge mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/linux-poweredge Please read the FAQ at http://lists.us.dell.com/faq
