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 - Can't find previous RedHat install (6.0)
Summary: Can't find previous RedHat install (6.0)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 6.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jay Turner
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-10-04 23:12 UTC by Steve Tate
Modified: 2015-01-07 23:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-10-20 16:38:42 UTC


Attachments (Terms of Use)

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="http://developer.redhat.com/bugzilla/show_bug.cgi?
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


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