Red Hat Bugzilla – Bug 38428
Installer is confused when existing Dos partition gets nuked
Last modified: 2007-04-18 12:32:55 EDT
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
I'm not really sure what problem you are reporting...can you clarify?
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 /
I think this problem is caused by the presence of the Solaris partition...I
don't think Disk Druid quite knows what to do...
I would use fdisk to remove the Solaris partition (that is, if you don't need it
anymore) and see what happens.
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.
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).
Sorry -- I wasn't clear. I _did_ use fdisk, and _did_ nuke the solaris off of
the machine, and did get the described problem.
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.