Bug 21202 - Signal 9 during install of "dev" package
Signal 9 during install of "dev" package
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Brock Organ
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-21 15:49 EST by redhat-bugs
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-20 19:15:09 EST
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 redhat-bugs 2000-11-21 15:49:01 EST
While trying to kickstart a machine using the 7.0 (boxed, RedHat
Professional Server) CDROM I get the following messages during the
installation of the "dev" package:

---------- cut ----------
Install exited abnormally -- received signal 9
sending termination signals...done
sending kill signals...done
disableing swap...
unmounting filesystems...
/mnt/sysimage/boot
/mnt/sysimage/proc
/proc/bus/usb
/mnt/sysimage
/mnt/runtime
/mnt/source umount failed (16)
/dev/pts
/proc
you may safely reboot your system
---------- cut ----------

I am using the following boot command:

linux updates ks=floppy

and using a floppy with the following ks.cfg file:
---------- cut ----------
lang en_US
cdrom
keyboard us
lilo --location mbr
part /boot --onpart hda2
part swap --onpart hda3
part / --onpart hda5
mouse none
timezone US/Pacific
rootpw xxxxxx
auth --enablemd5 --useshadow

%packages
@ Network Server
---------- cut ----------

I am also using the anaconda update that is available for 7.0.

The machine I am installing on has the following pre-existing partition
table:
---------- cut ----------
major minor  #blocks  name     rio rmerge rsect ruse wio wmerge wsect wuse
running use aveq

   3     0    9965592 hda      41 0 268 340 6 0 42 0 0 340 340
   3     1    4096543 hda1     0 0 0 0 0 0 0 0 0 0 0
   3     2      16065 hda2     7 0 14 20 1 0 2 0 0 20 20
   3     3      64260 hda3     0 0 0 0 0 0 0 0 0 0 0
   3     4          1 hda4     1 0 2 20 0 0 0 0 0 20 20
   3     5    1020096 hda5     32 0 250 290 5 0 40 0 0 290 290
  22     0     654848 hdc      148 1547 6774 8570 0 0 0 0 -17 289510
-4903770
---------- cut ----------

and the install.log from the target machine although it is not at all
surprising:
---------- cut ----------
Installing setup.
Installing filesystem.
Installing basesystem.
Installing glibc.
Installing chkconfig.
Installing mktemp.
Installing termcap.
Installing libtermcap.
Installing bash.
Installing anacron.
Installing apmd.
Installing ncurses.
Installing info.
Installing fileutils.
Installing grep.
Installing ash.
Installing at.
Installing authconfig.
Installing bc.
Installing bdflush.
Installing bind-utils.
Installing bzip2.
Installing sed.
Installing mingetty.
Installing gawk.
Installing e2fsprogs.
Installing procps.
Installing popt.
Installing logrotate.
Installing sysklogd.
Installing psmisc.
Installing which.
Installing vixie-cron.
Installing modutils.
Installing shadow-utils.
Installing initscripts.
Installing textutils.
Installing XFree86-libs.
Installing zlib.
Installing XFree86-xfs.
Installing cracklib.
Installing words.
Installing cracklib-dicts.
Installing pwdb.
Installing db3.
Installing glib.
Installing pam.
Installing SysVinit.
Installing chkfontpath.
Installing console-tools.
Installing cpio.
Installing crontabs.
Installing cyrus-sasl.
Installing db1.
Installing db2.
Installing dev.
---------- cut ----------

Any ideas?

b.
Comment 1 Bill Nottingham 2000-11-22 00:40:46 EST
Most likely, the install kernel oopsed; that's pretty much the only way the
installer gets SIGKILL.

Comment 2 redhat-bugs 2000-11-22 01:54:49 EST
Hmmmm.  There was no evidence of an oops on any of the VCs.

What now?
Comment 3 Michael Fulbright 2000-11-22 12:13:22 EST
Passing to QA to reproduce.
Comment 4 redhat-bugs 2000-11-23 15:26:14 EST
I don't mean to push, but any idea how long QA will take to reproduce?  I only
ask because I need to decide whether I can sit tight and wait or if I need to
figure something else out.

