Bug 6558 - python crashes while installing with boot-RHEA-1999:044.img
Summary: python crashes while installing with boot-RHEA-1999:044.img
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 6.1
Hardware: i386
OS: Linux
high
high
Target Milestone: ---
Assignee: Jay Turner
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-10-31 03:58 UTC by johna
Modified: 2015-01-07 23:39 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2000-02-24 14:21:58 UTC
Embargoed:


Attachments (Terms of Use)

Description johna 1999-10-31 03:58:59 UTC
The boot-RHEA-1999:044.img file was used to create a boot
floppy to perform an install (not upgrade) of 6.1 over top
of an existing 6.0 system.

A graphical install from hard drive (/dev/hda1) was selected
using installation type = custom system. The path to the
RedHat directory was entered without a terminating '/'
character. There are no non-RPM files in the rpms directory
as proven via "ls -a | grep -v rpm". I have rebuilt the RPM
database on the existing 6.0 system. The install was told to
reformat all the existing ext2 filesystems (so it shouldn't
even be looking at these partitions). In one install
attempt, /dev/hda2 and /dev/hda3 were allegedly removed and
replaced with a single swap partition. All partitions are
formatted as per their fstab entry.

====

cat /etc/fstab looks like:

/dev/hdb1       /               ext2
defaults                        1 1
/dev/hda2       /spare          ext2
defaults                        1 2
/dev/hda3       swap            swap
defaults                        0 0
/dev/fd0        /mnt/floppy     vfat
noauto                          0 0
/dev/cdrom      /mnt/cdrom      iso9660
noauto,ro                       0 0
none            /proc           proc
defaults                        0 0
none            /dev/pts        devpts
mode=0622                       0 0
/dev/hda1       /dos/c          vfat
exec,dev,suid,rw,umask=000      0 2
/dev/sda1       /dos/d          vfat
exec,dev,suid,rw,umask=000      0 2

====

fdisk -l looks like:

Disk /dev/hda: 255 heads, 63 sectors, 1027 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1       992   7968208+   b  Win95
FAT32
/dev/hda2           993      1011    152617+  83  Linux
/dev/hda3          1012      1027    128520   82  Linux swap

Disk /dev/hdb: 255 heads, 63 sectors, 525 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hdb1             1       525   4217031   83  Linux

Disk /dev/sda: 64 heads, 32 sectors, 1033 cylinders
Units = cylinders of 2048 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/sda1             1      1032   1056752    c  Win95
FAT32 (LBA)

====

The python error happened after the install displayed the
text dialog box containing "Reading package information...".
The python dump follows:

Traceback (innermost last):
  File "/usr/bin/anaconda.real",
line 255, in ?
    intf.run(todo, test = test)
  File
"/tmp/lib/python1.5/site-packages/te
xt.py", line 1000, in run
    rc = apply(step[1](), step[2])
  File
"/mnt/redhat/comps/install/6.1/i386/
misc/src/trees/hdimage/usr/lib/pytho
n1.5/site-packages/textw/packages.py
", line 10, in __call__
  File
"/tmp/lib/python1.5/site-packages/to
do.py", line 930, in getHeaderList
    self.hdList =
self.method.readHeaders()
  File
"/tmp/lib/python1.5/site-packages/ha
rddrive.py", line 45, in readHeaders
    isys.umount("/tmp/hdimage")
  File
"/tmp/lib/python1.5/site-packages/is
ys.py", line 8, in umount
    return _isys.umount(what)
