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.
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).
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.
*** 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 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
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)
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?
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.uci.edu>
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.uci.edu> ------- Additional Comments From 10/26/99 16:50 ------- updates-RHEA-1999:045.img has resolved the problem that I reported. (adrian.lawrence.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.
*** Bug 7742 has been marked as a duplicate of this bug. ***