Bug 72917 - post-install hang when dns configured?
post-install hang when dns configured?
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
:
Depends On:
Blocks: 67218
  Show dependency treegraph
 
Reported: 2002-08-28 20:29 EDT by greg hosler
Modified: 2007-04-18 12:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:49:31 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)
Try this on an update disk (36.18 KB, text/plain)
2002-08-29 12:12 EDT, Michael Fulbright
no flags Details

  None (edit)
Description greg hosler 2002-08-28 20:29:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Description of problem:
boot "boot.img" from floppy (because mb does not support usb booting) with disc
1 in usb cdrom. cdrom properly detected after system boots, and install
continues normally, until the "post install" - at post-install, system locks up
tight.

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


How reproducible:
Always

Steps to Reproduce:
1.see above
2.
3.
	

Actual Results:  failed install

Expected Results:  should not lock up. should finish install

Additional info:

I tried switching to vc2 and issuing "umount /proc/bus/pci" prior to the 
post-install (suggested by Michael Fulbright <msf@redhat.com>), but this has no
effect. system still locks up tightly.

This USED to work. I believe it worked in beta 1. I know it worked in Valhalla.
I can't remember which beta this stopped working in (beta 2 or beta 3).

I chose a simple install path ("Personal Workstation"), and everything installed
properly, up to the "post-install"

is there any way to tell what's going on when the system hangs ?
Comment 1 Michael Fulbright 2002-08-29 12:11:13 EDT
Please try this on an update disk (just format a floppy as ext2 and copy this
file on it), then boot with 'linux updates'.
Comment 2 Michael Fulbright 2002-08-29 12:12:32 EDT
Created attachment 73749 [details]
Try this on an update disk
Comment 3 greg hosler 2002-08-29 19:24:19 EDT
hmm. having difficulty here...

I formatted a floppy as e2fs, mounted, copied the file, umounted /dev/fd0. then
I booted with "updates". I got the "insert the updates floppy and press return"
prompt, and did so. When I clicked OK, I get the following error messages:

GUI : Failed to mount floppy disk
VC3 : UPDATES floppy device is fd0
VC4 : <3>EXT2-FS: corrupt root inode, run e2fsck

I switch to VC2. I do

           e2fsck /dev/fd0

it says:  /dev/fd0: clean

I can create a mount point and mount the floppy, without problem.

           mkdir /mnt/floppy
           mount /dev/fd0 /mnt/floppy
           ls /mnt/floppy
           packages.py
           umount /mnt/floppy

not sure what to try from here.

(note: I am booting from the "boot.img" floppy, though I do not think that this
makes a difference).

Comment 4 Michael Fulbright 2002-10-03 13:47:06 EDT
Could you please try the final 8.0 release now its out - it has the update in it.
Comment 5 greg hosler 2002-10-04 10:52:46 EDT
still fails.

I just completed a custom install. some 2500mb, 50 minutes off a USB cdrw reader.
completes the last package. then the progress meter bar comes up for
"post-installation". go part way, part way more, then fill way across, and then
the system locks solid. can not get to a vc. must press reset.

will test "minimal install" tomorrow, to see if the results are any different.
Comment 6 greg hosler 2002-10-05 01:20:14 EDT
hmm... interesting...

I just completed about a dozen "minimal" installs, varying a few of the
install parameters. I can force a success, or force a failure. it's completely
reproduceable, depending upon the installation configuration options.

and the most interesting thing was that the usb cdr was a red herring. I
switched to the usb cdr at about the same time that whatever bug this is was
introduced. Sheer coincidence. I am able to get successful installs on the
usb cdr, again depending upon the install configuration options.

Below are the results of a dozen installs. all are variations on the first.
The term "success" means that I get to the "create boot disk panel" (at that
point I reboot to try another variation). The term "fails" means that when the
"performing post install configuration" progress bar hits 100%, the system
totally freezes.

I am suspecting that the network configuration is related to this freeze. it
*IS* 100% reproduceable.

base install (subsequent installs will have difference in
installation options compared to this set of install options):

boot option:	linux
Intro Screen	<next>	
Lang Screen	<next>	
Kb Screen	<next>	
Mouse Screen	<next>
Install type	Custom	
		<next>	
