Created attachment 479400 [details] /tmp/anaconda.log Description of problem: It seems that loader requires a .treeinfo when attempting to do an NFS ISO install. I don't think HD ISO installs required the .treeinfo present in the directory containing the ISO. I'm filing this report mainly to review/discuss the change. If this is expected behavior, we can reassign this to the install-guide so the docs are updated appropriately, and update our test case procedures. Version-Release number of selected component (if applicable): * anaconda-15.20-1 Steps to Reproduce: 1. Boot F-15-Alpha-TC2 with "askmethod" 2. select NFS install 3. Enter server + path to a directory containing *just* Fedora-15-Alpha-x86_64-DVD.iso Actual results: ┌─────────────┤ Error ├─────────────┐ │ │ │ The URL provided does not contain │ │ installation media. │ │ │ │ ┌────┐ │ │ │ OK │ │ │ └────┘ │ │ │ │ │ └───────────────────────────────────┘ Expected results: ┌────────────────────────┤ Warning ├────────────────────────┐ │ │ │ Warning! This is pre-release software! ↑ │ │ ▮ │ │ Thank you for downloading this pre-release of Fedora. ▒ │ │ ▒ │ │ This is not a final release and is not intended for use ▒ │ │ on production systems. The purpose of this release is ▒ │ │ to collect feedback from testers, and it is not ▒ │ │ suitable for day to day usage. ▒ │ │ ▒ │ │ To report feedback, please visit: ▒ │ │ ▒ │ │ https://bugzilla.redhat.com ↓ │ │ │ │ ┌──────┐ ┌────────────────┐ │ │ │ Exit │ │ Install Anyway │ │ │ └──────┘ └────────────────┘ │ │ │ │ │ └───────────────────────────────────────────────────────────┘ Additional info: * /tmp/anaconda.log indicated that it was looking for a .treeinfo file. Adding this file on the NFS server, allowed the installer to proceed. 20:35:33,027 INFO loader: only have one network device: eth0 20:35:33,028 INFO loader: doing kickstart... setting it up 20:35:33,028 DEBUG loader: configuring device eth0 20:35:37,052 INFO loader: get_connection (2068): NetworkManager connected 20:35:37,080 INFO loader: url is nfs:dell-t5400.test.redhat.com:/var/lib/libvirt/images/x86_64/.treeinfo 20:35:37,080 DEBUG loader: parseNfsHostPathOpts url: |dell-t5400.test.redhat.com:/var/lib/libvirt/images/x86_64/.treeinfo| 20:35:37,080 DEBUG loader: parseNfsHostPathOpts host: |dell-t5400.test.redhat.com| 20:35:37,080 DEBUG loader: parseNfsHostPathOpts path: |/var/lib/libvirt/images/x86_64/.treeinfo| 20:35:37,080 DEBUG loader: parseNfsHostPathOpts opts: |(null)| 20:35:37,081 INFO loader: file location: nfs:dell-t5400.test.redhat.com:/var/lib/libvirt/images/x86_64/.treeinfo 20:35:37,220 ERR loader: failed to open /tmp/mnt/.treeinfo: No such file or directory 20:35:37,220 ERR loader: failed to copy file to /tmp/.treeinfo
Compare promptForHardDrive with promptForNfs to see why this is happening. promptForNfs simply needs to be adapted to understand the ISO method as well, though I'm not yet sure how to accomplish that.
Reproduced on anaconda 15.20.1 in f15 alpha rc1
Mark it as F15Blocker: 3. The installer must be able to use all supported local and remote package source options https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria
Got a fix in for the beta, updated Fixed In Version: field appropriately.
Reproduced on anaconda 15.25 of F15-beta-tc1.
Created attachment 488735 [details] anaconda-15.25.log
(In reply to comment #6) > Created attachment 488735 [details] > anaconda-15.25.log I think the problem you are seeing now is actually a different issue. According to clumens, the installer will always check for the presence of .treeinfo file when doing an NFS install. It does this to determine if you are attempting a traditional NFS install. If no .treeinfo file is found, it will then attempt to perform an NFS ISO install. The problem you are seeing now is being tracked as bug#691880 and should be fixed in anaconda-15.26-1. I'll leave this in ON_QA until we can complete a full NFS ISO installation without requiring a .treeinfo file.
James - yes, great explanation.
Confirmed fix using F-15-Beta-RC2 images
Discussed at 2011/04/15 blocker review meeting. jlaska affirms that this is already fixed, so closing. Blocker status is approved. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers