Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 88401 - Anaconda exits with signal 11 when pulling kickstart file from NFS server
Summary: Anaconda exits with signal 11 when pulling kickstart file from NFS server
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 9
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact: Mike McLean
URL: http://www.pogolinux.com/configuratio...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-09 20:25 UTC by Jesse Keating
Modified: 2007-04-18 16:52 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-04-22 20:48:44 UTC


Attachments (Terms of Use)
RHL9 kickstart config file for rackmount servers (deleted)
2003-04-09 20:29 UTC, Jesse Keating
no flags Details

Description Jesse Keating 2003-04-09 20:25:51 UTC
Description of problem:
I have setup a kickstart network, ks.cfg files live on the same NFS server as
the RHL9 install media.  I've used both the first RHL9 install CD and PXE boot
(kernel images provided on the first CD), and using the following boot command
at the syslinux prompt:

linux ks=nfs:192.168.2.3:/ks/ks9.cfg.rm

The problem is after the kickstart file is read, and anaconda tries to mount the
NFS directory where the install media is found, anaconda will receive a signal
11 quit.

Attached you will find the ks9.cfg.rm file.

If I use the first CD, in conjunction with a floppy disk, and place the same
exact kickstart file on the floppy disk, the install proceeds as expected, no
problems.

We've duplicated this issue across 2 of the same systems, but can't duplicate it
on any other system.

Specs of the system in question are:

1x p4 2.4ghz CPU w/ 533FSB
Intel 845 chipset Motherboard
2x PC2100 DDR memory
1x Seagate 120gig hdd
onboard Intel e100 network card (used for kickstart)

See URL for further details.

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


How reproducible:
Always

Steps to Reproduce:
1. boot system w/ CD or PXE
2. attempt kickstart install, ks file being on NFS server
3. watch the signal 11 happen
    

Actual Results:  Anaconda will quit with a signal 11

Expected Results:  Anaconda will continue to kickstart the system.

Additional info:

If necessary, we (Pogo Linux) may be able to send one of these systems over to
Red Hat for additional testing.  This issue kinda puts a major crimp in our
production practices.

Comment 1 Jesse Keating 2003-04-09 20:29:06 UTC
Created attachment 91047 [details]
RHL9 kickstart config file for rackmount servers

Of note, on the kickstart NFS server, the full path name to the RedHat/ tree is
/var/kickstart/ks9/  with /ks9 being a symlink to this directory.

Kickstart config files live in /var/kickstart/ and /ks is a symlink to this
directory as well.  /etc/exports has /var/kickstart/ as the share.

Comment 2 Michael Young 2003-04-16 19:46:00 UTC
We have seen the same problem; twin xeon processors, twin e1000 ethernet. If you
want to avoid the problem while it is fixed you can use http instead,
linux ks=http://website/kickstartfile
works for us with an appropriate website, with
url --url http://website/pathtorh9
in the kickstart file.

Comment 3 Michael Fulbright 2003-04-22 20:48:44 UTC
I cannot reproduce this issue on a variety of systems here. I would recommend
using http to pull your ks configs.


Comment 4 Michael Young 2003-04-22 21:42:10 UTC
In our case the NFS server was a netapps box, (the http server was via a Sun),
there was also probably a network mismatch between the router (half duplex) and
the system (full duplex). We may well try to reproduce the problem without the
network weirdness.

Comment 5 Ken Snider 2004-02-02 18:12:09 UTC
Just as a point of note, this problem is reproducable here, using
RHEL3, single Xeon (though hyperthreaded, so smp) server, e1000 nic
(IBM xserver 335).

Same bug. If we NFS/PXE install, we'll get a signal 11 right after the
drivers are loaded and it attempts to pull down the kickstart.

Comment 6 Trevin Beattie 2004-07-06 23:06:57 UTC
I'm encountering the same problem in RHEL WS3 u2 on two different
systems.  One is a Dell PowerEdge 1750 using a BCM5704 ethernet
controller (bcm5700 driver) which connects to a NetApp box.  The other
is VMware 4.5 with a virtual AMD 79c970 ethernet controller (pcnet32
driver) which connects directly to the host system.  Both try to load
the kickstart file over NFS.

Running ethereal on both of the networks shows that the SEGV fault
occurs before the kickstart file is read -- even before the NFS mount
is complete.  There is an ARP request/reply, then a series of sunrpc
packets followed by a Portmap DUMP call/reply, another pair of sunrpc
packets, a Portmap GETPORT call, another pair of sunrpc packets, the
GETPORT reply, and finally one more Portmap GETPORT call/reply.  At
that point it crashes.

I suspect the problem has something to do with the PXELinux or DHCP
configuration, because I seem to recall having the thing working at
one time...


Comment 7 Trevin Beattie 2004-07-06 23:43:41 UTC
Ha!  I found the silly cause of the problem.  The NFS server holding
the kickstart file wasn't running on either of the networks.  Fixing
that, the MOUNT call appears in between the Portmap DUMP and the first
Portmap GETPORT (on both the real system and VMware).

Perhaps the other posters on this bug could check their setups and
confirm whether NFS was running ("service nfs status")?  If that's the
case, it looks like this is simply a problem of robustness.  Anaconda
should check to see if NFS services are available on the remote
server, and if not, show an appropriate error message and either exit
gracefully or enter interactive mode.



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