During install, I chose to partition manually with Disk Druid, but this didn't work out for a couple of reasons: 1. I wanted to repartition hde and leave hdg alone, but anaconda wanted to turn hdg1 into a swap partition and format it. hdg1 is the single 13gb partition on the disk, and it's definitely type Linux, not Linux Swap. 2. I tried in vain to tell anaconda that hdg1 isn't swap. I then tried to tell it not to format the partition, and it came back with an error about the swap partition being too big. It then happily returned to "it's swap and I'm going to format it" mode.
When you went to create a new partition, there is a list of available drives. The default is to have all the drives activated, this means that the installer will try to create the new partition on the drive that currently has the most space available. I think you need to unselect the drives that you don't want to create partitions on and then click "OK". Does this help?
was this partition an ext3 partition?
*** Bug 50292 has been marked as a duplicate of this bug. ***
bfox: in that dialog, I selected hde as the only valid disk. It did create the partitions properly on hde, but it insisted that hdg1 was swap to be formatted. msw: yes, it is.
We (Red Hat) should try to fix this for the next release.
I think Matt has fixed a similar situation recently, reassigning. This needs to be a MUST fix bug, btw, since if the user proceeds their Linux data will be destroyed and reformatted as swap!
fixed in parted-1.4.16-4
I no longer have solaris x86 installed, but you guys may also want to check that the installer no longer destroys those partitions without asking. They're type 0x82, just like swap, but if you build ufs partition support into the -boot kernel it's pretty easy to tell from dmesg whether said partitions have filesystems on them. this is probably more of an interoperability issue than a showstopper, and it may/may not be worth the added kernel size.
building ufs support into the kernel isn't an option, there isn't space. The new partitioning code looks at filesystem fingerprints to decide what to do with things. It just happened that you had both a vaild ext3 filesystem and a valid SWAPSPACE2 signature in the same place. (ext[23] filesystems don't overwrite the swap signature, unfortunately). UFS is now detected the same way, so it shouldn't be turned in to swap at all.