Red Hat Bugzilla – Bug 352451
anaconde pre-installation environment unable to mount NFS shares
Last modified: 2008-03-28 09:57:04 EDT
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
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.
Steps to Reproduce:
Set up kickstart environment with NFS mount in %pre.
Mount will not go through.
A mounted NFS file system.
using python, and anaconda's isys module, I can succesfully mount the same
share. From the installation environment shell, starting python:
isys.mount('linux:/export/linux', '/linux', 'nfs', 1)
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?
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
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
The funny thing is that problems seem to appear even when
connecting to portmapper using IPv4 address (and not
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
isys.mount('hostname:/path', '/tmp/ks-mnt', 'nfs', 1);
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.
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
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
mount -o nolock linux:/export/linux /linux
using the released Fedora 9 Beta DVD files works again from within %pre in the
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
Thanks Chris, that helps!