Bug 1849083

This bug from Fedora is reproducible in RHEL-8.3 too and it should be fixed there.

There is already fix proposed upstream. See below.

+++ This bug was initially created as a clone of Bug #1848718 +++

This is a follow-up to https://bugzilla.redhat.com/show_bug.cgi?id=1844287 specifically for this NFS ISO case, which appears to be unambiguously broken.

This is supposed to work: `inst.repo=nfs:nfsvers=4:10.0.2.110:/iso/image.iso` , assuming 10.0.2.110:/iso/ is a valid and accessible NFS share, and it contains the file 'image.iso', which is an installer image with a file repo on it (i.e. a DVD image). anaconda should mount 10.0.2.110:/iso , loopback mount the specified ISO file from it, and use the repository from within the image. This is what the test case https://fedoraproject.org/wiki/QA:Testcase_install_repository_NFSISO_variation covers. Up till anaconda-33.18-1.fc33 , that's what happened.

Since that build, though, it doesn't work any more. Instead, anaconda tries literally to mount '10.0.2.110:/iso/image.iso', and that fails:

18:01:40,672 WARNING org.fedoraproject.Anaconda.Modules.Payloads:DEBUG:anaconda.modules.payloads.source.nfs.initialization:Setting up NFS source: nfs:nfsvers=4:10.0.2.110:/iso/image.iso
18:01:40,673 WARNING org.fedoraproject.Anaconda.Modules.Payloads:INFO:program:Running... mount -t nfs -o nfsvers=4,nolock 10.0.2.110:/iso/image.iso /run/install/source/mount-0000-nfs-device
18:01:40,779 NOTICE kernel:FS-Cache: Loaded
18:01:40,903 NOTICE kernel:FS-Cache: Netfs 'nfs' registered for caching
18:01:40,927 NOTICE kernel:Key type dns_resolver registered
18:01:41,158 NOTICE kernel:NFS: Registering the id_resolver key type
18:01:41,158 NOTICE kernel:Key type id_resolver registered
18:01:41,158 NOTICE kernel:Key type id_legacy registered
18:01:41,269 INFO kernel:mount.nfs (1899) used greatest stack depth: 12072 bytes left
18:01:41,271 WARNING org.fedoraproject.Anaconda.Modules.Payloads:INFO:program:stderr:
18:01:41,271 WARNING org.fedoraproject.Anaconda.Modules.Payloads:INFO:program:b'mount.nfs: mount spec 10.0.2.110:/iso/image.iso or point /run/install/source/mount-0000-nfs-device is not a directory'

I guess it may work if you do it the other possible way - just specifying `inst.repo=nfs:nfsvers=4:10.0.2.110:/iso` and relying on anaconda to look through the mount and find the ISO file - but both methods are meant to work, and the one that's failing is the one we use in the openQA test.

Proposing as a Final blocker as a violation of "The installer must be able to use all supported local and remote package and installer sources" - https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#package-and-installer-sources . It's a *bit* arguable as there is the option of not specifying the ISO name, but that option does exist for a reason: if the share contains multiple ISO files, you may need to explicitly specify the right one.

--- Additional comment from Adam Williamson on 2020-06-19 00:30:31 UTC ---

So it looks to me like jknoecny completely rewrote this code, initially left out ISO support entirely, then added it back in in https://github.com/rhinstaller/anaconda/commit/af627cd8f68406896b4684ac5b634208d1365f40 but didn't handle this specific path - that code doesn't seem to have any way of accounting for the possibility of the ISO name being specified in the argument. So I think that needs to be added back. If he has time for this I'll leave this to Jiri as I guess he knows how the new code works so he knows where it would make sense to do the parsing for this :)

--- Additional comment from Jiri Konecny on 2020-06-19 08:03:59 UTC ---

Interesting, I thought I've added this possibility in. I'll try to fix this soon. Thanks a lot for investigating.

--- Additional comment from Jiri Konecny on 2020-06-19 11:45:42 UTC ---

PR: https://github.com/rhinstaller/anaconda/pull/2673