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
Green IT and Data Center Automation Specialist
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
address@hidden
Green IT and Datacenter Automation Specialist
_______________________________________________
Freeipmi-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/freeipmi-devel
--
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory