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

Description of problem:
When attempting to install a RHEL-5 guest on F-8 Test3 (plus latest updates),
using this command-line:

# virt-install -d -n manage -r 512 -f /var/lib/xen/images/manage.dsk -s 10
--nonsparse -p --nographics -l
nfs:bigpapi:/vol/engineering/redhat/rhel5-server-x86_64

I get the following backtrace:

Tue, 09 Oct 2007 09:40:32 DEBUG    Disk path not found: Assuming file disk type.


Starting install...
libvir: Xen Daemon error : GET operation failed: 
Tue, 09 Oct 2007 09:40:32 DEBUG    Preparing mount at
/var/lib/xen/virtinstmnt.ivNS7C
Tue, 09 Oct 2007 09:40:32 DEBUG    Distro None.
Tue, 09 Oct 2007 09:40:32 DEBUG    Acquiring file from
/var/lib/xen/virtinstmnt.ivNS7C/fedora.css
Tue, 09 Oct 2007 09:40:32 DEBUG    Cleaning up mount at
/var/lib/xen/virtinstmnt.ivNS7C
Invalid file location given: No such file or directory
Domain installation may not have been
 successful.  If it was, you can restart your domain
 by running 'virsh start manage'; otherwise, please
 restart your installation.
Tue, 09 Oct 2007 09:40:32 ERROR    Invalid file location given: No such file or
directory
Traceback (most recent call last):
  File "/usr/sbin/virt-install", line 485, in <module>
    main()
  File "/usr/sbin/virt-install", line 449, in main
    dom = guest.start_install(conscb,progresscb)
  File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 722, in
start_install
    self._prepare_install(meter)
  File "/usr/lib/python2.5/site-packages/virtinst/ParaVirtGuest.py", line 48, in
_prepare_install
    self._installer.prepare(guest = self, meter = meter)
  File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 683,
in prepare
    self._prepare_kernel_and_initrd(guest, distro, meter)
  File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 653,
in _prepare_kernel_and_initrd
    distro = distro)
  File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 583,
in acquireKernel
    progresscb=progresscb, distro=distro, scratchdir=scratchdir)
  File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 566,
in _storeForDistro
    if store.isValidStore(fetcher, progresscb):
  File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 213,
in isValidStore
    if fetcher.hasFile("fedora.css", progresscb):
  File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 160,
in hasFile
    tmpfile = self.acquireFile(filename, progresscb)
  File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 150,
in acquireFile
    raise ValueError, _("Invalid file location given: ") + msg
ValueError: Invalid file location given: No such file or directory

The problem is in virtinst/DistroManager.py; if you can't find fedora.css in the
FedoraImageStore.isValidStore() method, it stacktraces instead of trying
additional OS's.  That is, *any* PV guest that is not Fedora is going to fail,
since it will stack trace when looking in the directory structure.  In
_storeForDistro, I changed:

    for store in stores:
        if store.isValidStore(fetcher, progresscb):
            return store

to:

    for store in stores:
        try:
            if store.isValidStore(fetcher, progresscb):
                return store
        except:
            continue

which allowed me to start the RHEL-5 install.  This is with
python-virtinst-0.300.1-2.fc8, by the way.

-- Additional comment from mc-al34luc on 2007-10-11 10:16 EST --
Could we *PLEASE* not depend on Fedora distro directory artifacts when trying to
discern if a distro is Fedora / Redhat??? I warned about exactly this problem in
273781. Just implement the solution proposed there moving forward to avoid this
problem in the future. Thanks.

Chris, could you bump up the severity to "high"?


-- Additional comment from berrange on 2007-10-11 11:43 EST --
Created an attachment (id=224491)
Fixed exception handling

The bug is actually in the hasFile method for MountedImageFetcher which is used
for NFS. It was catching  RuntimeError, but the method it calls raises a
ValueError, which isn't a subclass of RuntimeError. This was broken back in
changeset   209:9d8165be6060   which switched from raising RuntimeError to
ValueError, but didn't switch all the callers.

-- Additional comment from berrange on 2007-10-11 14:00 EST --
Fix built into rawhide.

* Thu Oct 11 2007 Daniel P. Berrange <berrange> - 0.300.1-3.fc8
- Fix missing file exception check with NFS installs (rhbz #325591)