With recent OpenBMC builds, this script sometimes fails to update BMC with below error:

Preserve network...
{
  "data": {
    "description": "The specified resource cannot be created: '/org/openbmc/control/flash/bmc'"
  },
  "message": "403 Forbidden",
  "status": "error"
}Update via TFTP...
{
  "data": {
    "description": "org.freedesktop.DBus.Error.FileNotFound: path or object not found: /org/openbmc/control/flash/bmc"
  },
  "message": "404 Not Found",
  "status": "error"
}Waiting for downloading...

This is caused by the legacy obmc flash service lowered its priority, and is not started when the script tries to use it.

openbmctool toolVersion = "1.06"
openbmctool.py sensors list with single sensor lists all sensors.
I believe this is a known issue.

openbmctool.py produces output that amounts to clutter when it is unwanted. Example:
Attempting login...

User root has been logged out

Can you change it to NOT produce extra output. You could offer a "verbose" parm so you could see such output when it is desired.

OpenBmc tool is displaying the wrong running firmware. after updating openbmctool to update firmware, the tool is displaying the wrong running firmware..
The second issue was for the FW update and this tool should not have displayed the latest code due to this issue with code update..
. After a firmware update was pushed, the priority of the image was set to 0 after the image was activated, and the old image was set to priority 1. After a reboot of the BMC, the priority 1 images was loaded instead of the priority 0. It took an AC cycle to get the proper image loaded which is not the expected behaviour.

On a recent OpenBMC build, when running
openbmctool.py -H $BMC -U ******** -P ******** certificate update client ldap -f ./certificate.pem

get the following unexpected response. All openbmctool.py certificate operations fail similarly.

