Red Hat Bugzilla – Bug 17240
Pinstripe NFS install seems to be broken with non-Linux NFS servers
Last modified: 2008-05-01 11:37:58 EDT
Pinstripe seems to exhibit the same behaviour as in bug #9276, an install
over NFS from a Sun Solaris system hangs. A network trace of what [doesn't]
go on can be found at:
Same happens on when trying to NFS-mount from NetApp (Ontap 5.3.4R2) - mounts
from Linux NFS-server does work though. This is by the way present in Rawhide
too, though the details differ. Here's the copy of my post to pinstripe-list to
which nobody had anything to say :)
Date: Mon, 11 Sep 2000 14:27:05 +0300 (EEST)
From: "Matilainen Panu (NRC/Helsinki)" <firstname.lastname@example.org>
Subject: NFS installation from NetApp filers fails on pinstripe
Found a rather nasty (for me at least) issue with pinstripe + current
rawhide installer: it can't NFS-mount from NetApp filers at all though
installing from Linux NFS-server does work. RH6.2 has no problems with
this (install tree is world mountable as read only) at all so it's not a
problem with permissions/NetApp configuration.
Pinstripe installer would seem to get the proper information from
DHCP-server but both kickstart and manual installation over NFS fail from
NetApp. If I install from a Linux NFS-server it works just fine and then
if I try manually mounting from the shell:
#mount netapp:/xxx/yyy/path/to/rh/image /tmp/foo
mount failed - invalid argument
#mount linux:/xxx/yyy/path/to/rh/image /tmp/foo
The same happens both with a static IP and when using DHCP.
Rawhide (Aug 11) bootnet.img is a bit of a different story: DHCP only gets
an IP-address, netmask and default-gw, but no nameserver nor
kickstart-information (it just seems to dismiss them) and will then ask
for nameserver IP. But... this time it can't install from either Netapp or
Linux-NFS server :( If I give it a static IP then install works from Linux
NFS but still not from NetApp ..
BTW mounting is ok once the system is up and running - this is just during the
The bug is present also on official RH7. Bad...
Apparently related to bug 18087 and bug 17609.
Not only related but exactly the same problem. There also is a working fix
posted by email@example.com at bug 17609.
*** This bug has been marked as a duplicate of 17609 ***