Bug 38428 - Installer is confused when existing Dos partition gets nuked
Summary: Installer is confused when existing Dos partition gets nuked
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Brent Fox
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-04-30 17:58 UTC by Philip Long
Modified: 2007-04-18 16:32 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-05-02 18:57:12 UTC
Embargoed:


Attachments (Terms of Use)

Description Philip Long 2001-04-30 17:58:51 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.3 i686)


I'm installing 7.1 (via ftp) on an HP Omnibook.  Previously, it had a DOS
partition, a hybernation partition, and a solaris partition.  I decided to
use expert and manually partition.  I left the hybernation partition (#2)
alone at cyl 1-37 (giving 270 MB of space). I put an ext2 partition above
that ending at cyl 1023.  I put a swap above that (1024-1299).

As the install progressed, all was well until the dialoge for the boot
loader presented itself.  It wanted /dev/hda1 to be DOS, and insisted that
the partition type was DOS/Windows7 It would not let me edit that. I
enetered linux for the lable and have my fingers crossed. 


Reproducible: Didn't try

Comment 1 Brent Fox 2001-04-30 20:13:38 UTC
I'm not really sure what problem you are reporting...can you clarify?

Comment 2 Philip Long 2001-04-30 20:58:33 UTC
Yes -- the basic problem is that the boot loader screen from the install/upgrade
menu showed exactly one entry, something like:


partition    label    type
---------------------------------------
/dev/hda1    dos      Dos/Windows


When I was expecting

partition       label     type
------------------------------------------
/dev/hda1       linux     linux native


The rest of the comments were my speculation on how that happened.  By the time
I got to the boot loader menu, I had fdisked away the previously extant windows
partition (YEAH!!!!) on /dev/hda1, and replaced it with an ext2 partition that I
had(earlier in the install process) said should be mounted at /




Comment 3 Brent Fox 2001-04-30 22:08:11 UTC
I think this problem is caused by the presence of the Solaris partition...I
don't think Disk Druid quite knows what to do...

Comment 4 Brent Fox 2001-05-01 22:37:42 UTC
I would use fdisk to remove the Solaris partition (that is, if you don't need it
anymore) and see what happens.

Comment 5 Philip Long 2001-05-02 12:44:47 UTC
The 2nd time through (when all that was on there was the ext2, hibernate, and
swap partition) it indeed worked fine.  I'm not sure if the solaris partition
had anything to do with it, though.  I know that your installation process is
polite and doesn't nuke other OSes, however evil they may be, and is set up to
put a dos option into lilo.conf.  What I observed was consistent with a check
for a dos partition before I fdisked, but not after.

Comment 6 Brent Fox 2001-05-02 18:57:07 UTC
Yes, but dos partitions are pretty easy to identify as such.  I think that our
installer might not be able to tell the difference between Solaris partitions
and Linux partitions.  I was playing around with Solaris x86 on my test machine,
and when I got tired of it, I tried to install Red Hat on the machine.  Needless
to say, weird things happened and I had to use fdisk to wipe out all the Solaris
partitions...then things worked smoothly.

I'm not sure how many people this affects, though.  Besides, Disk Druid is
designed to make partitioning easier for people in a very general case...if
you've got special circumstances with your system (like Solaris partitions),
it's usually better to use fdisk.  There's almost always a tradeoff between a
hard-to-use tool that can do lots of things (like fdisk) and an easy-to-use tool
that has a smaller feature set (like Disk Druid).

Comment 7 Philip Long 2001-05-03 03:36:03 UTC
Sorry -- I wasn't clear.  I _did_ use fdisk, and _did_ nuke the solaris off of
the machine, and did get the described problem. 

***ALSO***

Now that you mention it, there was a problem with disk druid. (I think, the
install process goes to dd after fdisk for mount points etc.)  I tried to make 
/dev/hda1 (ext2) mounted on / and it barfed (asserted no way, dude).  I'm sorry
I can't reproduce (the problem was worked around by restaring install process)
and can't recall exact details.

You are, of course, right.  If somebody has a solaris partion on the system,
they ought to be able to work around any problem.  The only issule from my POV
is to be sure that if somebody uses fdisk (not dd) to nuke the M$ partition off
of the machine (and possibly replace it with an ext2 part.), lilo.conf does not,
in general, present the menu I reported.  I don't object to bug being closed,
but I think there is more to this than we collectively understand at the moment.


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