Bug 40456
Summary: | install failure during copy | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | ken joerden <joerden> |
Component: | anaconda | Assignee: | Brent Fox <bfox> |
Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-06-15 15:39:37 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
ken joerden
2001-05-14 01:38:22 UTC
What kind of install were you doing? (cdrom, nfs, etc?) Also, did you go to VC2 and go in the /mnt/source directory? I was doing a CD install from a floppy start. I was in text mode as the GUI also failed (I don't recall for sure, but I believe the mouse detection failed and it wouldn't accept the 'busmouse' selection). I did browse the other VCs, but didn't see anything I felt was helpful. The copy stopped at about 2/3 of a 1300Mb selection (I remember seeing something above 800Mb completed). Regards, Ken I think that you might have gone into the /mnt/source directory on VC2, which is the directory that the cd was mounted in. When the installer needs to switch to disc 2, it has to unmount disc1 first. However, if something else is accessing the device (such as bash on VC2), then it can't unmount the device because it is currently in use. Try the install again without looking on any of the VC's. Does this help? Failed the same and I avoided VCs. After the stop the messages looked like the last time so I passed on the 'save'. When I oked the install progress screen scrolled up and the following was visible:install exited abnormally -- recieved signal 9 sending termination signals...done sending kill signals...done disabling swap... /tmp/swap/sda5 unmounting filesystems... /mnt/sysimage/boot /mnt/sysimage/proc /mnt/sysimage/usr umount failed () /mnt/sysimage umount failed () /mnt/runtime /mnt/source /dev/pts /proc You may safely reboot your system I am running on a Adaptec 2930 with 2 2Gb drives and a NEC 4X CD. the drives are partitioned via Druid /dos 160Mb /dev/sda1 /boot 20Mb /dev/sda2 swap 80Mb /dev/sda5 / 1800Mb /dev/sda6 /usr 2069Mb /dev/sdb1 Hope this helps. Regards, Ken Try booting with 'linux ide=nodma'. Does that help? Also remember to avoid going into the /mnt/source directory on VC2. Success!!! At least we got passed the 2nd CD. I couldn't get X configured so it was ok. I went back and repeated the setup within the install several times with different setting for resolution and card settings. I was never offered the #9 9FX Motion771 PCI 4Mb card I am using, I just saw a S3 968 X server and used various 8, 16, true resolutions and my NEC XV15 monitor. I want to run 1024x768xtruecolor. I retried also after the reboot, so it looks like I need a little guidence here also. Thanks and regards, Ken P.S. Please accept my apologies if I am duplicating here, this morning when I executed the login, my message disappeared and I wasn't sure if it went or not. Can you run Xconfigurator after reboot? Does that seem to help? I'm going to close this bug since the problem with anaconda crashing seems fixed, but feel free to keep responding to the bug and I'll try to help you with your video card. Yes Xconfigurator works from the #, but acts the same as when it ran during install. I see some response from the test start and it is covered instantly by the 'There is a problem with your X configuration. Cancel (or) Back. I also tried XFree86, but it couldn't be found (I haven't yet tried to dig for it in X11Rxx or elsewhere). Before I broke my 6.1 (id 0c55873cc6b3f6d5) install trying a 7.0 upgrade (from Sams Unleashed), X was ok so I know the card/monitor combination should be operable. When the 6.1/7.0 broke I decided to move on to a clean install of 7.1 since it was eminent. Just as an aside does my 6.1 extend my support? Thanks and regards, Ken I have 'solved' the X problem. I tried to 'startx' just to see what might happen. After it failed, I saw a message that said the mouse was busy or not there. I ran 'top' to find the process id for gpm and 'killed' it the Xconfigurator then ran fine and so did X. However, I have to 'kill' it on every restart. I'll chase this later. I had to manually configure the 3c509B, but got networking and printing (IP not SMB)to my W2k server back up. So, I am back to the dial networking problem that got me from 6.1 to 7.x in the first place. I can see the modem (Motorola ModemSurfer 33.6 external on /dev/ttyS0) with minicom (clean OK to any command), but get a 'modem not responding' from Dialup Configuration at debug (with init1 ATZ or AT&F) or actual dial attempts. I have browsed all the FAQs I can find, the DOC CD, 'linmodem sites' etc. If you can offer any suggestions, I'd sure appreciate it. I had hoped to accept full closure on this dialogue from within my running 7.1 configuration, but such is life. Regards, Ken Just a quick post script. The first debug attempt was as discribed and I said, 'self, here we go again'. However, I tried again and dialed and connected. Many, many addtional attempts have failed as discribed including with power cycle resets. I don't give up easily. Thanks again, Ken You might be interested in joining the seawolf mailing list...it's a group of Seawolf users that could probably help more than I could. If you go to https://listman.redhat.com/mailman/listinfo/seawolf-list, you'll see a subscription form there. Just thought you might be interested. *** Bug 44599 has been marked as a duplicate of this bug. *** Ok, I guess I'm a little slow here, when anaconda fails it is not a bug and I really do have a good install?? Let me explain...the original bug was caused by a kernel problem. The kernel tries to use DMA transfers for IDE devices if they can support it. Most devices that can't support DMA transfers fall back properly to a lower transfer speed. Some devices don't fall back properly, and they can operate strangely (or not at all). This is a problem that the kernel team is aware of and has addressed in recent builds. I closed the original bug report once booting with 'linux ide=nodma' caused the installer to stop crashing. This boot option will tell the kernel to avoid using DMA transfers, thus avoiding the problem. You are correct, however...the bug should not be resolved as 'NOTABUG', but rather as "RAWHIDE". That was a mistake on my part. Resolving properly as rawhide. |