If you have any suggestions at all that I can do to help out please just let me
know.
Comment 5 Brock Organ 2000-12-04 14:18:35 EST
hmmm ... this seems likely to be hardware specific, as I cannot reproduce the
problem in our test lab using generic equipment ...

what hardware do you have in your system ...?
Comment 6 redhat-bugs 2000-12-04 20:52:50 EST
Bah!  I hate that.

The exact details of the machine can be found at

http://www.e4me.com/infocentral/product_etower600is.html

minus the [win]modem and add at least one Linksys LNE100TX, details at:

http://www.linksys.com/products/product.asp?prid=31&grid=10

Mine are the version 4.1 cards, needing the updated tulip.o driver package from
Donald Becker's netdriver package.
Comment 7 Brock Organ 2000-12-18 10:52:30 EST
unfortunately, we do not have this specific hardware in our test lab ... we have
not seen this problem with similar class machines in our lab ... :(

also, I have almost this machine @ home (a 500 Mhz celeron emachines for
personal use), and though I've not done a kickstart install onto it, I've not
had any other problems with installing Red Hat Linux 7 onto it ... do you also
have this problem with an interactive (ie non-kickstart) install ...?  Have you
seen this problem occur similarly on different hardware ...? (I am wondering if
this incident is not a single possibly faulty machine)
Comment 8 redhat-bugs 2000-12-19 02:11:08 EST
No, an interactive install works just fine.  I suspect that there is something
about my kickstart recipie that is causing the barfage.  Actually I think likely
it has something to do with the part where I have the disk pre-partitioned and
tell the kickstart what to do with those partitions rather than letting
kickstart create them.

What do you think of that hypothesis?
Comment 9 Michael Fulbright 2000-12-27 12:36:09 EST
Could you try having the installer allocate one of the partitions and see if it
helps?
Comment 10 redhat-bugs 2001-01-05 13:52:08 EST
But if the machine I am installing to has other OS(es) on it, along with some
paritions that I want the installer to install into, how will it know not to
write into the partitions of the other OS(es)?
Comment 11 redhat-bugs 2001-01-16 19:31:21 EST
I solved it!!

The problem is simply one of not enough memory.  The machine I am installing
onto only has 32MB of memory.  You could not really have installed onto the same
class of machine (memory plays heavily into replicating a "class" of machine
IMHO) as you say above or you would have come across the same problem wouldn't
you have?

Anyway, I added a 128MB stick of memory and the install went fine.

This seems to be only a Kickstart issue and not a general installer issue. 
Why?  Because when used interactively, the installer notices that the amount of
memory is low and requests that swap be mounted immediately to compensate.  It
would seem that the installer does not do the same during a kickstart.  It
should, no?  Why not if you think it shouldn't?
Comment 12 redhat-bugs 2001-01-20 13:50:47 EST
Is anything going to be done with the additional information I have provided?  I
have worked around the damn problem!  Some acknowlegement of what permanent
fixes will be put in place would be nice.
Comment 13 Michael Fulbright 2001-02-15 12:01:23 EST
For your original case you had 32M of RAM and 64M of swap?
Comment 14 redhat-bugs 2001-02-15 12:20:31 EST
Yes, 32MB of memory, 64MB swap.
Comment 15 Brock Organ 2001-02-20 15:32:14 EST
> The problem is simply one of not enough memory.  The machine I am installing
> onto only has 32MB of memory.  You could not really have installed onto the 
> same class of machine (memory plays heavily into replicating a "class" of 
> machine IMHO) as you say above or you would have come across the same problem 
> wouldn't you have?

You're right.  I had more memory in the system (64 Mb) ... We are working to
have more efficient resource usages in future releases of anaconda ... 

Comment 16 redhat-bugs 2001-02-20 19:15:05 EST
Don't be so quick to close the bug.  :-)  The interactive mode of the installer
deals with this issue by mounting the swap partition very early in the install
if it detects a low memory configuration.

Why not have the kickstart mode of the installer do the same?
Comment 17 Michael Fulbright 2001-02-27 13:16:50 EST
Kickstart was designed for use on server machines primarily, which always have
enough RAM to work.

We do not plan to change this behavior at this time.

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