Bug 203067

Summary: NFS install from cd-images does not work
Product: [Fedora] Fedora Reporter: Kim Bisgaard <kim-rh>
Component: anacondaAssignee: Chris Lumens <clumens>
Status: CLOSED RAWHIDE QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-20 21:03:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 150224    

Description Kim Bisgaard 2006-08-18 09:07:27 UTC
Description of problem:
The install I used to install fc5 (install by booting usb-stick, with
diskimage.img, "linux askmethod", NFS (server,directory)) does not work. When I
have entered NFS-server and dircetory it informs me (quite correctly) that that
dir. does not contain the exploded files for a fc install. It used to be
satisfied with a dir. containing the cd-images FC6...disc[1-?].iso

I have tested the images for correct sha1sum.

Version-Release number of selected component (if applicable):


How reproducible:
Allways

Steps to Reproduce:
1. download all cd-images of fc6-test2
2. boot with "linux askmethod"
3. choose NFS
4. point to server and dir. with step 1 iso files
  
Actual results:


Expected results:


Additional info:

Comment 1 Jeremy Katz 2006-08-22 23:52:42 UTC
Can you provide the exact error message you received?

Comment 2 Kim Bisgaard 2006-08-24 17:20:51 UTC
The exact error is:
That directory does not seem to contain a Fedora Core installation tree.



Comment 3 Chris Lumens 2006-09-07 19:36:45 UTC
I can get past this problem, but run into a "Missing ISO9660 Image" later when
the graphical installer starts.  I've fixed that one in CVS, but am unable to
reproduce your problem.  Can you attach the last several lines of tty3 to this
bug report?

Comment 4 Kim Bisgaard 2006-09-08 07:12:56 UTC
Three pieces of info:
1) this is a x86_64 install
2) assuming you meant vt3, here is approx what I get:
INFO mntloop loop7 on /tmp/loopimage as /mnt/source/FC-6-Test2-x86_64-disc5.iso
fd is 78
ERROR open file to loop mount /tmp/loopimage/Fedora/base/stage2.img failed
INFO umounting loopback /mnt/runtime loop0
ERROR LOOP_CLR_FD failed for /mnt/runtime loop0 (no such device of address)

repeating for disc6 and rescuecd

3) on vt4 I get approx:
iso 99660 extention: RRIP_1991A
iso 99660 extention: Joliet
unable to load NIS charset utf8

repeated all over the page/screen



Comment 5 Chris Lumens 2006-09-15 15:58:46 UTC
Please try again with FC6test3 and report if this is working for you.  I fixed a
couple problems with ISO installs in general right before this release, one of
which was specifically for NFS ISO installs.

Comment 6 Kim Bisgaard 2006-09-16 15:27:08 UTC
In short yes! but in practice I got stopped by other errors:

Using diskimage.img on usb-stick I got the following errors:
============================================================
syslinux 3.11 ....
Could not find kernel image: linux
boot:
============================================================

Using boot.iso on cd-rw, I got a lot of garbage (in the curces/textual menues)
which made the screens difficult to fill out, but I managed to get to the
graphical part.
But anaconda stopped prematurely after filling in the network info, when
timezone info was to be filled in (according to vt3).

Comment 7 Chris Lumens 2006-09-20 21:03:41 UTC
Hm, okay.  Please file additional bugs for the problems you are now seeing, and
I will close this one out as this particular bug appears to be fixed for you. 
Garbage on the screen in text mode is already know - it's probably kernel error
messages getting written directly to the screen, and isn't anything we have
control over.  I don't know what problem you are seeing regarding the network
info, but filing a separate bug with /tmp/anaconda.log (or /tmp/anacdump.log if
you are getting a traceback) would be the best way to solve that.