Bug 49615 - Installer
Summary: Installer
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-21 17:09 UTC by greg hosler
Modified: 2007-04-18 16:34 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-10-01 16:01:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description greg hosler 2001-07-21 17:09:55 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.3-2.9.2smp i686)

Description of problem:
Apparently, depending upon the packes selected, and the network
setup, when the "post install configuration" meter reachs 100%, it might be
up to 4 or 5 minutes before you get the "create floppy" panel.

This excessivly long wait seems to occur when DNS is set to a "not yet
DNS (such as, or local IP number), and when a large number of
are selected (e.g. select alot of "individual packages")

I note that if DHCP is selected for the network, then there seems to not be
a long wait.

How reproducible:

Steps to Reproduce:
1. select "custom install"
2. set up network with private IP numbers, and DNS to
3. go into individual mode, and select most packages

I have not been able to figure out which packages are at fault, but a fair
number are definately doing hostname lookups and timing out.

The novice user, and even the advanced user will give up after maybe 1
After some 20 installed, different install configurations, I finally came
to the conclusion
that "if I wait, it will come back". I had to wait in excess of 4 minutes
for my custom install to come back to the "create floppy" screen.

Actual Results:  4 minute hang.

Expected Results:  It _really_ should not be hanging. Whatever hostname
lookups shouldn't be done
as part of installation. Frequently you take your system off the
lan/network to do the install, or you are going to setup a caching
nameserver (so the DNS hasn't even
been configured yet), and hostname lookups just won't work.

Additional info:

Comment 1 Glen Foster 2001-07-23 21:17:52 UTC
This defect is considered SHOULD-FIX for Fairfax.

Comment 2 Matt Wilson 2001-07-24 03:41:49 UTC
the name lookup is a requirement for proper /etc/hosts configuration.

Comment 3 greg hosler 2001-07-24 12:12:40 UTC
It seems to me that something is amis, and you're refusing to even acknowledge
that there is
an issue here.

Depending upon which packages, and how many packages I select, this timeout I am
you at will take from 10 secs, to 30 secs, to 1 minute to 4 or 5 minutes, and if
you do an
"everything install" it will probably take 7 to 10 minutes. This is on a P3-933,
with 512MB ram,
so you know there is no swapping, no thrashing issues.

Also, because the delay is variable, and depends upon which packages, it is also
obvious that
this timeout is happening MORE THAN ONCE.

While I can appreciate your assertion that "name lookup is a requirement for
proper /etc/hosts configuration", I hasten to point out that if instead of
giving a DNS IP number of a yet to be configured DNS server, I defaulted to
Dynamic IP service (and mind you I am on a network
without any DHCP server running), there is ZERO delay in the post install
configuration stage, 
WITH EXACTLY THE SAME PACKAGE SELECTION. So don't write this off as "name lookup
a requirement" because CLEARLY IT IS NOT, proven by setting up the network w/ a
NON-EXISTANT Dynamic IP service.

I appreciate the fact that you wish to close bugs, but there is something amis,
and you're
pretending that you're not even considering the possibility.

During installation, it is probably the case that there shouldn't even be any
hostname lookups...
And if infact there needs to be, then there ought to be some pop-up warning
message that
such-and-such hostname is failing to resolve properly when the lookup times out.
(This will
at least clue the user in that he/she has some post-boot work needing to be

Comment 4 Michael Fulbright 2001-09-17 21:43:38 UTC
Brent please try to reproduce.

Comment 5 Brent Fox 2001-09-18 20:25:36 UTC
What kind of install were you trying?  cdrom, hard drive, network, etc?

Comment 6 greg hosler 2001-09-18 23:07:05 UTC
Installation notes:
custom installation, from cdrom(s), to scsi hard disk (neither of which are
The hang will vary depenging upon the selection of packages. Many network
services selected, inclufdng NIS (with self as the NIS server). In network
setup, "local assigned IP" is selected (as opposed to DHCP assigned), and DNS is
set to self (which is to say it is not configured 'till after
reboot - I run a local caching name server). I suspect that this last is
important. It "feels" as though
some packages are doing hostname lookups as part of their post-install, and this
is timing-out.
I have not identified the packages, but in multiple trys to pinpoint this, I
noted that certain large selection of packages will breeze right thru, and other
selections will hang for up to 8 minutes.
As I recall (and I have not tried this lately), if I configure the network setup
to DHCP, I do not see
the hang (even though there is no DHCP server available) - this should be
re-confirmed as I am
no longer positive about this.

Comment 7 Brent Fox 2001-09-19 15:29:34 UTC
I did a cdrom install with the latest tree, setting the DNS to and
didn't notice any lag at all.  I don't know where the delays you are seeing are
coming from.  
When you are noticing the lag, can you look on VC4 and see if there are any
messages related to the cdrom?

Comment 8 Brent Fox 2001-10-01 16:01:20 UTC
Any more information here?

Comment 9 greg hosler 2001-10-06 05:28:51 UTC
I just did an fresh install of enigma. The delay that used to be immediately
after "post install configuration" and before "create boot floppy" no longer
seems to be there. Perhaps this was fixed in one of the beta's / rc's since the
original report. I'm satisfied that this is closed. If I see it in the next
round, I'll gather more info, and open a new bugzilla.


Comment 10 Brent Fox 2001-10-15 21:39:46 UTC
Ok.  Thanks for working with us on this issue.

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