On a Mitac 5033 laptop with Cyber 9385 Chipset, TEXT install. Redhat tried to use the Xserver from Xfree 3.3.6, but should be using 4.0.2. The card is well supported because I have RH 7.0 with the Xfree 4.0.2 RPMS working. Here is the trace information: Traceback (innermost last): File "/usr/bin/anaconda", line 503, in ? intf.run(todo, test = test) File "/var/tmp/anaconda-7.1//usr/lib/anaconda/text.py", line 1179, in run rc = apply (step[1](), step[2]) File "/var/tmp/anaconda-7.1//usr/lib/anaconda/text.py", line 608, in __call__ if todo.doInstall (): File "/var/tmp/anaconda-7.1//usr/lib/anaconda/todo.py", line 1773, in doInstall (p, self.intf.messageWindow, pkgTimer)) File "/var/tmp/anaconda-7.1//usr/lib/anaconda/todo.py", line 1505, in instCallback fn = self.method.getFilename(h, pkgTimer) File "/var/tmp/anaconda-7.1//usr/lib/anaconda/image.py", line 84, in getFilename isys.umount("/mnt/source") File "/mnt/redhat/test/qa0126.0/i386/RedHat/instimage/usr/lib/anaconda/isys.py", line 123, in umount rc = _isys.umount(what) SystemError: (16, 'Device or resource busy') Local variables in innermost frame: what: /mnt/source removeDir: 1 ToDo object: (itodo ToDo p1 (dp2 S'resState' p3 S'' sS'progressWindow' p4 (itext ProgressWindow (dp5 S'scale' p6 (isnack Scale (dp7 S'w' <failed>
Here is the PCI information the card. This machine uses a Trident Cyber 9385 Chipset, but here is what is reported from cat /proc/pci. The issue here is not that much with the video, but the fact that anaconda crashes. VGA compatible controller: Trident Microsystems TGUI 9660/968x/968x (rev 211). Non-prefetchable 32 bit memory at 0xfdc00000 [0xfdffffff]. Non-prefetchable 32 bit memory at 0xfe7f0000 [0xfe7fffff]. Non-prefetchable 32 bit memory at 0xfe000000 [0xfe3fffff]. Xfree 4.0.2 sees this correctly. I think your hardware probing is incorrectly configuring this card.
As to the traceback -- were you doing anything in tty2? It looks like you had cwd in the source directory so the installer was unable to unmount the source. Also, what type of install were you doing? Since the main issue is an anaconda one, changing to anaconda and giving it to msf The using 3.3.6 by default was also the case in 7.0 due to a few strange issues with the Tridents under XFree 4.x if I remember correctly
Yes I was doing something in the tty2 in that directory...so this make sense. But, ALL of the problems with Xfree 4.X and the Trident Chipsets has been fixed with Xfree 4.0.2. As I said in the last messages, I have Redhat 7.0 running with the Rawhide 4.0.2 version of Xfree. In expert mode, can I override the Xfree setup or choose not to do it? I think this might be a good idea for people that want to try the 4.X based servers.
I get a VERY similar error.. Im running a Voodoo3-2000 AGP Oh.. and I was only in / on tty2 Heres the trace.. Traceback (innermost last): File "/usr/bin/anaconda.real", line 503, in ? intf.run(todo, test = test) File "/var/tmp/anaconda-7.1//usr/lib/anaconda/text.py", line 1179, in run File "/var/tmp/anaconda-7.1//usr/lib/anaconda/text.py", line 608, in __call__ File "/var/tmp/anaconda-7.1//usr/lib/anaconda/todo.py", line 1856, in doInstal l File "/var/tmp/anaconda-7.1//usr/lib/anaconda/harddrive.py", line 179, in file sDone File "/var/tmp/anaconda-7.1//usr/lib/anaconda/harddrive.py", line 112, in umou ntMedia File "/usr/lib/anaconda/isys.py", line 123, in umount rc = _isys.umount(what) SystemError: (16, 'Device or resource busy') Local variables in innermost frame: what: /tmp/hdimage removeDir: 1 ToDo object: (itodo ToDo p1 (dp2 S'resState' p3 S'' sS'progressWindow' p4 (itext ProgressWindow (dp5 S'scale' p6 (isnack Scale (dp7 S'w' <failed>
I reran the install last night and stayed off the other tty's and it was fine. so this is not really a bug, more of an annoyance. This Redhat installer wants to eject the first CD and install things from the second CD. I was on one of the other tty's in the /mnt/source directory which happens to be the mount point for the CD. Maybe a suggestion for the installer might be is first try to unmount the CD, if that fails ask the user to make sure they are not 'in' the mount point, after that retry the unmount rather than just blowing up and killing the install. When it blows up it is a shame because the install is about 95% done at that point based upon what packages you had selected.