On Sun, 2012-07-29 at 12:22 -0700, Corey Osman wrote: > Al, > > > Why does ipmitool work correctly then without sending additional > workarounds?
I can't say for sure, b/c the invalidly formatted packet back from the HP system can affect things in different ways. Although I do not know ipmitool perfectly, different assumptions are made in various parts of the code. FreeIPMI tends to be a tad more strict on IPMI compliance, electing to error out to the user instead guessing what a system wants to do when it isn't in compliance. Could you recompile freeipmi w/ --enable-debug and --enable-trace? We can see a full error trace of what's going on when you try to do your ipmi-chassis-config --checkout. Al > > > 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 > > > > -- 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
