On Thu, Nov 25, 2010 at 7:50 PM, Andrew Lyon <[email protected]> wrote: > On Wed, Nov 17, 2010 at 3:32 PM, <[email protected]> wrote: >> That is very odd...... The only dependency that the sensor data has that >> the other data does not have is the IPMI driver. Just to double confirm, >> you are using IPMI tool locally, not using the lan interface where you >> specify the IP address of the BMC? I will have to ask some of the >> developers to see if they have any theories on what would be causing this. >> >> Wayne Weilnau >> Systems Management Technologist >> Dell | OpenManage Software Development > > Hi, > > I've been on holiday but decided to have a quick look at this again as > my personal hosted server is a Dell r200 running Gentoo so I have good > reason to try to get this working in my own time as well as my > employers. > > The missing ipmi sections appears to be caused by > /opt/dell/srvadmin/etc/srvadmin-hapi/ini/dchipm.ini containing only > header comments about it being automatically generated, if I replace > the file with one taken from a SLE11SP1 image installed on the same > server then the missing sections appear and everything seems to work > ok, the Data Engine also takes a lot longer to start with the overall > startup time only very slightly less than when running Suse (which is > probably because when running Gentoo the system has less overall > load). > > How is the file normally populated? Running OMSA 6.3 on SLE11SP1 it > contains the following: > > # > # Automatically generated file: please don't edit > # Copyright (c) 1995-2010 Dell Inc. - All Rights Reserved > # This file is in config (not INI) format > # Generated on Thu Nov 25 18:44:17 GMT 2010 > # > hapi.openipmi.driverstarted=yes > hapi.openipmi.issupportedversion=yes > hapi.openipmi.driverpattern=ipmi_ > hapi.openipmi.basedriverprefix=ipmi_si > hapi.openipmi.poweroffmodule=ipmi_poweroff > hapi.openipmi.powercyclemodule=ipmi_poweroff > hapi.openipmi.ispoweroffcapable=no > hapi.allow.user.mode=no > > > When I created the ebuilds I was careful to create all of the > necessary dependencies and to port over the pre/post install/uninstall > scripts and running rpm -qi --scripts srvadmin-hapi again on SLE11SP1 > I can only see the usual omreg update, ldconfig, and commands to stop > the service if it is being upgraded, all of which I've already dealt > with, there is nothing about populating dchipm.ini > > Once dchipm.ini is populated everything appears to work properly, but > I am concerned that there may be other configuration steps which I've > also missed and I would like to be sure I've done the best job I can > before putting these ebuilds online for testing. > > How is the file populated? > > Are there any other similar files which need to be created/updated? > > Thanks > Andy >
I think this rpm: srvadmin-omilcore-6.3.0-639.1.sles11.noarch.rpm should be renamed from noarch to the appropriate architecture, because despite being "noarch" and having the same name the following two files are not the same: http://linux.dell.com/repo/hardware/OMSA_6.3/platform_independent/suse11/srvadmin-i386/srvadmin-omilcore-6.3.0-639.1.sles11.noarch.rpm http://linux.dell.com/repo/hardware/OMSA_6.3/platform_independent/suse11_64/srvadmin-x86_64/srvadmin-omilcore-6.3.0-639.1.sles11.noarch.rpm diff -r i386/opt/dell/srvadmin/etc/omreg.d/omreg-omilcore.cfg x86_64/opt/dell/srvadmin/etc/omreg.d/omreg-omilcore.cfg 3c3 < openmanage.archtype=32 --- > openmanage.archtype=64 6c6 < openmanage.funcs=/opt/dell/srvadmin/lib/srvadmin-omilcore/Funcs.sh --- > openmanage.funcs=/opt/dell/srvadmin/lib64/srvadmin-omilcore/Funcs.sh Only in i386/opt/dell/srvadmin: lib Only in x86_64/opt/dell/srvadmin: lib64 diff -r i386/opt/dell/srvadmin/sbin/CheckSystemType x86_64/opt/dell/srvadmin/sbin/CheckSystemType 46c46 < SYSCHECK_OVERRIDE_FILE="/opt/dell/srvadmin/lib/openmanage/IGNORE_GENERATION" --- > SYSCHECK_OVERRIDE_FILE="/opt/dell/srvadmin/lib64/openmanage/IGNORE_GENERATION" I can work around this by not including a hash for the rpm in the ebuild Manifest so that when the user tries to install omsa on gentoo the appropriate rpm for their arch is downloaded and the checksum is added, but its not a clean solution and people who share a distfiles repo between systems of different arch would still find that omsa install breaks if they install a x86 system and then x86_64 as the second install will reuse the rpm from the first install. Andy _______________________________________________ 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
