Al

Here is the output after recompiling with the debug and trace options.  

http://pastebin.com/u2BfpNjb


Thanks,

Corey Osman
[email protected]

Green IT and Data Center Automation Specialist






On Jul 30, 2012, at 7:05 AM, Al Chu <[email protected]> wrote:

> On Mon, 2012-07-30 at 06:16 -0700, Jim Mankovich wrote:
>> Al, Corey,
>> 
>> FYI, The  DL380 G5 only supports IPMI 2.0.
> 
> Well that's an IPMI compliance issue as well.
> 
>> Could one of you summarize which IPMI command or commands that
>> you are having issues with?  Maybe I can help out.
> 
> The issue is the Get System Boot Options IPMI command and the "boot
> flags" parameter selector.  See Corey's previous link:
> 
> http://pastebin.com/6E9R9VNG
> 
> which shows a packet trace.
> 
> Al
> 
>> -- Jim Mankovich | [email protected] --
>> 
>> On 7/29/2012 1:18 PM, Al Chu wrote:
>>> On Sun, 2012-07-29 at 11:48 -0700, Corey Osman wrote:
>>>> 
>>>> 
>>>> 
>>>> On Jul 29, 2012, at 11:05 AM, Al Chu <[email protected]> wrote:
>>>> 
>>>>> Hey Corey,
>>>>> 
>>>>> For some reason, on your system, HP motherboard sends extra data for
>>>>> this particular IPMI payload.
>>>>> 
>>>>> 192.168.1.22: Payload Unexpected Data:
>>>>> 192.168.1.22: ------------------------
>>>>> 192.168.1.22: [  BYTE ARRAY ... ] = unexpected_data[12B]
>>>>> 192.168.1.22: [ 00h 00h 00h 00h 00h 00h 00h 00h ]
>>>>> 192.168.1.22: [ 00h 00h 00h F5h ]
>>>>> 
>>>>> FreeIPMI reasonably determines this payload is bogus and throws it
>>>>> out.
>>>>> I'm not really sure how to work around this.  Can you do a
>>>>> --checkout
>>>>> with IPMI 1.5?  i.e. --driver-type=LAN
>>>> 
>>>> I can't because of the following error which is fixed by specifying
>>>> LAN_2_0
>>>> 
>>>> 
>>>>  authentication type unavailable for attempted privilege level
>>> Your system simply may not be configured to allow the currently used
>>> authentication level.  You can experiment with different ones using the
>>> '-a' option.
>>> 
>>>> 
>>>> 
>>>> Additionally,
>>>> 
>>>> 
>>>> I just tried the ipmitool method to set the boot device and it
>>>> worked.  However the difference is that it sets the boot device
>>>> instead of retrieving the information
>>>> 
>>>> I am going to try and just set the boot device instead of performing a
>>>> checkout.  I would assume it freeipmi is better sending data than
>>>> querying.
>>> The issue is that FreeIPMI will send the data in the format it knows of,
>>> which may not work with whatever data format the HP motherboard is
>>> working with.
>>> 
>>> I suppose it's also worth trying inband communication on the motherboard
>>> to see if reading the chassis config works that way.
>>> 
>>> At the minimum, please send this information to HP.  They should
>>> definitely fix their board.
>>> 
>>> Al
>>> 
>>>> Corey
>>>> 
>>>> 
>>>> 
>>>>> Al
>>>>> 
>>>>> On Sun, 2012-07-29 at 10:20 -0700, Corey Osman wrote:
>>>>>> Please ignore my previous post as I forgot to plugin my ipmi
>>>>>> device.
>>>>>> 
>>>>>> 
>>>>>> Here is the corrected output:
>>>>>> 
>>>>>> 
>>>>>> ipmi-chassis-config --username=admin
>>>>>> --password=password--hostname=192.168.1.22 --driver-type=LAN_2_0
>>>>>> --debug --section=Chassis_Boot_Flags --checkout
>>>>>> 
>>>>>> 
>>>>>> http://pastebin.com/6E9R9VNG
>>>>>> 
>>>>>> Note: this is an HP DL380 G5 with ilo 2 - version 2.0 firmware
>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> 
>>>>>> Corey Osman
>>>>>> [email protected]
>>>>>> 
>>>>>> 
>>>>>> Green IT and Data Center Automation Specialist
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Jul 29, 2012, at 9:57 AM, Corey Osman <[email protected]>
>>>>>> wrote:
>>>>>> 
>>>>>>> Here is the out of running the following command (There were 9
>>>>>>> total
>>>>>>> attempts with the output below):
>>>>>>> 
>>>>>>> 
>>>>>>> ipmi-chassis-config --username=admin
>>>>>>> --password=password--hostname=192.168.1.22 --driver-type=LAN_2_0
>>>>>>> --debug --section=Chassis_Boot_Flags --checkout
>>>>>>> 
>>>>>>> 
>>>>>>> 192.168.1.22:
>>>>>>> =====================================================
>>>>>>> 192.168.1.22: IPMI 1.5 Get Channel Authentication Capabilities
>>>>>>> Request
>>>>>>> 192.168.1.22:
>>>>>>> =====================================================
>>>>>>> 192.168.1.22: RMCP Header:
>>>>>>> 192.168.1.22: ------------
>>>>>>> 192.168.1.22: [               6h] = version[ 8b]
>>>>>>> 192.168.1.22: [               0h] = reserved[ 8b]
>>>>>>> 192.168.1.22: [              FFh] = sequence_number[ 8b]
>>>>>>> 192.168.1.22: [               7h] = message_class.class[ 5b]
>>>>>>> 192.168.1.22: [               0h] = message_class.reserved[ 2b]
>>>>>>> 192.168.1.22: [               0h] = message_class.ack[ 1b]
>>>>>>> 192.168.1.22: IPMI Session Header:
>>>>>>> 192.168.1.22: --------------------
>>>>>>> 192.168.1.22: [               0h] = authentication_type[ 8b]
>>>>>>> 192.168.1.22: [               0h] = session_sequence_number[32b]
>>>>>>> 192.168.1.22: [               0h] = session_id[32b]
>>>>>>> 192.168.1.22: [               9h] = ipmi_msg_len[ 8b]
>>>>>>> 192.168.1.22: IPMI Message Header:
>>>>>>> 192.168.1.22: --------------------
>>>>>>> 192.168.1.22: [              20h] = rs_addr[ 8b]
>>>>>>> 192.168.1.22: [               0h] = rs_lun[ 2b]
>>>>>>> 192.168.1.22: [               6h] = net_fn[ 6b]
>>>>>>> 192.168.1.22: [              C8h] = checksum1[ 8b]
>>>>>>> 192.168.1.22: [              81h] = rq_addr[ 8b]
>>>>>>> 192.168.1.22: [               0h] = rq_lun[ 2b]
>>>>>>> 192.168.1.22: [              1Eh] = rq_seq[ 6b]
>>>>>>> 192.168.1.22: IPMI Command Data:
>>>>>>> 192.168.1.22: ------------------
>>>>>>> 192.168.1.22: [              38h] = cmd[ 8b]
>>>>>>> 192.168.1.22: [               Eh] = channel_number[ 4b]
>>>>>>> 192.168.1.22: [               0h] = reserved1[ 3b]
>>>>>>> 192.168.1.22: [               1h] =
>>>>>>> get_ipmi_v2.0_extended_data[ 1b]
>>>>>>> 192.168.1.22: [               4h] = maximum_privilege_level[ 4b]
>>>>>>> 192.168.1.22: [               0h] = reserved2[ 4b]
>>>>>>> 192.168.1.22: IPMI Trailer:
>>>>>>> 192.168.1.22: --------------
>>>>>>> 192.168.1.22: [              3Dh] = checksum2[ 8b]
>>>>>>> ipmi-chassis-config: connection timeout
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> 
>>>>>>> Corey Osman
>>>>>>> [email protected]
>>>>>>> 
>>>>>>> 
>>>>>>> Green IT and Data Center Automation Specialist
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Jul 22, 2012, at 10:57 PM, Al Chu <[email protected]> wrote:
>>>>>>> 
>>>>>>>> Hi Corey,
>>>>>>>> 
>>>>>>>> On Sun, 2012-07-22 at 13:20 -0700, Corey Osman wrote:
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> My ruby implementation is off to a great start but I had a
>>>>>>>>> few
>>>>>>>>> questions with regards to driver types and inband
>>>>>>>>> configuration.
>>>>>>>>> 
>>>>>>>>> Since I will have no idea as to what kind of IPMI device
>>>>>>>>> needs
>>>>>>>>> to be
>>>>>>>>> controlled I need to make sure that everything appears
>>>>>>>>> automatic
>>>>>>>>> with
>>>>>>>>> regards to driver types and any kind of workarounds.
>>>>>>>>> 
>>>>>>>>> My goal is to automatically detect driver type and
>>>>>>>>> workarounds
>>>>>>>>> to ease
>>>>>>>>> the pain for folks who use the ruby-freeipmi library.
>>>>>>>> I admit I'm not sure of the best way to handle this and make
>>>>>>>> sure
>>>>>>>> the
>>>>>>>> code is super-portable.  It's sort of an unfortunate
>>>>>>>> side-effect/consequence of IPMI being implemented by so many
>>>>>>>> vendors.
>>>>>>>> ipmitool is no different, as you select an interface if the
>>>>>>>> default
>>>>>>>> doesn't work.
>>>>>>>> 
>>>>>>>>> My current test device is an HP DL380 G5.  I was hoping to
>>>>>>>>> have
>>>>>>>>> this
>>>>>>>>> device automatically detected but it appears I need to
>>>>>>>>> supply
>>>>>>>>> the
>>>>>>>>> --driver-type=LAN_2_0.
>>>>>>>>> 
>>>>>>>>> Although this is not really a problem as I am planning on
>>>>>>>>> doing
>>>>>>>>> some
>>>>>>>>> testing up front as to which driver to explicitly assign.
>>>>>>>>> 
>>>>>>>>> However, I have noticed that when I call ipmi-chassis-config
>>>>>>>>> --checkout  the command appears to stall and doesn't provide
>>>>>>>>> all
>>>>>>>>> the
>>>>>>>>> information.  Output below
>>>>>>>> Could you provide the --debug output from the below?  Use the
>>>>>>>> --section=Chassis_Boot_Flags so we can isolate the debug
>>>>>>>> output to
>>>>>>>> just
>>>>>>>> he bad section below.
>>>>>>>> 
>>>>>>>>> How do I set the bios to boot from cdrom, usb and network?
>>>>>>>>>  Also
>>>>>>>>> do I
>>>>>>>>> have a choice of which network device I can boot from?
>>>>>>>> Once we get this section working, you'll see the full list of
>>>>>>>> options.
>>>>>>>> 
>>>>>>>>       ## Possible values:
>>>>>>>> NO-OVERRIDE/PXE/HARD-DRIVE/HARD-DRIVE-SAFE-MODE/
>>>>>>>>       ##
>>>>>>>>                 DIAGNOSTIC_PARTITION/CD-DVD/BIOS-SETUP/REMOTE-FLOPPY
>>>>>>>>       ##
>>>>>>>>                 
>>>>>>>> PRIMARY-REMOTE-MEDIA/REMOTE-CD-DVD/REMOTE-HARD-DRIVE/FLOPPY
>>>>>>>>       Boot_Device
>>>>>>>>                                   NO-OVERRIDE
>>>>>>>> 
>>>>>>>>> Can someone supply or document the commands I would use to
>>>>>>>>> set
>>>>>>>>> the
>>>>>>>>> boot device?  What boot options do I have available, as only
>>>>>>>>> Floppy is
>>>>>>>>> in the output?
>>>>>>>>> Additionally,  is this a one time boot setting or will it
>>>>>>>>> boot
>>>>>>>>> from
>>>>>>>>> the device after every reboot.
>>>>>>>> It should be configurable via
>>>>>>>> 
>>>>>>>>       ## Possible values: Yes/No (Yes = All Future Boots; No =
>>>>>>>> Next Boot Only)
>>>>>>>>       Boot_Flags_Persistent                         No
>>>>>>>> 
>>>>>>>> once we get it to output.
>>>>>>>> 
>>>>>>>>> Also, do I need to supply an inband option here?
>>>>>>>> Inband communication is usually auto-discovered, but every
>>>>>>>> simple
>>>>>>>> is
>>>>>>>> different and its certainly possible a auto-discovery can fail
>>>>>>>> in
>>>>>>>> some
>>>>>>>> systems.  Some HP motherboards have a known inband defect,
>>>>>>>> which
>>>>>>>> may
>>>>>>>> require use of a workaround (see manpage).
>>>>>>>> 
>>>>>>>> Hope this helps get things going for you,
>>>>>>>> 
>>>>>>>> Al
>>>>>>>> 
>>>>>>>>> Please feel free to have a look at my code and provide any
>>>>>>>>> suggestions.  I have written a README file to explain how
>>>>>>>>> things
>>>>>>>>> will work.
>>>>>>>>> 
>>>>>>>>> https://github.com/logicminds/ruby-freeipmi
>>>>>>>>> 
>>>>>>>>> Command line examples would be great as I can easily convert
>>>>>>>>> them to ruby calls.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> #
>>>>>>>>> # Section Chassis_Front_Panel_Buttons Comments
>>>>>>>>> #
>>>>>>>>> # The following configuration options are for enabling or
>>>>>>>>> disabling button
>>>>>>>>> # functionality on the chassis. Button may refer to a
>>>>>>>>> pushbutton, switch, or
>>>>>>>>> # other front panel control built into the system chassis.
>>>>>>>>> #
>>>>>>>>> # The value of the below may not be able to be checked out.
>>>>>>>>> Therefore we
>>>>>>>>> # recommend the user configure all four fields rather than a
>>>>>>>>> subset of them,
>>>>>>>>> # otherwise some assumptions on configure may be made.
>>>>>>>>> #
>>>>>>>>> Section Chassis_Front_Panel_Buttons
>>>>>>>>> ## Possible values: Yes/No
>>>>>>>>> Enable_Standby_Button_For_Entering_Standby    Yes
>>>>>>>>> ## Possible values: Yes/No
>>>>>>>>> Enable_Diagnostic_Interrupt_Button            Yes
>>>>>>>>> ## Possible values: Yes/No
>>>>>>>>> Enable_Reset_Button                           Yes
>>>>>>>>> ## Possible values: Yes/No
>>>>>>>>> Enable_Power_Off_Button_For_Power_Off_Only    Yes
>>>>>>>>> EndSection
>>>>>>>>> #
>>>>>>>>> # Section Chassis_Power_Conf Comments
>>>>>>>>> #
>>>>>>>>> # The following configuration options are for configuring
>>>>>>>>> chassis power
>>>>>>>>> # behavior.
>>>>>>>>> #
>>>>>>>>> # The "Power_Restore_Policy" determines the behavior of the
>>>>>>>>> machine when AC
>>>>>>>>> # power returns after a power loss. The behavior can be set
>>>>>>>>> to
>>>>>>>>> always power on
>>>>>>>>> # the machine ("On_State_AC_Apply"), power off the machine
>>>>>>>>> # ("Off_State_AC_Apply"), or return the power to the state
>>>>>>>>> that
>>>>>>>>> existed before
>>>>>>>>> # the power loss ("Restore_State_AC_Apply").
>>>>>>>>> #
>>>>>>>>> # The "Power_Cycle_Interval" determines the time the system
>>>>>>>>> will
>>>>>>>>> be powered down
>>>>>>>>> # following a power cycle command.
>>>>>>>>> #
>>>>>>>>> Section Chassis_Power_Conf
>>>>>>>>> ## Possible values:
>>>>>>>>> Off_State_AC_Apply/Restore_State_AC_Apply/On_State_AC_Apply
>>>>>>>>> Power_Restore_Policy
>>>>>>>>>                         Restore_State_AC_Apply
>>>>>>>>> ## Give value in seconds
>>>>>>>>> ## Power_Cycle_Interval
>>>>>>>>> EndSection
>>>>>>>>> #
>>>>>>>>> # Section Chassis_Boot_Flags Comments
>>>>>>>>> #
>>>>>>>>> # The following configuration options are for configuring
>>>>>>>>> chassis boot behavior.
>>>>>>>>> # Please note that some fields may apply to all future boots
>>>>>>>>> while some may only
>>>>>>>>> # apply to the next system boot.
>>>>>>>>> #
>>>>>>>>> # "Boot_Flags_Persistent" determines if flags apply to the
>>>>>>>>> next
>>>>>>>>> boot only or all
>>>>>>>>> # future boots.
>>>>>>>>> #
>>>>>>>>> # "Boot_Device" allows the user to configure which device
>>>>>>>>> the
>>>>>>>>> BIOS should boot
>>>>>>>>> # off of. Most users may wish to select NO-OVERRIDE to
>>>>>>>>> select
>>>>>>>>> the configuration
>>>>>>>>> # currently determined by the BIOS. Note that the
>>>>>>>>> configuration
>>>>>>>>> value BIOS-SETUP
>>>>>>>>> # refers to booting *into* the BIOS Setup, not from it.
>>>>>>>>> FLOPPY
>>>>>>>>> may refer to any
>>>>>>>>> # type of removeable media.
>>>>>>>>> #
>>>>>>>>> -----  This is all that is returned
>>>>>>>>> 
>>>>>>>>> Corey Osman
>>>>>>>>> [email protected]
>>>>>>>>> Green IT and Datacenter Automation Specialist
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> Freeipmi-devel mailing list
>>>>>>>>> [email protected]
>>>>>>>>> https://lists.gnu.org/mailman/listinfo/freeipmi-devel
>>>>>>>> --
>>>>>>>> Albert Chu
>>>>>>>> [email protected]
>>>>>>>> Computer Scientist
>>>>>>>> High Performance Systems Division
>>>>>>>> Lawrence Livermore National Laboratory
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> --
>>>>> Albert Chu
>>>>> [email protected]
>>>>> Computer Scientist
>>>>> High Performance Systems Division
>>>>> Lawrence Livermore National Laboratory
>>>>> 
>> 
> -- 
> Albert Chu
> [email protected]
> Computer Scientist
> High Performance Systems Division
> Lawrence Livermore National Laboratory
> 

_______________________________________________
Freeipmi-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Reply via email to