Bug 5536 - Can't find previous RedHat install (6.0)
Can't find previous RedHat install (6.0)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-04 19:12 EDT by Steve Tate
Modified: 2015-01-07 18:38 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-10-20 12:38:42 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 Steve Tate 1999-10-04 19:12:01 EDT
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 19:15:59 EDT
See also bug #5511. These are definitely related.
Comment 2 Steve Tate 1999-10-05 16:16:59 EDT
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 17:30:59 EDT
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 12:38:59 EDT
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.