{
  "data": {
    "description": "global name 'busName' is not defined"
  },
  "message": "503 Service Unavailable",
  "status": "error"
}
Failed to update the certificate```

with openbmctool.py toolVersion = "1.06":

bash-4.1$ python3 openbmctool.py -H $BMC -U root -P $PWD dump list
Attempting login...
{
"data": [
"/xyz/openbmc_project/dump/internal/manager",
"/xyz/openbmc_project/dump/entry/3"
}

python3 openbmctool.py -H $BMC -U root -P $PWD dump delete all
Attempting login...
You must specify an entry number to delete <-------------------------

Hi,

when I try to install a new certificate I get the following error message.

py openbmctool.py -H xxx.xxx.xxx.xxx -U root -P xxxxxx certificate update server https -f "xxxx.pem"
Attempting login...
Updating certificate url=https://xxx.xxx.xxx.xxx/xyz/openbmc_project/certs/server/https
{
"data": {
"description": "The specified resource cannot be created"
},
"message": "403 Forbidden",
"status": "error"
}
Failed to update the certificate
User root has been logged out

Request to change the openbmctool.py shebang line from
#!/usr/bin/python3
to
#!/usr/bin/env python3

Some systems may not have python3 at /usr/bin but have it in $PATH.

openbmctool toolVersion = "1.06"
openbmctool.py fru list with single fru lists all frus.
I believe this may be known issue.

openbmctool.py version = 1.07

1. Is "blink "a valid option in chassis identify?
   bash-4.1$ python3 openbmctool.py -H $BMC -U root -P 0penBmc chassis identify -h
   usage: openbmctool.py chassis identify [-h] {on,off,status}
   positional arguments:
   {on,off,status} The control option for the led: on, off, blink, status <------ is blink valid?

2. Is "info" a valid option for bmc?
   bash-4.1$ python3 openbmctool.py -H $BMC -U xxxx -P xxx bmc -h
   usage: openbmctool.py bmc [-h] {reset} ...
   positional arguments:
   info Displays information about the BMC hardware, including device
   revision, firmware revision, IPMI version supported,
   manufacturer ID, and information on additional device support.

For an unactivated image like:

"/xyz/openbmc_project/software/ace821ef": {
      "Activation": "xyz.openbmc_project.Software.Activation.Activations.Ready",
      "ExtendedVersion": "op-build-v2.0.10-24-g6c8e467,buildroot-2018.05.1-9-gc99f2ee,skiboot-v6.0.14,hostboot-3bf7fcf-pf177c86,occ-3a505ff,linux-4.17.12-openpower1-pfd19258,petitboot-v1.7.3-pe15f91f,machine-xml-dce824c,hostboot-binaries-hw112718a.op920,capp-ucode-p9-dd2-v4,sbe-7aa21f6,hcode-hw112718a.op920",
      "Path": "/tmp/images/ace821ef",
      "Purpose": "xyz.openbmc_project.Software.Version.VersionPurpose.Host",
      "RequestedActivation": "xyz.openbmc_project.Software.Activation.RequestedActivations.None",
      "Version": "IBM-witherspoon-OP9-v2.0.10-2.22",
      "associations": [
        [
          "inventory",
          "activation",
          "/xyz/openbmc_project/inventory/system/chassis"
        ]
      ]
    },

openbmctool firmware list will fail like:

./openbmctool.py -U root -P 0penBmc -H $BMC firmware list
Attempting login...
Traceback (most recent call last):
  File "./openbmctool.py", line 3772, in <module>
    main()
  File "./openbmctool.py", line 3745, in main
    output = args.func(args.host, args, mysess)
  File "./openbmctool.py", line 2061, in firmwareList
    firmwareInfoDict = parseFWdata(firmwareDict)
  File "./openbmctool.py", line 1995, in parseFWdata
    if firmwareDict['data'][key]['Priority'] == 0:
KeyError: 'Priority'

openbmctool: minor sel issues
in openbmctool.py Version: 1.07
I noticed two minor issues

   1. 'sel resolve all' always gives 'Unable to set the alert to resolved'.  No alerts are resolved.

   2. sel list of an individual eSEL, for example  'sel list 19', gave the same outupt
      as 'sel list' with no parameters.  That is, the details for all eSELs was listed.
     'sel get 19' did the same.

openbmctool: version 1.06, 1.07 or 1.08

when doing
python3 openbmctool.py -H $BMC_IP -U ******** -P ******** health_check
get failure "JSON object must be str, not 'dict'" as follows:

Attempting login...
Traceback (most recent call last):
File "openbmctool.py", line 2290, in
main()
File "openbmctool.py", line 2264, in main
output = args.func(args.host, args, mysess)
File "openbmctool.py", line 1582, in healthCheck
sels = json.loads(selPrint(host, args, session))
File "/opt/rh/rh-python34/root/usr/lib64/python3.4/json/init.py", line 312, in loads
s.class.name))
TypeError: the JSON object must be str, not 'dict'

This seen on recent r7 firmware. Older firmware works fine.

openbmctool version = 1.09

bash-4.1$ pwd
~/$HOME

bash-4.1$ python3 openbmctool.py -H $BMC -U xxxx -P xxxxxxx collect_service_data
Attempting login...
Inventory collected and stored in /tmp/x.x.x.x--2018-09-24_10.07.06/inventory.txt
Sensor readings collected and stored in /tmp/x.x.x.x--2018-09-24_10.07.06/sensorReadings.txt
System LED status collected and stored in /tmp/x.x.x.x--2018-09-24_10.07.06/ledStatus.txt
error: Policy Table not found. <---------------------------
sel short list collected and stored in /tmp/x.x.x.x--2018-09-24_10.07.06/SELshortlist.txt
Failed to collect system event logs
the JSON object must be str, not 'dict'
Attempting to get a full BMC enumeration
RAW BMC data collected and saved into /tmp/x.x.x.x--2018-09-24_10.07.06/bmcFullRaw.txt
Collecting bmc dump files
retrieving dump file 5
retrieving dump file 4
retrieving dump file 3
retrieving dump file 2
retrieving dump file 1
data collection complete

policyTable.json is in $PATH, same location as openbmctool.py
ls -l ~/bin
-rwxrwxr-x 1 ssombar ssombar 105086 Sep 24 09:48 openbmctool.py
-rwxrwxr-x 1 ssombar ssombar 996910 Sep 24 09:48 policyTable.json

bash-4.1$ which openbmctool.py
~/bin/openbmctool.py
bash-4.1$ which policyTable.json
~/bin/policyTable.json

Version 1.07 of the openbmctool has logging functions. Version 1.09 is more robust but does not support logging. Can we perhaps have a new version which is a merge of both?

Version 1.09 is available from here
https://www14.software.ibm.com/support/customercare/sas/f/lopdiags/scaleOutLCdebugtool.html

Version 1.07 is available from here:
git clone https://github.com/openbmc/openbmc-tools/ then look for thalerj

Ran into this when trying out the tool to parse a pcap file.

 python3 ~/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap ~/delete-me/good.pcap
....
[[[108, 4, 1, 1, 11, 4294967295], [[7, "org.freedesktop.DBus"], [6, ":1.116"], [1, "/org/freedesktop/DBus"], [2, "org.freedesktop.DBus"], [3, "NameAcquired"], [8, "s"]]], [":1.116"]]
[[[108, 1, 0, 1, 117, 2], [[1, "/org/freedesktop/DBus"], [3, "AddMatch"], [2, "org.freedesktop.DBus"], [6, "org.freedesktop.DBus"], [8, "s"], [7, ":1.116"]]], ["type='signal',member='JobRemoved',path='/org/freedesktop/systemd1',interface='org.freedesktop.systemd1.Manager',"]]
unpack requires a bytes object of length 1
parse_fixed: Error unpacking b''
parse_fixed: Attempting to unpack type DBusType.BYTE with properties TypeProperty(field=<DBusType.BYTE: 121>, type='B', nature=1)
AlignedStream: absolute offset: 81
AlignedStream: relative offset: 69
RawMessage(endian=108, header=b'l\x02\x01\x01\x00\x00\x00\x00\xff\xff\xff\xff', data=b'>\x00\x00\x00\x05\x01u\x00\x02\x00\x00\x00\x07\x01s\x00\x14\x00\x00\x00org.freedesktop.DBus\x00\x00\x00\x00\x06\x01s\x00\x06\x00\x00\x00:1.116\x00\x00\x08\x01g\x00\x00\x00\x00\x00')
Traceback (most recent call last):
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 206, in parse_fixed
    val = struct.unpack("{}{}".format(endian, prop.type), val)[0]
struct.error: unpack requires a bytes object of length 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 400, in <module>
    main()
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 394, in main
    for msg in parse_session(stream, matchers):
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 338, in parse_session
    cooked = parse_packet(packet)
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 332, in parse_packet
    msg = parse_message(RawMessage(data[0], data[:12], data[12:]))
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 328, in parse_message
    raise e
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 319, in parse_message
    header, data = parse_header(raw)
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 294, in parse_header
    fields = parse_fields(endian, astream)
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 280, in parse_fields
    fields = parse_container(endian, stream, sig)
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 270, in parse_container
    return parse_array(endian, stream, tc.members)
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 252, in parse_array
    elem = parse_type(endian, stream, tc)
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 240, in parse_type
    val = parse_container(endian, stream, tc)
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 272, in parse_container
    return parse_struct(endian, stream, tc.members)
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 260, in parse_struct
    arr.append(parse_type(endian, stream, tc))
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 236, in parse_type
    val = parse_fixed(endian, stream, tc)
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 212, in parse_fixed
    stream.dump_assert(False)
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 198, in dump_assert
    self.dump()
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 192, in dump
    print("AlignedStream: remaining buffer:\n{}".format(self.drain()[0]))
  File "/Users/andrewg/Code/openbmc-tools/amboar/obmc-scripts/dbus-pcap/dbus-pcap", line 186, in drain
    assert self.offset - self.stash[1] == len(self.stash[0])
AssertionError

The parsing of the data when running fru print does not look right. This is the openbmctool level that is in CORAL 1.13

openbmctool.py version = 1.07

I see 'dump delete all' is a valid choice according to the -h option for dump delete.

However, when attempting to delete all dumps, you must specify an entry number to delete.

bash-4.1$ python3 openbmctool.py -H $BMC -U xxxxx -P xxxxxx dump delete all
Attempting login...
You must specify an entry number to delete
User root has been logged out

I think we have an issue with the policy table or missing information to interpret.

Customer system got a SEL event:

12535 | Unknown | 2020-02-11 13:56:24 | Unknown | Critical | error: Not found in policy table: Sensor.Device.Error.ReadFailure||

But it really is not telling us what sensor. When I go into the elog file I see the following for this event:

DICT_ENTRY "oa{sa{sv}}" {
OBJECT_PATH "/xyz/openbmc_project/logging/entry/12535";
ARRAY "{sa{sv}}" {
DICT_ENTRY "sa{sv}" {
STRING "org.freedesktop.DBus.Peer";
ARRAY "{sv}" {
};
};
DICT_ENTRY "sa{sv}" {
STRING "org.freedesktop.DBus.Introspectable";
ARRAY "{sv}" {
};
};
DICT_ENTRY "sa{sv}" {
STRING "org.freedesktop.DBus.Properties";
ARRAY "{sv}" {
};
};
DICT_ENTRY "sa{sv}" {
STRING "com.ibm.Logging.Policy";
ARRAY "{sv}" {
DICT_ENTRY "sv" {
STRING "EventID";
VARIANT "s" {
STRING "None";
};
};
DICT_ENTRY "sv" {
STRING "Description";
VARIANT "s" {
STRING "An internal BMC error occurred"

So I would expect the log message to say: Internal BMC error occurred. That would help the field on how to proceed with troubleshooting.

I did notice that customer has the 1.14 openbmctool version. Could not get them to update the tool to see if error symptom changed, they got upset and is now demanding a new system.

Failed sub commands are fru, sensors, sel, dump, firmware.

I noticed this minor issue on toolVersion = "1.06"

openbmctool.py -H $BMC -U root -P $PWS dump create
Attempting login...
Dump successfully created

If you list dumps, there aren't any yet.

Since it takes the BMC several minutes to create a dump, perhaps openbmctool could remind the user of that? or perhaps Dump initiation request successful or similar, instead of Dump successfully created?

Thanks!

@thalerj Is it possible to have the fru status sort to be more reader friendly?
i.e. instead of 0,1,10,11... list out 0,1,2,3,4.....
./openbmctool.py -H wsp001 -U root -P 0penBmc fru status
..
cpu1 | Yes | Yes | Yes | Yes
cpu1-core0 | No | No | No | No
cpu1-core1 | No | Yes | Yes | No
cpu1-core10 | No | Yes | Yes | No
cpu1-core11 | No | Yes | Yes | No
cpu1-core12 | No | No | No | No
cpu1-core13 | No | No | No | No
cpu1-core14 | No | Yes | Yes | No
cpu1-core15 | No | Yes | Yes | No
cpu1-core16 | No | No | No | No
cpu1-core17 | No | No | No | No
cpu1-core18 | No | Yes | Yes | No
cpu1-core19 | No | Yes | Yes | No
cpu1-core2 | No | Yes | Yes | No
cpu1-core20 | No | Yes | Yes | No
cpu1-core21 | No | No | No | No
cpu1-core22 | No | Yes | Yes | No
cpu1-core23 | No | Yes | Yes | No
cpu1-core3 | No | Yes | Yes | No
cpu1-core4 | No | No | No | No
cpu1-core5 | No | No | No | No
cpu1-core6 | No | Yes | Yes | No
cpu1-core7 | No | Yes | Yes | No
cpu1-core8 | No | Yes | No | No
cpu1-core9 | No | Yes | No | No
dimm0 | Yes | Yes | Yes | No
dimm1 | Yes | Yes | Yes | No
dimm10 | Yes | Yes | Yes | No
dimm11 | Yes | Yes | Yes | No
dimm12 | Yes | Yes | Yes | No
dimm13 | Yes | Yes | Yes | No
dimm14 | Yes | Yes | Yes | No
dimm15 | Yes | Yes | Yes | No
dimm2 | Yes | Yes | Yes | No
dimm3 | Yes | Yes | Yes | No
dimm4 | Yes | Yes | Yes | No
dimm5 | Yes | Yes | Yes | No
dimm6 | Yes | Yes | Yes | No
dimm7 | Yes | Yes | Yes | No
dimm8 | Yes | Yes | Yes | No
dimm9 | Yes | Yes | Yes | No

This issue is to add Redfish PasswordChangeRequired support to openbmctool. For background, see https://github.com/openbmc/docs/blob/master/designs/expired-password.md and the Redfish piece openbmc/bmcweb#103.

Problem statement
Users of a new out-of-the-box system which uses the EXPIRED_PASSWORD image feature will immediately encounter an expired password for the root account which must be changed before they can use the BMC. Using older versions of openbmctool to access this system will fail.

The latest openbmctool must be able to (A) tell users their password is expired, and (B) work with both older and newer releases of OpenBMC-based systems.

Proposed changes
Change the openbmctool login function to detect if Redfish is available (using the existing isRedfishSupport = redfishSupportPresent() support) and create the session via POST to /redfish/v1/SessionService/Sessions as an alternative to the /login URI. Make the corresponding change for logout. Only the SessionService will tell openbmctool if the user's password is expired; /login will not. If the password is expired, openbmctool will direct the user to use the openbmctool set_password command to change their password, and the command they were trying to use fails.

Discussion
The intended use is: openbmctool.py ... -U root -P 0penBmc set_password -p NEWPASS.
It would be easy to add an interactive password change dialog to the login function, but I am focused on non-interactive use cases where openbmctool uses is invoked from a shell script. Can we get some users to vet this approach?

This property goes away when the code update completes. Theory is that we're catching a race condition where the update is done and property is gone but we miss the "Active". Should just retry.

$ ./openbmc-sfw -I --server w37.aus.stglabs.ibm.com update_auto /scratch/arj/op-build/output/images/witherspoon.pnor.squashfs.tar 
Activation Progress: 10%
Activation Progress: 10%
Traceback (most recent call last):
  File "./openbmc-sfw", line 254, in <module>
    args.func(args)
  File "./openbmc-sfw", line 185, in do_update_auto
    s.update_auto(args.image, args.reboot)
  File "./openbmc-sfw", line 95, in update_auto
    self.__wait_for_activation(image_id)
  File "./openbmc-sfw", line 150, in __wait_for_activation
    print 'Activation Progress: ' + str(image['Progress']) + '%'
KeyError: 'Progress'

FYI @charleshofer @anoo1 @amboar

openbmctool version = 1.06

On one of our systems, saw this:
bash-4.1$ python3 openbmctool.py -H $BMC -U xxxxxx -P xxxxxx health_check

Attempting login...
Traceback (most recent call last):
File "openbmctool.py", line 2125, in
main()
File "openbmctool.py", line 2099, in main
output = args.func(args.host, args, mysess)
File "openbmctool.py", line 1548, in healthCheck
sels = json.loads(selPrint(host, args, session))
File "/opt/rh/rh-python34/root/usr/lib64/python3.4/json/init.py", line 312, in loads
s.class.name))
TypeError: the JSON object must be str, not 'dict'

When using python 2.7 with openbmctool and trying to get the tool version using the -V option, the command returns saying too few arguments.

python openbmctool.py -V
usage: openbmctool.py [-h] [-H HOST] [-U USER] [-A | -P PW] [-j]
[-t POLICYTABLELOC] [-V]

                  {fru,sensors,sel,chassis,collect_service_data,health_check,dump,bmc,mc,gardclear,firmware}
                  ...

openbmctool.py: error: too few arguments

I got eventlog xyz.openbmc_project.State.Host.Error.SoftOffTimeout, but could not find this in policy table.

I want to reduce size of openbmc rootfs file to run on ast2500 board, I got one suggestion to use rootfs_size.py script .I dont know where to run this script and which command to run the script. Can anyone provide steps to run this script.

Thanks in advance