Hide Forgot
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. ***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.