Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 352451 - anaconde pre-installation environment unable to mount NFS shares
anaconde pre-installation environment unable to mount NFS shares
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Chris Lumens
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-25 11:12 EDT by Stijn Hoop
Modified: 2008-03-28 09:57 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-28 09:40:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stijn Hoop 2007-10-25 11:12:36 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

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.
Comment 1 Stijn Hoop 2007-10-25 11:28:51 EDT
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.
Comment 2 David Lehman 2007-10-25 12:48:30 EDT
Any chance specifying "-t nfs" in the mount command helps?
Comment 3 Stijn Hoop 2007-10-26 02:28:24 EDT
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).
Comment 4 Tomasz Kepczynski 2007-11-12 04:52:51 EST
I have exactly the same problem on F8 final on x86_64.
Comment 5 Leigh Koven 2007-11-30 10:22:03 EST
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).
Comment 6 Leigh Koven 2007-11-30 10:24:57 EST
Oh, by the way, my experience is with Fedora 8 final as well.
Comment 7 Tomasz Kepczynski 2007-11-30 10:41:53 EST
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?
Comment 8 Leigh Koven 2007-11-30 10:47:24 EST
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.
Comment 9 Stijn Hoop 2007-11-30 11:14:53 EST
We use 'noipv6' as well (same reason, speeding up the kickstart process by
avoiding the timeout).
Comment 10 Leigh Koven 2007-11-30 14:45:53 EST
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
Comment 11 Chris Schanzle 2008-03-07 14:06:16 EST
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!
Comment 12 Tomasz Kepczynski 2008-03-07 14:31:26 EST
I would say it should be fixed right now, so that works
again for F9 installs!
Comment 13 Chris Lumens 2008-03-14 10:58:14 EDT
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.
Comment 14 Stijn Hoop 2008-03-28 07:16:02 EDT
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.
Comment 15 Stijn Hoop 2008-03-28 08:25:26 EDT
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 ;-)
Comment 16 Chris Lumens 2008-03-28 09:40:07 EDT
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.
Comment 17 Stijn Hoop 2008-03-28 09:57:04 EDT
Thanks Chris, that helps!

Note You need to log in before you can comment on or make changes to this bug.