SystemError: (16, 'Device or
resource busy')

====

This python error prevents 6.1 from being installed.
Thankfully, the attempt at re-partitioning did not actually
happen at the time the installer looked like it was writing
to the disk, or I wouldn't be able to create this bug report
right now.

This bug may be related to any or all of 5545, 5551, 5555,
5615, 5618, 5638, 5691, 5741, 5749, 5768, 5875, 5931, 6033,
and 6159.

Comment 1 Jay Turner 1999-11-01 14:44:59 UTC
You state that you were performing a graphical hard drive
installation, but the hard drive installation is not supported in
graphical mode.  Could you please provide details of how you are
performing a graphical hard drive installation, as this might help me
to replicate your problem as well as reach some resolution for it.

------- Additional Comments From   11/01/99 10:56 -------
On the initial boot floppy screen it says:

o  To install or upgrade a system running Red Hat Linux 2.0
   or later in graphical mode, press the <ENTER> key.

So I pressed the <ENTER> key. I always assumed that it would switch
from being text mode to graphical mode at some point in the install
process, just as installs for Windows and OS/2 do. I have never
reached the point where it actually was graphical.

If you say that hard disk installs are never graphical, then that
would explain why it was always in text mode, but perhaps it indicates
that the text in the first screen of the boot floppy should be
changed.

I will retry the install but this time typing in "text" at the boot
prompt.

------- Additional Comments From   11/02/99 00:25 -------
I have now tried both text mode and expert mode (with no additional
device drivers). Both fail in exactly the same way as the original
"graphical" attempts at installation.

Comment 2 Richard Horinek 1999-11-22 06:45:59 UTC
I have had the same problem.  I have tried all updated boot images including
bootnet and pcmcia and updates.  I have reverified all files three times using
three different ftp sites.  I have used the text command line and without it.
I've tried updating existing or installing new as Gnome or Custom or KDE.  I
always get the exact same message.  I have tried installing on four different
machines.  All four are currently running RedHat 6.0, in tandem with either
Windows 95, 98 or 98SE.  My inclination has been that the symbolic links in the
RedHat install directory are not all there.  I am fairly new to Linux and have
not had any luck trying to add these links by hand.  All four installs have been
hard drive installs or network installs using ftp.  I have a 30 meg swap file
and at least 850 meg / directory specified on all attempts.  I've also tried
using a ramdisk as large as 48 megs but it made no difference.

Comment 3 lwayne 1999-12-03 06:58:59 UTC
I also have the same problem.  (This means I am unable to install
Red Hat Linux on my computer.)

Here is how I got to the python error (which killed the
Red Hat installation).  I tried to install RH 6.1 via
ftp.  My computer is a Compaq Deskpro, with a Pentium III
chip and 192MB of RAM.  Windows NT 4.0 was previously
installed on one partition, and I tried to install
RH 6.1 on a separate partition.  I tried two different
boot images:  (1) I tried the standard bootnet.img that
comes with RH 6.1.  (2) I tried bootnet-RHEA-1999:044.img
in conjunction with the update

Comment 4 lwayne 1999-12-03 07:18:59 UTC
I also have the same problem.  (This means I am unable to
install Red Hat Linux on my computer.)

Here is how I got to the python error (which killed the
Red Hat installation).  I tried to install RH 6.1 via
ftp.  My computer is a Compaq Deskpro, with a Pentium III
chip and 192MB of RAM.  Windows NT 4.0 is installed on
one partition, and I tried to install RH 6.1 on a separate
partition (dual-boot configuration).  I tried two
different boot images:  (1) I tried the standard
bootnet.img that comes with RH 6.1.  (2) I tried
bootnet-RHEA-1999:044.img in conjunction with the update
updates-RHEA-1999:045.img.  I got slightly different
python errors with these two different boot images.
With image (1) I got the following "Exception occurred:"

    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 572, in __call__
       if todo.doInstall():

With boot image (2) I got the following "Exception
occurred:"

    File "/usr/bin/anaconda.real", line 225, in ?
        intf.run(todo, test=test)
    File "/tmp/updates/text.py", line 1009, in run
        rc=apply(step[1](),step[2])
    File "/tmp/updates/text.py", line 572, in __call__
        if todo.doInstall():
    File "/tmp/updates/todo.py", line 1517, in doInstall
        self.inst(allback,p)

Comment 5 jay beatty 1999-12-19 02:23:59 UTC
I get this same error on a hard disk install. The error occurs on SDA6, which is
an NTFS partition.  As these guys, I'm using the new boot images downloaded
today from the updates.redhat.com site. The boot.img still seems to think that
NTFS partitions are ext2.

Jay

Comment 6 paradis 1999-12-28 22:38:59 UTC
I also received the error:
"/tmp/lib/python1.5/site-packages/is
 ys.py", line 8, in umount
     return _isys.umount(what)
 SystemError: (16, 'Device or
 resource busy')

This is the first time Linux is being installed on my system.  It has 1 drive
with 1 partition (FAT16), with NT 4.0 currently as the only boot.  I'm trying to
add RedHat 6.1 as a second boot on the same drive.  I'm installing from the hard
drive.  I checked to make sure I do not have any non .rpm files in the RPMS
directory.  I also used the latest boot images (boot-RHEA-1999_044.img and
updates-RHEA-1999_045.img).

By the way, you should change the instructions on the main install screen to say
that the graphical interface is not supported during an install from the hard
drive.  It doesn't give a new user, like myself, a pleasant feeling when you're
misguided right from the start.

At this point I'm giving up and will try 6.0.

Comment 7 paradis 2000-01-04 18:24:59 UTC
I gave the 6.1 hard drive install another chance now that I have some more
experience from installing 6.0.  I found the following 3 steps necessary before
the 6.1 install finally worked for me:

1) Make sure there are no files without the .rpm extension in the RPMS directory
2) If ftp'ing the install files to your system, make sure all files are
transferred in binary mode.  I had used CuteFTP and it incorrectly transferred
indexhtml-6.1-1.noarch.rpm in ascii mode, so I turned off auto detect mode.
3) Use the updated install images, boot-RHEA-1999_044.img and
updates-RHEA-1999_045.img.

