Bug 433637 - stage 1 nfs mount uses insecure port (does not work on NetApp filers)
stage 1 nfs mount uses insecure port (does not work on NetApp filers)
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-02-20 10:37 EST by David Carlson
Modified: 2008-02-20 12:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-20 12:11:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Carlson 2008-02-20 10:37:25 EST
Description of problem:
mounting the nfs directory to find stage 2 doesn't work - the port that it uses
to talk to RPC is above 1024 (which I verified with wireshark), and is rejected
as insecure from NFS appliances, etc.

Thus, no fedora install or rescue can take place from a NFS server with this

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

How reproducible:
Use a method boot argument using nfs to fedora 8 boot

Steps to Reproduce:
1. boot 'method=nfs:netappfiler:/vol/someqtree' to anaconda
2. hit next, ok until it's ready to load stage 2
3. watch stage2 load fail
Actual results:
"mount: RPC: Authentication error; why = Client credential too weak"
RPC speak for "don't talk to me above port 1024"

Expected results:
straps into stage 2

Additional info:
This does work with fedora 8 NFS server as the rpc daemon doesn't care about
that.  I had talked with a NetApp engineer about this and he said it's always
checked for that.  I can remember getting to stage 2 on previous fedora releases
- this must have changed.
Comment 1 Jeremy Katz 2008-02-20 11:41:58 EST
Are you doing this inside a qemu/kvm/similar guest?
Comment 2 David Carlson 2008-02-20 12:11:33 EST
yes, i was using it through VMware.  I just realized I was using it through a
NAT interface that I had set up for PXE boot testing, and that was doing the
mangling.  Once I tried it with boot.iso and a bridged network, it worked fine.

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