Bug 5672 - Hard Drive install method fails during upgrade (Device or resource busy)
Hard Drive install method fails during upgrade (Device or resource busy)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-07 02:26 EDT by opie.simons
Modified: 2015-01-07 18:38 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-10-20 16:17:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description opie.simons 1999-10-07 02:26:20 EDT
Relevant hardware- Dell PII, 64MB RAM, AHA2740, Internal
IDE, MACH64.

Completely reproducible and present from RH5.2 and on in
upgrade process at same point. Please contact me for
additional info or assistance reproducing.

Steps:
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
window.

Details are below:
Traceback (innermost last):
File "/usr/bin/anaconda.real", line 225, in ? intf.run(todo,
test=test)
File "/tmp/lib/python1.5/site-packages/text.py", line 1000,
in run rc=apply(step[1](), step[2])
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...)
Comment 1 jwang 1999-10-10 09:01:59 EDT
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 jwang@choate.edu'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
easy fix.)
Comment 2 hchcheng 1999-10-11 16:33:59 EDT
Same as a problem I reported as #5749
Comment 3 Jay Turner 1999-10-20 11:26:59 EDT
*** Bug 5804 has been marked as a duplicate of this bug. ***

Assuming / is the root directory of the
CD, /RedHat/instimage/usr/lib/python1.5/site-packages
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.
Comment 4 Jay Turner 1999-10-20 11:27:59 EDT
*** 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 jturner@redhat.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 smooge@redhat.com  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
relies on.

------- 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
directory.
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
directory.


------- 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
fails.

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.
Comment 5 sharifi 1999-10-20 12:47:59 EDT
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.
Comment 6 Jay Turner 1999-10-20 16:17:59 EDT
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 -------
From opie.simons@ey.com:

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.
Comment 7 Phil Baslington 2000-08-31 09:00:15 EDT
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.
Comment 8 Phil Baslington 2000-08-31 19:33:39 EDT
To follow up my previous post (sorry about the change of name, but I'm at home 
now)

This is the offending routine. 

   def readHeaders(self):
	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
            try:
                (h, isSource) = rpm.headerFromPackage(fd) <--- check if valid 
rpm file
            except:
                continue <---- Invalid, get the next file
            self.fnames[h] = n <--- Valid store details
            hl.append(h)
            os.close(fd) <---- close the file
		
	isys.umount("/tmp/hdimage")
	return HeaderList(hl)

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.


            except:
                print n      # Display the bad file
                os.close(fd) # close it
                continue     # get the next file
            

Note You need to log in before you can comment on or make changes to this bug.