Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 5618 - bootnet.img: upgrade fails with python error
bootnet.img: upgrade fails with python error
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
6.1
i386 Linux
high Severity high
: ---
: ---
Assigned To: Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-06 00:57 EDT by kreucher
Modified: 2015-01-07 18:38 EST (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-08 10:55:47 EST
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 kreucher 1999-10-06 00:57:07 EDT
when doing an upgrade from a redhat 6.0 system via ftp, i
encountered an error just before the install started to copy
files to my machine (just after "processing files"
finished). the error was a giant python error, with
something at the end about doinstall, and mount and bad type
for argument. then the install asked to debug, if i didn't
debug it just told me to reboot. i tried this twice before
giving up. i used the purdue mirror to try to install rh 6.1

------- Additional Comments From   10/06/99 09:16 -------
I have the same error using boot.img.  I autobooted off the CD, tried
using a floppy, etc. but I get a python error.  Also, when I booted
back into my 6.0 installation, fdsk complained that the disk had not
been unmounted cleanly.

------- Additional Comments From   10/07/99 21:28 -------
same error here. ne2000 pci and ftp upgrade options selected using
bootnet.img.  tried ftp.cc.gatech.edu and ftp.redhat.com, same error.
running redhat 6.0 trying to find a way to upgrade to 6.1... no luck.

------- Additional Comments From   10/08/99 12:05 -------
Same here on netinstall at ftp.tux.org. It gets to the point of
verifying packages on my machine and then errors out into reboot or
debug mode.
Comment 1 timw 1999-10-08 17:28:59 EDT
Similar problem.
The machine in question has an NTFS partition at /dev/hda1.
The Linux partition is /dev/hda5, and swap at /dev/hda6.
The installer tries to mount /dev/hda1 (why, it's the wrong type to
even attempt this), and the install errors out trying to unmount
the partition (probably because it isn't mounted).


------- Additional Comments From   10/11/99 14:35 -------
Same here from inside cisco using redhat's repository,
ftp.redhat.com/pub/redhat/redhat-6.1/i386. I get a python error about
a file not being found... if there's any interest in which file I can
regenerate the error.

------- Additional Comments From   10/18/99 18:44 -------
I have seen this on two machines, myself:

1) A machine which had 2 partitions marked ext2 in the partition table
of hda, but which were actually unformatted. Once these were
mke2fs-formatted, and manually entered into /etc/fstab, the python
script no longer burned out.

2) Another machine with everything in fstab and partition table
consistent, but /dev/hda1 is a swap partition, and there are 3 linux
partitions: /dev/hda2 (/), /dev/hda3 (/usr/local/) and /dev/hdb1
(/home).
Comment 2 Jay Turner 1999-10-20 15:53:59 EDT
We know there is a problem with upgrades on systems which have NTFS or
HPFS partitions.  This is going to be fixed in an errata released the
week of October 18th.  I also think there is a problem with partitions
which are type 83 (linux native) but which are not formatted.  Can
someone confirm?

------- Additional Comments From   10/20/99 20:28 -------
My upgrade was on a system with hda1 as windows, hda2 as swap and hda3
as linux native.  This was an upgrade using a cdrom as media.  I have
no htfs nor ntfs on my system.  These are the only partitions, they
are currently in use using RH6.0 or windows, as the case my be.  If
you need any more specific info, please let me know.
Comment 3 Jay Turner 1999-10-21 14:11:59 EDT
*** Bug 5931 has been marked as a duplicate of this bug. ***

When I upgraded my RH 6.0 machine with the (awesome)
graphic installer, I had a Linux partition yet unformatted.
When the installer searched for partitions with Red Hat
installed, this partition caused a Python error (visible by
switching the virtual console) and the installer hung.

Formatting that partition with mke2fs solved the problem,
and the upgrade completed smoothly.


------- Additional Comments From alain.richard@equation.fr  10/15/99 07:11 -------
I have had the same kind of problems with NTFS formated partitions :
mount fails (in my case because there is no NTFS module in the kernel
and in the previouly described case because the ext2 partition is
unformated).

The mount is tried during the initial localisation of a linux root
filesystem.

This bug is 100% reproductible using either graphic or text installer.

A simple fix for me was to change the partition type from 7
(HPFS/NTFS) to 17 (Hidden HPFS/NTFS) using fdisk, running the
installer/upgrader and changing back the partition
Comment 4 kreucher 1999-10-23 19:26:59 EDT
FIXED THE BUG:
i used the updated bootnet.img (which did not fix it by itself). and
when i got to the error i used Pdb or whatever to see what exactly
happened. it got stuck at line 1512 of todo.py: prob = "%-15s %d %c\n"
% (mount, need, suffix)
where:
mount = "/boot"
need = "(918,)"
suffix = "k"
then: Type Error: illegal argument type for built in operation.

i looked at the code and figured out that all it does was append the
error message to probs, which basicly said i needed 918k more free
space on /boot

SO then i rebooted and rm'ed some unneeded stuff from /boot and then
the install went ok!!

so i do not know python enough to actually correct the code. someone
help?

