Incorrectly detects NFS shares are mounted

[brianjmurrell]

Actual behavior
Risk Factor: high (inhibitor)
Title: Use of NFS detected. Upgrade can't proceed
Summary: NFS is currently not supported by the inplace upgrade.
We have found NFS usage at the following locations:

• Currently mounted NFS shares

Remediation: [hint] Disable NFS temporarily for the upgrade if possible.
Key: 9881b25faceeeaa7a6478bcdac29afd7f6baaaed

Expected behavior
When no NFS shares are actually mounted (as you can see from the preupgrade log message above), there should be no inhibition.

System information (please complete the following information):

• OS and version: AlmaLinux 8.10
• Linux pvr.interlinx.bc.ca 4.18.0-553.5.1.el8_10.x86_64 #1 SMP Wed Jun 5 09:12:13 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux

leapp-0.14.0-1.el8_6.noarch
leapp-deps-0.14.0-1.el8_6.noarch
leapp-data-almalinux-0.2-7.el8.noarch
leapp-upgrade-el8toel9-deps-0.16.0-6.el8_6.elevate.20.noarch
leapp-upgrade-el8toel9-0.16.0-6.el8_6.elevate.20.noarch
python3-leapp-0.14.0-1.el8_6.noarch

[brianjmurrell]

And the problem is here

leapp-repository/repos/system_upgrade/common/actors/checknfs/actor.py

Lines 33 to 38 in 249925a

	# Check mount
	for mount in storage.mount:
	if mount.tp.startswith("nfs"):
	nfs_found = True
	details += "- Currently mounted NFS shares\n"
	break

But this exact issue was reported upstream over 2 years ago! And it was fixed upstream over two years ago.

So why are we still hitting this using 2 year old code? This project has even released/tagged 0.19.0 so why are we still using 0.16.0?

[andrewlukoshko]

@brianjmurrell 0.19.0 is in Testing now and expected to become stable in August.
You can use it to migrate now, it's well tested already.
https://wiki.almalinux.org/elevate/ELevate-testing-guide.html

[andrewlukoshko]

0.19.0 is in stable now so closing