Release Notes

Workaround: There is no workaround available.
• Description: When iDRAC Service Module 3.3.0 or later is installed on RHEL 6.10 Operating System with SELinux enabled in either of
Permissive or Enforcing modes, AVC denial logs (AVC denial is noticed with iptables) are observed in /var/log/audit/audit.log while
the following features are enabled or disabled:
• iDRAC Access via Host OS
• Host SNMP Alerts
Workaround: iDRAC Service Module 3.3.0 and later does not support explicit SELinux policies. No action is expected from the user.
There is no functionality impact to iSM features due to this.Future releases of iSM shall address the AVC denials.
Tracking number: JIT-102480
• Description: When TLS capable iSM (Example: iSM 3.4.0) is installed on Linux OSs' and the iSM client certificate name is modified
and iSM service is restarted, then iSM communication with iDRAC ends.
Workaround: As a workaround, user has to uninstall and install iSM 3.4.0
Tracking number: JIT-114656
• Description: If the third octet of USBNIC IPv4 address is modified in iDRAC, then the iDRAC Service Module communication with
iDRAC will end.
Workaround: NA.
Tracking number: JIT-118654
• Description: When invoking "iDRAC GUI Launcher" for the first time either using iDRACLauncher.sh or using the program menu
shortcut, the following message will be seen in operating system logs.
"localhost dbus-daemon[2369]: [system] Activating via systemd: service
name='net.reactivated.Fprint'unit='fprintd.service'
requested by ':1.18176' (uid=0 pid=126684 comm="sudo -l /opt/dell/srvadmin/iSM/bin/
InvokeiDRACLau"label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")"
Workaround: There is no functional impact. No action is required by the user.
Tracking number: JIT-124514
• Description: If Support Assist Collection(TSR) is triggered on 13G platforms, it is failing under the following conditions,
• The maser device which is exposed to OS by iDRAC during the SA collection but it is failing to mount /mnt since it is already
mounted by Administrator with read-only file system or no access permission. Once the failure occurs, the Support assist collection
will be blocked by iDRAC for 30 mins.
Workaround:
• OS root user or Administrator need to unmount /mnt.
(OR)
• Instead of using /mnt directly as mount point, OS user/Administrator need to create a separate directory under /mnt and use
that directory for their activity.
Tracking number: JIT-146515
Known issues on VMware ESXi operating systems
• Description: After performing an iDRAC Hard Reset operation on certain VMware ESXi operating systems, the IPMI driver
(ipmi_si_drv on ESXi 6.5U2 and ipmi on ESXi 6.7U1 Operating Systems) may become unresponsive because of an existing issue in the
IPMI driver. If the IPMI driver becomes unresponsive, reload the IPMI driver (ipmi_si_drv on ESXi 6.5U2 and ipmi on ESXi 6.7U1
Operating System).
Workaround: The issue is observed on iDRAC Service Module v2.3 and later supported ESXi versions.
To reload the IPMI driver:
• If the removal fails, then all applications (such as iDRAC Service Module and OpenManage Server Administrator) using the ipmi_si
need to be stopped and retry the operation.
Run the following commands
esxcli system wbem set -e 0
esxcfg-module -u ipmi_si_drv/ipmi => unload ipmi_si_drv/ipmi
esxcfg-module ipmi_si_drv/ipmi => load ipmi_si_drv/ipmi
Known Issues
9