Nicholas J Kreucher (kreucher@msu.edu)
Comment 5 adrian.lawrence 1999-10-24 13:15:59 EDT
Problems remain with bootnet-RHEA-1999:044.img which was intended to
fix the problem. Here is the /etc/fstab from the target machine:-

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/dev/hdc1               /       ext2    defaults                1 1
/dev/hdc4               /usr    ext2    defaults                1 2
/dev/hda4               /dv0    ext2    defaults                1 2
/dev/hdb3               /dv1    ext2    rw                      1 2
/dev/hdc3               none    swap    sw
/dev/cdrom              /cdrom  iso9660 ro,noauto,user          0 0
none                    /proc   proc    defaults                1 1
none                    /dev/pts                devpts
gid=5,mode=620        0
0
/dev/hda2               /dosf   vfat    rw,uid=500,gid=500      0 0
/dev/hdb1               /dosd   vfat    rw,uid=500,gid=500      0 0
/dev/hdb5               /dose   vfat    rw,uid=500,gid=500      0 0
#/dev/fd0               /a      ext2    noauto,user             0 0
#/dev/fd1               /b      ext2    noauto,user             0 0
/dosf/dblspace.000      /dosc   vfat
loop,rw,user,cvf_format=dblspace,uid=500
,gid=500 0 0
/dosd/dblspace.001      /dosg   vfat
loop,rw,user,cvf_format=dblspace,uid=500
,gid=500 0 0
/dose/dblspace.001      /dosh   vfat
loop,rw,user,cvf_format=dblspace,uid=500
,gid=500 0 0
# ntfs is buggy at 2.2.6-ac1! Avoid
#/dev/hda3          /mnt/nt/f   ntfs    rw                      0 0
#/dev/hdc2        /mnt/nt/2nd   ntfs    rw                      0 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Notice in particular that /dev/hda3 is commented out (because of
problems with buggy ntfs driver).

bootnet-RHEA-1999:044.img crashed with the message
 Error mounting ext2 filesystem on hda3: invalid arg

And then presented a Python traceback as usual.

This was in expert upgrade mode. Surely it should only attempt to
mount uncommented compatible entries in /etc/fstab. Or rather, in
expert mode, it should consult the "expert" on the keyboard :-)
It is  surely being too clever trying to outguess/anticipate all the
possible situations to upgrade. Too much like Micro$not?
Comment 6 jstern 1999-10-24 17:42:59 EDT
I may have found a 2nd solution to one of the several bugs in the
python install/upgrade script.

(The 1st bug I worked around was also on a machine I installed via
ftp-upgrade from 6.0->6.1). That got a python script dump, too, but
was solved by finding a discrepancy between the fstab and the
partition table of the drive.  When I formatted (e2fs) the partitions
which had been marked as Linux (83) in the partition table but had
been left unformatted, and then made corresponding entries into the
/etc/fstab, then the upgrade script worked fine after that.)

The 2nd bug/solution: When upgrading via ftp from 6.0 to 6.1, I got a
long (non-cut/pasteable) python script dump.  The last two lines
(copied down by hand) were something like:

/var/tmp/python-root/usr/lib/python1.5/ftplib.py, line 201, in getresp
IOERROR: [Errno ftp error] 500 'CWD ': command not understood.

[OK]

I figured this meant that for some reason the ftp connection is having
a hard time cd'ing to the right directory, and that perhaps that might
have something to do with my supplying a final '/' on the pathname.

Working on that hunch, I re-tried the upgrade via ftp, and when I
replaced the ftp directory for upgrading, from
'/redhat/redhat-6.1/i386/' with '/redhat/redhat-6.1/i386', the upgrade
now went perfectly.

Difference of a single, terminating slash ('/').

Hope this helps.

Jeff Stern <jstern@eclectic.ss.uci.edu>
Comment 7 jstern 1999-10-24 17:45:59 EDT
I'm sorry, I forgot to mention that that last comment was based on
using the new bootnet.img, 'bootnet-RHEA-1999:044.img'.  That is, with
the latest (as of today) bootnet.img, if I supply the final '/' in the
ftp directory pathname, the script dumps out, and if I omit it, it
works fine.

Jeff Stern <jstern@eclectic.ss.uci.edu>


------- Additional Comments From   10/26/99 16:50 -------
updates-RHEA-1999:045.img has resolved the problem that I reported.
(adrian.lawrence@oucs.ox.ac.uk)

------- Additional Comments From   10/27/99 07:05 -------
I couldn't upgrade from 6.0 to 6.1 neither from network nor from
cdrom, even using the RHEA bootdisk series. Apparently anaconda tries
to mount ext2 on hda1 even if I remove it from fstab and gives me the
usual python error ...umount(what). Here follows my present fstab (all
ntfs have been removed):

/dev/hdb1               /                       ext2
defaults        1 1
/dev/hdc4               /mnt/zip                vfat
defaults        0 0
/dev/hdb2               /usr                    ext2
defaults        1 2
/dev/hdb3               /var                    ext2
defaults        1 2
/dev/hdb4               swap                    swap
defaults        0 0
/dev/fd0                /mnt/floppy             ext2
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
osfvirgo1:/usr/users4	/virgoApp	nfs	 exec,dev,suid,rw 1 1

It seems that somehow I must tell to the install program where to look
for the old installation (how to do this?) which for me is on hdb (not
hda!)

------- Additional Comments From   11/09/99 11:34 -------
I have two systems that the upgrade fails on.  Both of them use a
floppy to boot from because the Linux partition is not the first one
on the disk.

One system has Win98 in FAT32 (whole disk) that normally boots, Linux
is on a second disk.

The second system has a single disk.  First partition is HPFS
(according to Linux partitioner), then Linux swap partition, then
Linux root.  I boot this system from floppy to activate Linux, else
NT workstation will boot.  I downloaded the new boot image, but it
didn't work on this system.  It failed trying to mount /dev/hda1,
which is the NT partition.

It would appear the the upgrader is tripping over the initial, non-
Linux partitions.
Comment 8 radoje 1999-12-15 10:20:59 EST
*** Bug 7742 has been marked as a duplicate of this bug. ***

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