Bug 5555 - Upgrade to 6.1 fails to detect previous installation
Upgrade to 6.1 fails to detect previous installation
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
6.1
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-04 22:16 EDT by nd
Modified: 2015-01-07 18:38 EST (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-10-20 14:43:05 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 nd 1999-10-04 22:16:31 EDT
Several people have confirmed a bug discovered in the Red
Hat Linux 6.1 installation program (both GUI and text mode).
When choosing the "Upgrade" option in installation, it gives
an error message: "Error mounting ext2 filesystem on hdXX:
Invalid argument.  /dev/hdXX is not a ext2 partition".  On
the partitions it gives, it is indeed not a ext2 partition
-- so the problem appears to be that it doesn't find the
VALID ext2 partition on the drives.  After the error message
anaconda just sits there indefinitely with a "Searching for
Red Hat Linux installations" dialogue.  Upgrading seems
almost impossible.

All people who reproduced it were upgrading to 6.1 from 6.0
(not that it should matter).  On my system I have 2 hard
drives, with Linux on /dev/hda3 (hda1=windows).  hdb is just
an OS/2 (HPFS) partition.  Note that Red Hat tried to treat
a /dev/hdb partition as an ext2 partition.

Suggestions: Try different partition arrangements with other
filesystems to reproduce the bug.  Add an installation
command line option to SET where your ext2 partition is (in
case Anaconda is unable to find it for some reason).  At
least then people like me (and the others) could get around
this.

------- Additional Comments From   10/05/99 05:01 -------
I've had the same problem upgrading from a Redhat5.2/WinNT dual-boot
system with the following partition layout:

hda1	id 83 (ext2) 		Linux native (root partition)
hda2	id 7  (OS/2 HPFS)	WinNT NTFS
hda3	id 5  (Extended)	(contains other Linux paritions)

The graphical upgrader fails when "Searching for Red Hat
installations..." with the message "Error mounting ext2 filesystem on
hda2: Invalid argument"

The text-based upgrader fails with the same mesage as the graphical
system: "Error mounting ext2 filesystem on hda2: Invalid argument".
But using the text installer provides some Python stack information
(I've had to retype this, so there may be a few minor typos in
captialization, punctuation, and white space):

Traceback (innermost last):
File "/usr/bin/anaconda", line 225 in ?
	intf.run(todo, test=test)
File "../../../RedHat/instimage/usr/lib/site-packages/text.py", line
1000 in run
	rc = apply(step[1](), step[2])
File "../../../RedHat/instimage/usr/lib/site-packages/text.py", line
222 in __call__
	parts = todo.upgradeFindRoot()
File "../../../RedHat/instimage/usr/lib/site-packages/todo.py", line
1130 in upgradeFindRoot
	isys.umount('/mnt/sysimage')
File "/usr/lib/python1.5/site-packages/isys.py", line 8, in umount
	return _isys.umount(what)
SystemError: (22, 'Invalid argument')

------- Additional Comments From   10/05/99 12:19 -------
It seems to be a bug in one of the python packages
(_balkanmodule.so?) which the installation script is using to read the
partition table. The type returned from the package is 2 for both
NTFS and ext2 partitions!. The installation script looks for type 2
since it tries to mount all ext2 partitions. Of course it fails for
NTFS partitions. Note that HPFS partitions look the same as NTFS in
partition table, so it may happen with HPFS as well.
Bolek
bolek@netcene.com


------- Additional Comments From   10/07/99 03:32 -------
I have the same error on this simple disk:
/dev/hda3 as ext2 partition
/dev/hda1 as fat32 partition (WIN98)
Regards

------- Additional Comments From   10/10/99 13:40 -------
It seems like Redhat 6.2 doesn't check if the Linux partition is on
any partition with a number higher than 4. My Redhat 6.0 is installed
on /dev/hda6 and 6.1 upgrade doesn't find it. After installing a test
Redhat 6.0 to /dev/hda3 the installer upgrades this one. What do
people do who have two Redhat versions on their system?

------- Additional Comments From   10/10/99 14:06 -------
  I've also been unable to perform an upgrade from 6.0 to 6.1 on ANY
(2) of the systems I've tried.  Both systems had both IDE and SCSI
disks with the Linux installation on the SCSI disks.  Python traceback
and all other symtoms are identical to those already discussed.
Comment 1 matts 1999-10-13 20:55:59 EDT
Same problem. I have NTFS on /dev/sda and /dev/sdb1. My ext2 is on
/dev/sdb3. Cannot upgrade. Would be nice if I could indicate to the
install program that my ext2 is on /dev/sdb3.

------- Additional Comments From   10/14/99 03:01 -------
Not Only the missing break for NTFS/HPFS in anaconda/balkan/dos.c
causes the upgrade to abort. This source file does not know that
Microsoft invented a new type for extended partitions. These days
we not only have 0x5 but also 0xf (which Linux fdisk calls Win95 Ext'd
(LBA). The RedHat installation mistakenly thinks this is a DOS
partition. Instead all checks made with DOSP_TYPE_EXTENDED/5 must be
extended to also include 0xf as a type for exended partitions. To my
knowledge this new partition type is used for harddisk greater than
8gb and not only Windows uses it but also Partition Magic from
Powerquest.
So as a workaround one not only has to change the id of NTFS/HPFS
partitions (of course only temporarily to for example 0xa7) but also
must set extended partitions with type 0xf to have type 0x5.
Comment 2 dschommer 1999-10-14 14:22:59 EDT
Although this may be overkill, I will add my two cents.  I two have
found this bug upgrading 6.0 to 6.1.  I recieve the same error
message(s) in both text and graphic mode.

/dev/sda1 = WinNT
/dev/sdb1 = Linux (REDHAT 6.1)

Just wanted to make sure it was known that SCSI disks are effected as
well (although it might have been obvious, just making sure).
Comment 3 matts 1999-10-14 19:25:59 EDT
Just to confirm that a workaround reported 10/14/99 03:01 works. I
booted from my existing install using linux single, ran fdisk and
changed my NTFS partiitions to type a7. Rebooted to the 6.1 CD and ran
the upgrade without a problem. Rebooted to 6.1 linux single and used
fdisk to change the partition types for NTFS back to normal. Edited my
lilo.conf (as it lost the dual boot config) and re-ran /sbin/lilo.
Rebooted and all works fine now. Thanks for the workaround!
Comment 4 Jay Turner 1999-10-20 14:43:59 EDT
We will be releasing an errata update image which solves this problem
the week of October 18.
Comment 5 bertrand 1999-10-27 08:07:59 EDT
I have post another bug report (with the new installation images
#6328). I have two systems, OS/2 (Warp 4) and Linux (6.0):

sda5, extended partition OS/2
sda6, extended partition OS/2
sda7, extended, ext2
sda8, extended, HPFS
sda9, extended, ext2
...

	The first partition that the installer
tries mount is a HPFS partition and the installer
crash. The errata uptade image does not fix this
bug.

	I read that it be possible to set the
ext2 partition in a command line option. Can you
explain, please?

	Best regards,

	JKB
Comment 6 bertrand 1999-10-27 08:09:59 EDT
I have post another bug report (with the new installation images
#6328). I have two systems, OS/2 (Warp 4) and Linux (6.0):

sda5, extended partition OS/2
sda6, extended partition OS/2
sda7, extended, ext2
sda8, extended, HPFS
sda9, extended, ext2
...

	The first partition that the installer
tries mount is a HPFS partition and the installer
crash. The errata uptade image does not fix this
bug.

	I read that it be possible to set the
ext2 partition in a command line option. Can you
explain, please?

	Best regards,

	JKB

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