Description of problem: The Fedora 11 anaconda installer apparently cannot talk to an older NFS server successfully. I'm guessing it does not successfully negotiate the protocol with an older server, as the manpage says it should, but instead wants to use TCP even if the server only has UDP. At any rate, things like stage2=nfs:123.45.67.89:/images/install.img and repo=nfsiso:123.45.67.89:/path fail, with a stage1 "Error" window saying "That directory could not be mounted from the server" -- IF the (123.45.67.89) server is running an old version of NFS. (F10 worked.) It took me a long time (weeks) to discover that, partly because the error message was (and "INFO" messages in console 3 were) so generic. But eventually I tried having the install.img and ISO images on another machine, a newer linux with a newer NFS server running, and that worked. Version-Release number of selected component (if applicable): 11.5.0.59 How reproducible: Every time I tried. Steps to Reproduce: 1. Put install.img and the ISO(s) on an older-system server 2. specify repo=nfsiso: and stage2=nfs: to anaconda (I was using PXE) 3. Actual results: stage1 "Error" window saying "That directory could not be mounted from the server" Expected results: stage1 would fetch install.img, stage2 (=install.img) would get packages from ISO image(s) Additional info: I hope this can be fixed in Fedora 11 somehow, say by you putting new versions of (vmlinuz?) initrd.img and install.img out on the mirrors. I want to be able to install Fedora 11 using the same server I always use to install other things. Fixing it in Fedora 12 is not the same thing, in my opinion.
Both the command line and kickstart allow you to specify mount options to use: http://fedoraproject.org/wiki/Anaconda/Kickstart http://fedoraproject.org/wiki/Anaconda/Options
Apparently my "cannot talk to" comment wasn't clear enough. The 11.5.0.59 anaconda IS BROKEN AND WILL NOT WORK if you give LEGAL NFS OPTIONS to it to fetch the install.img via NFS -- IF the NFS server is "old" (probably only talking the UDP protocol but I do not have the knowledge to test that guess in some absolute fashion). Similarly, if you somehow still manage to fetch stage2 (say by FTP since NFS won't work), if you have specified the LEGAL "nfsiso" type of "repo" anaconda WILL NOT WORK. It will fail to get the package information, but at least tells you it is because it cannot "mount" the NFS target you are pointing it to -- IF the server machine is old enough, and thus runs an old version of the NFS server. If you then go to a shell window at that point and try to manually mount the remote NFS directory, you will get an error message. (As I recall mount complains about a bad argument but this is from memory.) If you instead then add the option "proto=udp" to your "nolock" option, the "mount" will succeed. That is all the proof I need that the NFS in stage1 and stage2 of anaconda is broken, and WILL NOT WORK when talking to an older NFS server (which only talks UDP, not TCP). The Fedora 10 anaconda did not have this problem. The Fedora 11 anaconda does. I disagree with your decision to mark this bug as "closed" and "notabug" -- but there is nothing I can do about it except to make this comment. Here are the PXE commands I used. This fails: kernel F11/vmlinuz append initrd=F11/initrd.img ramdisk_size=10000 repo=nfsiso:172.22.101.50:/home2/me/F/F11/DVD stage2=nfs:172.22.101.50:/home2/me/F/F11/install.img ip=dhcp keymap=us lang=en_US.UTF-8 loglevel=debug This works: kernel F11/vmlinuz append initrd=F11/initrd.img ramdisk_size=10000 repo=nfsiso:172.22.109.124:/home5/me/Fedora_11 stage2=nfs:172.22.109.124:/home5/me/Fedora_11/install.img ip=dhcp keymap=us lang=en_US.UTF-8 loglevel=debug The only essential difference is that 172.22.109.124 runs Fedora 8 and 172.22.101.50 runs an old system, the yum-updated ("legacy") RH7.3. (And lest you point to that being the problem, that RH7.3 machine has successfully talked VIA NFS to the anaconda in every Fedora from 1 through 10, inclusive. The F11 anaconda is the problem, not the server machine.)