Partition
manual disk druid. Select 1 large partition for /
Format
	<next>  
Boot Loader	<next>	
Network cards	<next>	(2 cards eth0/eth1) configured for DHCP)
F/W
	No FW	<next>
Lang
	<next>	
Timezone
<next>

Root PW		Enter root pw	 <next>	
Auth
	<next>	
Packages
Minimal
<next>

Info
	<next>	

Result:
success

-----------

redo with the following change (from base):

boot option:	linux resolution=1024x768

Result:
	success

-----------

redo with the following change (from base):

boot option:	linux lowres

Result:
	success

-----------

redo with the following change (from base):

boot option:	linux lowres

 - in diskdruid allocate /boot and / partitions
 - set time zone properly

Result:
	success

-----------

redo with the following change (from base):

boot option:	linux lowres

 - in network config:

   eth0	      192.168.0.2/255.255.255.0
	      Active on boot
   eth1	      DHCP
	      not active on boot
   hostname   tomboy
   no gateway
   no dns

Result:
	success

-----------

redo with the following change (from base):

boot option:	linux lowres

 - in network config:

   eth0	      192.168.0.2/255.255.255.0
	      Active on boot
   eth1	      DHCP
	      not active on boot
   hostname   tomboy.nanocube.localdomain
   gateway    192.168.0.1
   dns	      192.168.0.1

 - Auth

   NIS
	nis domain GDH
	do NOT use broadcast
	nis server lugs.nanocube.localdomain

Result:
	Fail

-----------

redo with the following change (from base):

boot option:	linux lowres

 - in network config:

   eth0	      192.168.0.2/255.255.255.0
	      Active on boot
   eth1	      DHCP
	      not active on boot
   hostname   tomboy.nanocube.localdomain
   gateway    192.168.0.1
   dns	      192.168.0.1

Result:
	Fail

-----------

redo with the following change (from base):

boot option:	linux lowres

 - in network config:

   eth0	      192.168.0.2/255.255.255.0
	      Active on boot
   eth1	      DHCP
	      not active on boot
   hostname   tomboy.nanocube.localdomain
   gateway    <empty>
   dns	      <empty>

Result:
	Success

-----------

redo with the following change (from base):

boot option:	linux lowres

 - in network config:

   eth0	      192.168.0.2/255.255.255.0
	      Active on boot
   eth1	      DHCP
	      not active on boot
   hostname   tomboy
   gateway    192.168.0.1
   dns	      192.168.0.1

Result:
	Fail
Comment 7 greg hosler 2002-10-05 01:54:00 EDT
two more data points (in reference to the prior set of installations). From
these, I would guess that there is an issue with the DNS IP in the post-install
code.


-----------

redo with the following change (from base):

boot option:	linux lowres

 - in network config:

   eth0	      192.168.0.2/255.255.255.0
	      Active on boot
   eth1	      DHCP
	      not active on boot
   hostname   tomboy
   gateway    none
   dns	      192.168.0.1

Result:
	fail

-----------

redo with the following change (from base):

boot option:	linux lowres

 - in network config:

   eth0	      192.168.0.2/255.255.255.0
	      Active on boot
   eth1	      DHCP
	      not active on boot
   hostname   tomboy
   gateway    192.168.0.1
   dns	      none

Result:
	Success

Comment 8 Michael Fulbright 2002-10-24 16:49:21 EDT
I've changed the topic for this bug.

So if I understand you correctly, if you set the DNS to be 192.168.0.1 then the
install hangs during the post-install stage?

Is 192.168.0.1 really a DNS server?
Comment 9 Michael Fulbright 2002-12-02 11:09:01 EST
Closing due to inactivity, please reopen if you have additional information to add.
Comment 10 greg hosler 2002-12-02 12:51:06 EST
somehow I missed the Additional comment by msf@redhat.com on 2002-10-24 16:49:21

Yes, 192.168.0.1 really is a DNS server. really.

I am happy to leave this as closed, and see how anaconda deals with this
situation on GinGin, and file a new bug (or reopen this one) if the problem
still persists. (been out of town for the past 2 weeks, so did not get a chance
to test GinGin yet.
Comment 11 Red Hat Bugzilla 2006-02-21 13:49:31 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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