Re: [Freeipmi-devel] Questions regarding auto discovery and workarounds for ruby implementation

[Al Chu]

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 | address@hidden --
> 
> 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 <address@hidden> 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
> >>>> address@hidden
> >>>>
> >>>>
> >>>> Green IT and Data Center Automation Specialist
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Jul 29, 2012, at 9:57 AM, Corey Osman <address@hidden>
> >>>> 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
> >>>>> address@hidden
> >>>>>
> >>>>>
> >>>>> Green IT and Data Center Automation Specialist
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Jul 22, 2012, at 10:57 PM, Al Chu <address@hidden> 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
> >>>>>>> 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
> >>>>>>
> >>>>>
> >>>>
> >>> --
> >>> Albert Chu
> >>> address@hidden
> >>> Computer Scientist
> >>> High Performance Systems Division
> >>> Lawrence Livermore National Laboratory
> >>>
> 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory