Description of problem: If I try to install F10 using an exported ISO image over NFS anaconda will fail to recognise the image when using the 'askmethod' boot option and selecting NFS Version-Release number of selected component (if applicable): F10 release netinstall image. How reproducible: Always. Steps to Reproduce: 1. Boot from netinstall image 2. Add 'askmethod' to boot options 3. Select NFS install 4. Configure server to point to an NFS share which exports the DVD iso Actual results: An error saying the NFS share couldn't be mounted. Looking at the logs anaconda appends /images/install.img to the end of the supplied path. This suggests it's looking for an expanded install tree, rather than doing a loopback mount of the ISO which was in the original directory. Expected results: Anaconda recognises the presence of the DVD iso, mounts that and uses it for the rest of the install. Additional info: If instead of using 'askmethod' in the boot options you use: method=nfsiso:example.com:/some/dir ..then the NFS install works as expected. This same option should be available from with the askmethod options.
That's odd. In bug 466992 (and others), Chris Lumens indicates that method=nfsiso: should no longer work (intentionally). Users also report that it does not work.
No, you don't want an expanded install tree. What you want to do is make an images/ directory in the same directory as your ISO image, and put the install.img from your ISO image into that directory. anaconda no longer looks inside the ISO for install.img files. You need to provide that either explicitly with stage2=, or implicitly by booting with boot.iso or making the images/ directory.
I really don't understand this. What is the advantage to this over the previous behaviour? Anaconda can obviously still work without this via the nfsiso method, so as far as I'm concerned this is a regression from the previous behaviour. Previously I could export a single directory which contained both the i386 and the x86_64 isos and just boot from the appropriate netinstall disk to do a new install. Now I have to separate the isos for different architectures and instead of just downloading them I have to do a loopback mount and extract out a directory from the image as well. All for no greater functionality than I had before. I'd really like to know if there is some great advantage I'm missing here.
The point to this is that the loader really just goes and finds a stage2 image, and that's what knows about repos. Loader is really now just passing the location of where the installation media is on to the second stage of anaconda for it to make a decision about what to do. The advantage to the user is that we can have more advanced error handling and recovery by moving all this stuff into python instead of leaving it in the C-based loader. Another (much more secondary) advantage is that it gets rid of a bunch of fragile code we had to keep fixing, freeing up our time to work on better stuff. Anyway if you were doing split media installs, you really should have been keeping different versions/arches in separate locations to begin with, as anaconda could have picked the wrong ones and landed you in some pretty weird situations. We've seen bugs about that. And exactly how much work is it to do the loopback mount thing, since you only have to do that once and then do as many installs as you want from that? Booting with a boot.iso will also save you from having to take that step.