Issue

What were you trying to do that didn't work? Leapp reports an inhibitor because the mptctl module (that also depends on mptbase) is loaded and suggests to unload it using rmmod. As per my understanding (and comments from SME storage), there is no HW behind. The module in question cannot be unloaded when a userpace application speaks with that API through its device descriptor (/dev/mpt*ctl), presumably to fetch metrics only. On Dell HW, "Dell OMSA software" has open fds on the device descriptors (as per lsof), and on HP HW there is also an HP monitoring tool. In all cases, the controller is in fact handled by the megaraid_sas driver and works on RHEL 7 as well as RHEL 8, but it leads to a confusion for both customers and the support as these mpt* drivers are usually seen as related to storage and HW. 03:00.0 RAID bus controller [0104]: Broadcom / LSI MegaRAID SAS-3 3108 [Invader] [1000:005d] (rev 02) Subsystem: Dell PERC H730P Adapter [1028:1f42] : Kernel driver in use: megaraid_sas Kernel modules: megaraid_sas filename: /lib/modules/3.10.0-1062.52.2.el7.x86_64/kernel/drivers/scsi/megaraid/megaraid_sas.ko.xz description: Broadcom MegaRAID SAS Driver [..] alias: pci:v00001000d0000005Dsv*sd*bc*sc*i*  <<= [1000:005d] If nobody checks the HW is really certified for RHEL 8, some customers or even support engineers could be attempted to give up the IPU process due to this inhibitor. Please provide the package NVR for which bug is seen: leapp-upgrade-el7toel8-0.18.0-3.el7_9 How reproducible: Always for the customer. Steps to reproduce Load the module in question: # modprobe mptctl And use it (ideally with these 3rd parties monitoring software...): # python -c "f=open('/dev/mptctl','r');import time;time.sleep(3600)" & Run leapp preupgrade and check the report. Risk Factor: high (inhibitor) Title: Leapp detected loaded kernel drivers which have been removed in RHEL 8. Upgrade cannot proceed. Summary: Support for the following RHEL 7 device drivers has been removed in RHEL 8: - mptctl Try to unload the mptctl module as suggested. # rmmod mptctl rmmod: ERROR: Module mptctl is in use Expected results An inhibitor sharing what userspace program is speaking with this kernel module. Actual results Customers feel stuck with this problem. Additional notes Typical customer outputs $ grep -e mpt.?ctl sos_commands/process/lsof_-b_M_-n_-l_-c  dsm_sa_da 8258 0 11u CHR 10,220 0t0 201399 /dev/mptctl dsm_sa_da 8258 0 12u CHR 10,221 0t0 205031 /dev/mpt2ctl dsm_sa_da 8258 0 13u CHR 10,221 0t0 201411 /dev/mpt3ctl dsm_sa_da 9442 0 11u CHR 10,220 0t0 201399 /dev/mptctl dsm_sa_da 9442 0 12u CHR 10,221 0t0 205031 /dev/mpt2ctl dsm_sa_da 9442 0 13u CHR 10,221 0t0 201411 /dev/mpt3ctl $ grep -e 8258 -e 9442 sos_commands/process/ps_auxwww root 8258  0.0  0.0 993984 23692 ? Ssl  Oct31 0:59 /opt/dell/srvadmin/sbin/dsm_sa_datamgrd root 9442  0.0  0.0 592308 18364 ? Ss Oct31 0:00 /opt/dell/srvadmin/sbin/dsm_sa_datamgrd Recommended workaround: kill the processes returned by the below command: # find /dev -name 'mpt*ctl' -exec fuser -u {} \; Another possible workaround: append the following to the kernel cmdline and reboot: mptctl.blacklist=1 rd.driver.blacklist=mptctl mptbase.blacklist=1 rd.driver.blacklist=mptbase From the PES data (in /etc/leapp/files/device_driver_deprecation_data.json precisely), such a driver has a 'pci' device_type, is it expected? { "available_in_rhel": [ 7 ], "deprecation_announced": "", "device_id": "", "device_name": "", "device_type": "pci", "driver_name": "mptctl", "maintained_in_rhel": [] }, Note: mptbase cannot be considered the same way, it is loaded by mptctl as a depmod, but it is also loaded by mpt*sas drivers that handle real HW.

Release Notes

No. of Comments

Resolution

Won't Do