Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 5536

Summary: Can't find previous RedHat install (6.0)
Product: [Retired] Red Hat Linux Reporter: Steve Tate <stephenrtate>
Component: installerAssignee: Jay Turner <jturner>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-10-20 16:38:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Steve Tate 1999-10-04 23:12:01 UTC
I tried to do an upgrade to 6.1, and while I have a fairly
straightforward RedHat 6.0 installation, the partition setup
is a little funky -- my root partition is /dev/hda7, and
when it gets to the part where it looks for the previous
RedHat installation it gives an error message about mounting
/dev/hdd1 (which is actually half of a RAID-0 setup), and
then bombs out with some python exceptions.

If there was a way I could *tell* it where the old
installation was, all would be cool, but I don't see any way
to do that...

Comment 1 Ian Macdonald 1999-10-04 23:15:59 UTC
See also bug #5511. These are definitely related.

Comment 2 Steve Tate 1999-10-05 20:16:59 UTC
I have a workaround for this now, but it's a bit ugly because there
are in fact TWO problems!  First, when looking for the previous
install, anaconda tries to mount anything that is labeled as a ext2
partition --- and if the mount fails the exception stops the install
cold.  That seems like a huge overreaction to me -- if the mount
fails, you should just ignore the partition.  With my RAID-0 striping,
it failed the mount, but that's not a big deal -- that's obviously not
my root partition, so it should just ignore it and go on.

The work-around:  relabel (temporarily) all such partitions as
something obscure (I used "amoeba") so they are ignored.

Unfortunately, that didn't fix my problem because there is a second
problem caused by a bug in the anaconda code.  In particular, there's
a case statement where a "break" is missing, so NTFS partitions are
mistakenly identified as ext2 partitions!  So the mount once again
fails, and the exception stops the upgrade. I'll send a patch that
fixes this, but for now the workaround is the same as before:
temporarily relabel the NTFS partition(s) to something other than NTFS
or ext2, and then try again...

Comment 3 nd 1999-10-05 21:30:59 UTC
See also <a href="
id=5555&BUGLIST=5555">bug #5555</a> for more info on this.  It
appears to affect all systems with existing NTFS *AND* HPFS (OS/2)
partitions.  This is probably because (I think) NTFS and HPFS utilize
the same partition ID type.

Comment 4 Jay Turner 1999-10-20 16:38:59 UTC
Discarding as bug contains information also found in #5555 and #5511;
see those bugs for more information