Description of problem: In our kickstart configuration we mount an NFS share from our installation server into the anaconda environment, but on Fedora 8 test 3 that doesn't seem to work anymore. We start the kickstart with linux ks=nfs:linux:/export/linux/etc/ks/fc8 method=nfs:linux:/export/linux/fedora7.92-x86_64/packages/dvd This boots and proceeds up until the kickstart %pre script which does mount -o nolock linux:/export/linux /linux however this mount does not work. Looking at /tmp/syslog, it says <4>GFS2: path_lookup on linux:/export/linux returned error <4>GFS2: gfs2 mount does not exist It repeats these messages if I enter the NFS mount command by hand on the terminal. Version-Release number of selected component (if applicable): anaconda as on the 7.92 install cd. How reproducible: every time Steps to Reproduce: Set up kickstart environment with NFS mount in %pre. Actual results: Mount will not go through. Expected results: A mounted NFS file system.
Further information: using python, and anaconda's isys module, I can succesfully mount the same share. From the installation environment shell, starting python: import sys sys.path.append('/usr/lib/anaconda') import isys isys.mount('linux:/export/linux', '/linux', 'nfs', 1) exit() results in a working NFS mount. I have no idea why the shell command mount does not work anymore.
Any chance specifying "-t nfs" in the mount command helps?
Unfortunately, no. sh-3.2# mount -t nfs -o nolock linux:/export/linux /linux mount: mounting linux:/export/linux on /linux failed However this time the mount command does not return immediately. /tmp/syslog says <5>rpcbind: server 0.0.0.0 not responding, timed out Which is strange since a simple 'ping linux' does resolve the name to the correct IP address (of course, since the python way of mounting works).
I have exactly the same problem on F8 final on x86_64.
Adding a "me too" to this. I ran a tcpdump on my nfs server and saw absolutely no activity coming from the client whenever I tried to mount it. I tried a few different servers, including our Netapp, and nothing worked. Sometimes it's return that it failed right away, and others it would wait around 30-60 seconds then return that it failed (sometimes with that rpcbind error above in the kernel logs).
Oh, by the way, my experience is with Fedora 8 final as well.
This may be a long shot but I mention it here. I saw some problems with rpcinfo (from rpcbind package) which seem to be related to IPv6. They seem to appear when client interface gets IPv6 address (other than link local) through autoconfiguration. The funny thing is that problems seem to appear even when connecting to portmapper using IPv4 address (and not hostname). New rpcinfo relies on tirpc, so if mount relies on this for nfs as well all of this this may be connected. The question to other people here is then - do you have IPv6 deployed?
No. We don't have IPV6 deployed. In fact, I've gone so far as to specify noipv6 in the kernel boot params since fc6 so that it doesn't wait on the dhcp server to assign it an ipv6 address since it'll never come.
We use 'noipv6' as well (same reason, speeding up the kickstart process by avoiding the timeout).
I first tried getting rid of noipv6 for the heck of it, but that didn't make a difference (and by the way, it appears it doesn't hold anaconda up any more). Using Stijn's python snippet above, I was able to hack a change to our kickstart so that it uses python to do the mount and it worked! So, at least there's a workaround until a more permanent fix is found. Here's what I did -- in place of a single mount command in the %pre script: cat << EOF >> /tmp/mountit.py import sys sys.path.append('/usr/lib/anaconda') import isys isys.mount('hostname:/path', '/tmp/ks-mnt', 'nfs', 1); EOF python /tmp/mountit.py
I'm disappointed to see this bug has not gotten any attention, especially now we're mid-life in Fedora 8. Is there anything I can do to contribute to come up with a resolution? I can confirm it's broken and the Python mount workaround works. Thanks!
I would say it should be fixed right now, so that works again for F9 installs!
Is this any better in F9 Beta (not quite released yet - but should be coming soon)? We are no longer using our own mount code - we're just using the regular system mount and mount.nfs programs to handle this stuff for us. So any problems that remain should be a lot easier to fix now. Let me know.
It looks like this problem has been fixed; at least from the installation shell I can now use a regular mount command to mount the share (albeit with an mtab error that's probably harmless here): sh-3.2# mount -o nolock linux:/export/linux /linux Can't set permissions on mtab: Operation not permitted sh-3.2# ls /linux | wc -l 25 I haven't yet updated our kickstart environment to include the rest of F9 so I can't yet validate it on automatic install.
OK, our kickstart environment is now also updated and I can confirm that simply using mount -o nolock linux:/export/linux /linux using the released Fedora 9 Beta DVD files works again from within %pre in the kickstart file. It would be nice to have the permissions on mtab error fixed as well though; as it is we can't do error checking after the mount because the command now always exits with status 1. However that is a separate bug and a minor quibble ;-)
If you add -n to your mount arguments, it won't try to read or write /etc/mtab (which is a symlink to /proc/mounts in the boot image) and you'll get proper return values.
Thanks Chris, that helps!