Red Hat Bugzilla – Bug 40456
install failure during copy
Last modified: 2007-04-18 12:33:12 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Description of problem:
Traceback (innermost last):
File "/usr/bin/anaconda", line 520, in ?
intf.run(todo, test = test)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/text.py", line 1126, in run
rc = apply (step(), args)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/text.py", line 551, in
if todo.doInstall ():
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/todo.py", line 1852, in
(p, self.intf.messageWindow, pkgTimer))
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/todo.py", line 1564, in
fn = self.method.getFilename(h, pkgTimer)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/image.py", line 87, in
.py", line 140, in umount
rc = _isys.umount(what)
SystemError: (16, 'Device or resource busy')
Local variables in innermost frame:
Actual Results: install stopped 'contact bugzilla'
Expected Results: install should continue
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).
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
/mnt/sysimage/usr umount failed ()
/mnt/sysimage umount failed ()
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.
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,
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,
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.
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.
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.