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
