Relevant hardware- Dell PII, 64MB RAM, AHA2740, Internal
Completely reproducible and present from RH5.2 and on in
upgrade process at same point. Please contact me for
additional info or assistance reproducing.
Boot using boot.img
<enter> for GUI install
[screens go by]
select partition and path using values of /dev/hda5
(internal IDE) and /redhat-6.1/i386.
[RAMDISK is loaded, begins searching etc.]
Problem message: Exception Occurred on Examine System
Details are below:
Traceback (innermost last):
File "/usr/bin/anaconda.real", line 225, in ? intf.run(todo,
File "/tmp/lib/python1.5/site-packages/text.py", line 1000,
in run rc=apply(step(), step)
File "/tmp/lib/python1.5/site-packages/text.py", line 251,
in __call__ todo.upgradeFindPackages (root)
File "/tmp/lib/python1.5/site-packages/todo.py", line 1147,
in upgradeFindPackages self.getCompsList()
File "/tmp/lib/python1.5/site-packages/todo.py", line 942,
in getCompsList self.getHeaderList()
File "/tmp/lib/python1.5/site-packages/todo.py", line 930,
in getHeaderList self.hdList=self.method.readHeaders()
File "/tmp/lib/python1.5/site-packages/harddrive.py", line
45, in readHeaders isys.umount("/temp/hdimage")
File "/tmp/lib/python1.5/site-packages/harddrive.py", line
8, in umount return _isys.umount(what)
SystemError: (16, 'Device or resource busy')
------- Additional Comments From 10/09/99 13:24 -------
I have the same problem- Gateway pii/300 256mb with hda-10gb ide, hdb
8gb ide, hdc-cdrw, hdd-cd.
I go to debug, type 'what' and it says .... /tmp/hdimage (i'm not sure
about the tmp, but I am about the hdimage...)
I've isolated this problem. Please see bug #5804. It has to do with
the packaging and the MS-DOS filesystem. MS-DOS is not case
sensitive with filenames, and (Redhat
dir)/RedHat/instimage/usr/lib/python1.5/site-packages has two files
named GTK.py and gtk.py. You'll see these if you open up the ISO.
However, DOS chokes on the file names and so the installer can't find
one of the files and dies.
------- Additional Comments From 10/11/99 12:55 -------
True to firstname.lastname@example.org's comments, the RedHat 6.1 directory tree was
on a DOS partition.
Additional info: Originally ftp'd RH 6.1 to Linux on ext2 partition
case sensitive partition. Tarred directory to carry it to target
machine so I should've have 'lost' any files due to
case-insensitivity. To prepare for original upgrade, I untarred to
partition of choice. Originally, it was a DOS FAT16 partition using
IDE. As a test, I untarred to an ext2 partition on SCSI.
Results: Same error message as originally stated. It appears my
problem is not related to bug #5804. (Too bad. It would have been an
Same as a problem I reported as #5749
*** Bug 5804 has been marked as a duplicate of this bug. ***
Assuming / is the root directory of the
contains two files, GTK.py and gtk.py. However, because
the MS-DOS filesystem is not case-sensitive, all
installations from a MS-DOS partition fail because the
installer does not find one of these two files.
*** Bug 5711 has been marked as a duplicate of this bug. ***
I have downloaded the RedHat - directory for 6.1 as
recommended in the readme-file from FTP server and also
files on top-level directory. I've burned them completely on
CDROM because I don't want to install from partition -
besides: it's going to be installed on another machine.
As booting from floppy, the installer starts but then
doesn't accept the files on CD - why? The other way round:
Why do you provide all files on servers if they don't work?
possibly it's only an error during FTP!
------- Additional Comments From email@example.com 10/11/99 11:12 -------
Unable to replicate in test lab. Am able to install from mastered cd
here in the lab.
------- Additional Comments From firstname.lastname@example.org 10/11/99 16:52 -------
From what I can tell from similar posts this problem is most likely
the GTK.pyu gtk.py problem that happens on cd's mastered from a
download to a windows box.
This problem is due to case-indiference in windows box which Unix
------- Additional Comments From 10/17/99 06:37 -------
I have the same problem, but in this case it is because I need to
install from a FAT32 hard drive partition (Sony C1F notebook: USB
floppy drive, so I cannot load the PCMCIA floppy)
I burned a CD using Joliet extensions to preserve the filenames, in
order to xcopy it to a spare partition under Win98.
However, in RedHat\instimage\usr\lib\python1.5\site-packages, there
are files "GTK.py" and "gtk.py" which cannot coexist in a Windows
IMO this is a serious bug, as it makes the "install from hard drive"
option pretty much useless. I cannot proceed now without hacking
python code :-(
Brian Candler <B.Candler@pobox.com>
------- Additional Comments From B.Candler@pobox.com 10/17/99 06:46 -------
I should add that the problem was not with making the CD, but with
copying it to the Windows machine (where it thought that two files on
the CD had the same name).
This problem would therefore also occur with the other "traditional"
way of getting round problems with install media, i.e. using
DOS/Windows FTP to fetch the installation files into a local
------- Additional Comments From 10/20/99 12:21 -------
When I originally created this report, I had ftp'd from the website
directly onto an ext2 filesystem under RH6.0 which is case-sensitive.
I then copied it to an MS-DOS filesystem which is case-insensitive and
would have the "GTK.py vs gtk.py" problem.
However, after learning of the problem, I *copied the original*
downloaded directory to an ext2 (case-sensitive) partition and tried
to reinstall again with the same results. In summary, ftp'd to
case-sensitive and then installing from a case-sensitive partition
Is there a way to get more debugging information from the installer
during this process? The installer is basically saying that the
partition is mounted cannot be unmounted.
It is possible that you have the same problem as Bug#: 5551.
" remove all files other than *.rpm from the RPMS directory. If you
used WS_FTP, ws_ftp.log is probably the file you are looking for."
------- Additional Comments From 10/20/99 12:58 -------
I saw that one too and looked at it. I used ncftp from rh6.0 command
line and do not get the same error message as that mentioned for
#5551. Ncftp does not create log files as WS_FTP does.
Issues in this bug are covered by bug #5555, #6159 and #5711, so I am
discarding this bug to prevent clutter. Please refer to the above
bugs for updates.
------- Additional Comments From 10/20/99 18:14 -------
The three bugs mentioned above do not share the same symptoms of the
report I have entered. In addition, one of the bugs has been marked as
a duplicate of this one though it is not (#5711).
Again, I am *NOT* having a problem with GTK.py and gtk.py. I *AM*
having a problem with the installer not unmounting a partition. This
bug report should not be discarded yet as it is not resolved.
------- Additional Comments From 10/21/99 08:53 -------
Not a problem with GTK.py vs. gtk.py, as I have downloaded everything
into an ext2 file system and still get the same result.
I have the same problem. It appears to be a bug in harddrive.py, this reads
through the files in the RPM directory, for each file it finds it opens the
file and attempts to read information from the file, if it is succesfull it
closes the file and goes on to get the next one. However if it fails to read
the correct information from the file it simply goes on to process the file,
it does NOT close it. Therefore when a attempt is made to dismount the file
structure these files are still open.
To follow up my previous post (sorry about the change of name, but I'm at home
This is the offending routine.
isys.makeDevInode(self.device, '/tmp/' + self.device)
isys.mount('/tmp/' + self.device, "/tmp/hdimage",
fstype = self.fstype);
hl = 
path = "/tmp/hdimage" + self.path + "/RedHat/RPMS"
for n in os.listdir(path):
# no gurantee on suffix - do a copy onto msdos filesytem from
# linux and you don't get .rpm
# if (n[len(n) - 4:] == '.rpm'):
fd = os.open(path + "/" + n, 0) <--------- open the file
(h, isSource) = rpm.headerFromPackage(fd) <--- check if valid
continue <---- Invalid, get the next file
self.fnames[h] = n <--- Valid store details
os.close(fd) <---- close the file
Any file that is not valid is left open, this seems to agree with all the
evidence. ie:corrupt rpm files, non rpm files.
I think the except statment should be somthing like this.
print n # Display the bad file
os.close(fd) # close it
continue # get the next file