Al, Why does ipmitool work correctly then without sending additional workarounds?
Thanks, Corey Osman [email protected] Green IT and Data Center Automation Specialist On Jul 29, 2012, at 12:18 PM, Al Chu <[email protected]> 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
