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>), 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 ?
Please try this on an update disk (just format a floppy as ext2 and copy this file on it), then boot with 'linux updates'.
Created attachment 73749 [details] Try this on an update disk
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).
Could you please try the final 8.0 release now its out - it has the update in it.
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.
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
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
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?
Closing due to inactivity, please reopen if you have additional information to add.
somehow I missed the Additional comment by msf 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.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.