Known issues

This topic describes known issues for ESS.

ESS 5.3.x issues

The following table describes known issues in ESS 5.3.x and how to resolve these issues. Depending on which fix level you are installing, these might or might not apply to you.

Table 1. Known issues in ESS 5.3.x
Issue	Environment affected	Description	Resolution or action
The gssgennetworks script requires high-speed host names to be derived from I/O server (xCAT) host names using suffix, prefix, or both.	High-speed network generation Type: Install Version: All Arch: All Affected nodes: I/O server and EMS nodes	gssgennetworks requires that the target host name provided in -N or -G option are reachable to create the high-speed network on the target node. If the xCAT node name does not contain the same base name as the high-speed name you might be affected by this issue. A typical deployment scenario is: gssio1 // xCAT name gssio1-hs // high-speed An Issue scenario is: gssio1 // xCAT name foo1abc-hs // high-speed name	Create entries in the /etc/hosts with node names that are reachable over the management network such that the high-speed host names can be derived from it using some combination of suffix and/or prefix. For example, if the high-speed host names are foo1abc-hs, goo1abc-hs: Add foo1 and goo1 to the /etc/hosts using management network address (reachable) in the EMS node only. Use: gssgennetworks -N foo1,goo1 – suffix abc-hs --create-bond Remove the entries foo1 and goo1 from the /etc/hosts file on the EMS node once the high-speed networks are created. Example of how to fix (/etc/hosts): // Before `<IP><Long Name><Short Name> 192.168.40.21 gssio1.gpfs.net gssio1 192.168.40.22 gssio2.gpfs.net gssio2 X.X.X.X foo1abc-hs.gpfs.net foo1abc-hs X.X.X.Y goo1abc-hs.gpfs.net goo1abc-hs` // Fix `192.168.40.21 gssio1.gpfs.net gssio1 foo1 192.168.40.22 gssio2.gpfs.net gssio2 goo1 X.X.X.X foo1abc-hs.gpfs.net foo1abc-hs X.X.X.Y goo1abc-hs.gpfs.net goo1abc-hs gssgennetworks -N foo1, goo1 --suffix=abc-hs --create-bond`
Running gssutils over PuTTY might shows horizontal lines as “qqq” and vertical lines as “xxx”.	ESS Install and Deployment Toolkit Type: Install or Upgrade Version: All Arch: All Affected Nodes: EMS and I/O server nodes	PuTTY translation default Remote Character set UTF-8 might not translate horizontal line and vertical character sets correctly.	1. On the PuTTY terminal Window > Translation, change Remote character set from UTF-8 to ISO-8859-1:1998 (Latin-1, West Europe) (this should be the first option after UTF-8). 2. Open session.
gssinstallcheck might flag an error regarding page pool size in multi-building block situations if the physical memory sizes differ.	Software Validation Type: Install or Upgrade Arch: Big Endian or Little Endian Version: All Affected nodes: I/O server nodes	gssinstallcheck is a tool introduced in ESS 3.5, that helps validate software, firmware, and configuration settings. If adding (or installing) building blocks of a different memory footprint installcheck will flag this as an error. Best practice states that your I/O servers must all have the same memory footprint, thus pagepool value. Page pool is currently set at ~60% of physical memory per I/O server node. Example from gssinstallcheck: [ERROR] pagepool: found 142807662592 expected range 147028338278 - 179529339371	1. Confirm each I/O server node's individual memory footprint. From the EMS, run the following command against your I/O xCAT group: xdsh gss_ppc64 "cat/ proc/meminfo \| grep MemTotal" Note: This value is in KB. If the physical memory varies between servers and/or building blocks, consider adding memory and re-calculating pagepool to ensure consistency. 2. Validate the pagepool settings in IBM Spectrum Scale™: mmlsconfig \| grep -A 1 pagepool Note: This value is in MB. If the pagepool value setting is not roughly ~60% of physical memory, then you must consider recalculating and setting an updated value. For information about how to update the pagepool value, see IBM Spectrum Scale documentation on IBM® Knowledge Center.
The GUI might display the long-waiters warning: `Spectrum Scale long-waiters monitoring returned unknown result`	GUI Type: Upgrade Arch: Big Endian Version: All Affected nodes: All	Upon new installs (or upgrades) to ESS 5.3.x, the GUI might show an error due to a bad return code from mmhealth in its querying of long-waiters information. `/usr/lpp/mmfs/bin/mmdiag --deadlock Failed to connect to file system daemon: No such process RC=50`	There is no current workaround but it is advised to verify on the command line that no long-waiters exist. If the system is free from this symptom, mark the event as read on the GUI by clicking under the Action column. Doing so will clear the event.
Creating small file systems in the GUI (below 16G) will result in incorrect sizes	GUI Type: Install or Upgrade Arch: Big Endian or Little Endian Version: All Affected nodes: All	When creating file systems in the GUI smaller than 16GB (usually done to create CES_ROOT for protocol nodes) the size will come out larger than expected.	There is currently no resolution. The smallest size you might be able to create is 16GB. Experienced users might consider creating a customer vdisk.stanza file for specific sizes you require. You can try one of the following workarounds: Use three-way replication on the GUI when creating small file systems. Use gssgenvdisks which supports the creation of small file systems especially for CES_ROOT purposes (Refer to the `--crcesfs` flag).
Creating file systems in the GUI might immediately result in lack of capacity data	GUI Type: Install or Upgrade Arch: Big Endian or Little Endian Version: All Affected nodes: All	When creating file systems in the GUI you might not immediately see the capacity data show up.	You may wait up to 24 hours for the capacity data to display or simply use the command line which should accurately show the file system size.
The GUI might show ‘unknown’ hardware states for storage enclosures and Power® 8 servers in the ESS building block. Part info and firmware levels under the Hardware Details panel might also be missing. Upon adding ESS PPC64LE building-blocks to an existing PPC64BE environment, you might encounter this same issue.	GUI Type: Upgrade Arch: Big Endian Version: All Affected nodes: All	The ESS GUI (running on the EMS) might show ‘unknown’ under the Hardware panel for the ESS building block members. The ESS GUI might also be missing information under Part Info and Firmware version within the Hardware Details panel.	The workaround for this issue is the following: Login to the EMS Run the following in order: `/usr/lpp/mmfs/gui/cli/runtask RECOVERY_GROUP /usr/lpp/mmfs/gui/cli/runtask DISK_ENCLOSURES /usr/lpp/mmfs/gui/cli/runtask ENCLOSURE_FW /usr/lpp/mmfs/gui/cli/runtask CHECK_FIRMWARE` After running, the GUI should refresh with the issues resolved. Note: If this issue is encountered on adding ESS PPC64LE building-blocks to an existing PPC64BE environment, there is no current workaround as the GUI does not support multiple xCATs.
Canceling disk replacement through GUI leaves original disk in unusable state	GUI Type: Install or Upgrade Arch: Big Endian or Little Endian Version: All Affected nodes: I/O server nodes	Canceling a disk replacement can lead to an unstable system state and must not be performed. However, if you did this operation, use the provided workaround.	Do not cancel disk replacement from the GUI. However, if you did, then use the following command to recover the disk took state: mmchpdisk <RG> --pdisk <pdisk> --resume
Under Monitoring > Hardware details, you might see enclosures missing location information.	GUI Type: Install or Upgrade Arch: Big Endian or Little Endian Version: All Affected nodes: N/A	After install or upgrade to ESS 5.3.x, you might see missing location information for the enclosures in your system. This does not reflect the true frame U location which can be observed in the Monitoring > Hardware details panel.	The current workaround is to wait up to 24 hours for the GUI services to refresh. After this period you will see the enclosure location information fill in.
The GUI wizard might start again after completing the initial setup.	GUI Type: Install Arch: Big Endian Version: All Affected nodes: N/A	After completing the GUI wizard setup on ESS 5.3.x PPC64BE, you might see the start screen again.	If you see the GUI wizard start screen a second time, type the address of the EMS into the browser and press enter. https://<`ip of EMS over management network`> You will then be taken to the GUI home screen.
Upon upgrades to ESS 5.3.x, you might notice missing pools and users in the Monitoring > Capacity GUI panel	GUI Type: Upgrade Arch: All Version: All Affected nodes: N/A	You might notice one or more missing pools or users after upgrading to ESS 5.3.x in the Monitoring > Capacity GUI panel. You may also see missing capacity and throughput data under the Monitoring > Nodes panel.	There is currently no resolution or workaround. Try waiting 24 hours for the GUI to refresh. You can also try clicking Refresh.
Upon upgrades to ESS 5.3.x, you might see several Mellanox OFED `weak-updates` and `unknown symbols` messages on the console during gss_updatenode.	OFED Type: Upgrade Arch: Big Endian and Little Endian Version: All Affected nodes: N/A	When building the new OFED driver against the 44.1 kernel, you might see many messages such as `weak-updates` and `unknown symbols`.	There is currently no resolution or workaround. These messages can be ignored.
During firmware upgrades on PPC64LE, `update_flash` might show the following warning: `Unit kexec.service could not be found.`	Firmware Type: Installation or Upgrade Arch: Little Endian Version: All Affected nodes: N/A		This warning can be ignored.
Setting target node names within gssutils might not persist for all panels. The default host names, such as ems1 might still show.	Deployment Type: Install or Upgrade Arch: Big Endian or Little Endian Version: All Affected nodes: All	gssutils allows users to conveniently deploy, upgrade, or manage systems within a GUI-like interface. If you run gssutils –N `NODE`, it must store that node name and use it throughout the menu system. There is a bug that might prevent this from working as designed.	Use on one of the following resolutions: Change the JSON file directly as follows. Issue this command. `/opt/ibm/gss/tools/bin/gssutils \ --customize --ems-node-name ems2 \ --config /tmp/LE.json` Issue this command. `/opt/ibm/gss/tools/bin/gssutils \ --config /tmp/LE.json` For any given command within gssutils, you can press "c" to customize. At that point, you can change the node name(s) accordingly.
The GUI wizard might fail due to an error when issuing mmaddcomp.	GUI Type: Install Arch: Big Endian or Little Endian Version: All Affected nodes: N/A	During the GUI wizard setup users might hit an error similar to the following. `ERROR: column name is not unique`	Run the final wizard setup step again. After doing this, the error does not occur and you can proceed to the GUI login.