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
>> 
> 

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

Reply via email to