Bug 473251 - NFS install fails when exporting ISO images
NFS install fails when exporting ISO images
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-11-27 06:18 EST by Simon Andrews
Modified: 2008-12-04 17:16 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-12-02 10:58:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Simon Andrews 2008-11-27 06:18:57 EST
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:

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:


..then the NFS install works as expected.  This same option should be available from with the askmethod options.
Comment 1 Gordon Messmer 2008-12-01 19:41:37 EST
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.
Comment 2 Chris Lumens 2008-12-02 10:58:25 EST
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.
Comment 3 Simon Andrews 2008-12-02 11:13:21 EST
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.
Comment 4 Chris Lumens 2008-12-04 17:16:38 EST
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.

Note You need to log in before you can comment on or make changes to this bug.