Comment 8 johna 2000-01-04 19:35:59 UTC
Thank you for the clue.

I suggest that everybody go to their .../RedHat/rpms directory and run the
command:

rpm --checksig --nopgp *

When I do this in my 6.0 directory, everything shows up as "size md5 OK". When I
do this in my 6.1 directory, everything shows up as "size md5 GPG NOT OK".

The file zlib-devel-1.1.3-5.i386.rpm shows up in both 6.0 and 6.1, but it is
larger in the 6.1 directory.

It looks like ALL the files I downloaded were transferred in ASCII mode. Since I
have been using the same ftp tool for several years (to download 5.1, 5.2, 6.0,
and 6.1) with no upgrades or option changes, I suspect that the files were
corrupted at the mirror. Of course since I downloaded back on Sep 27 and I don't
remember which mirror I used, I have no way to verify this.

It is interesting to note that the Python installer failed with a umount error.
Perhaps the installer should be modified to run a sanity test of the rpms to
check for corruption before attempting installation.

I will re-download everything and report back.

Comment 9 johna 2000-01-19 05:53:59 UTC
Well, as should have been guessed by the lack of comments, this wasn't it
either. I tried downloading with 3 different ftp programs, including bare ftp. I
tried downloading selected files from 9 different mirrors. Every result was the
same. rpm would always say "size md5 GPG NOT OK".

Either every mirror on the list managed to mess up their transfers from the main
RedHat ftp server, or else the 6.0 rpm does not understand 6.1 RPM packages. It
sure would be nice if someone from RedHat would actually read the bug reports
and comment on what the output of rpm should be, and if the mirrors are okay.

One final point about the downloads. The disk images were also copied during the
same bulk download as the RPM packages. If the RPMs were transfered as ASCII
files, then the disk images should have been as well, yet the disk images boot
fine.

What more can I try? Wait until 6.2?

Comment 10 jay beatty 2000-01-25 02:30:59 UTC
Do we have any response on this? I've worked around it on my other machines by
 finding a way to install off the cdrom. But now I'm stuck with an older laptop
 that doesn't have a cd-rom. I've tried to the new pcmcia and bootnet. Both
generate the same exection in the "Package Groups" screen - starting with
File "usr/bin/anaconda.real", line 225, in ?
              intf .run(todo, test = test)

It looks like at least some of the problems in 5618 (lockem) and 5691
are the same.
  Is there any way to install 6.1 without the cdrom??

Comment 11 Jay Turner 2000-02-22 14:33:59 UTC
OK, I am coming up blank on this one, but there is one last idea that I have of
what is going on.  By any chance are you mounting the hard drive partition (the
source partition that is) in Disk Druid?  So, say you are installing from
/dev/hda6 (so the source files are there) and then in Disk Druid, you choose to
mount /dev/hda6 as "/mnt/src" or something similar, then you will get an error
message similar to above, as the device really is busy and therefore the
installer is not able to unmount it.

Comment 12 Jay Turner 2000-02-24 14:21:59 UTC
Closing out this bug, as I am 99% sure that the partition was getting mounted in
Disk Druid and that is what was causing the problem.  The issue will be resolved
in the next release, so users will again be able to set mount points for the
source partition of a hard drive installation.

Comment 13 johna 2000-02-24 15:46:59 UTC
I don't seem to be logged in right now, so this is johna

Yes, I had told the installer that I wanted /dev/hda1 installed on /dos/c. I
have done this with every install from 5.0 on up and never experienced any
problem. Note that in every install, the system would NOT create this mount
point in /etc/fstab so I have always had to add this point manually.

Note in my earlier comments that I had the exact same problem while running the
installer in expert mode. I was under the impression that Disk Druid was not
used in expert mode.


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