Description of problem: On my laptop I had installed an old version of OpenBSD. For that installation I've created an extended partition (/dev/hda4 with type 'f') which had 4 entries - /dev/hda5-8 all with type 'a6' (OpenBSD). On the partitioning screen of anaconda (the one that lets you specify custom layout) I see /dev/hda5-8 with type "vfat". The command line fdisk utility displays the entries correctly with the type OpenBSD.
parted looks at the filesystem instead of just going with partition ids (which are really pretty meaningless). What's the output of parted on the disk?
I cannot tell anymore since I've installed RHEL already and wiped all the OpenBSD partitions. However, as I said above - the command line fdisk utility correctly recognized the partitions as OpenBSD. The filesystem on those partitions is really ufs and not vfat.
We don't have any UFS reading code for systems other than Sun and HP in parted at the moment. I'll put this on the list of things to do for parted 2.0, but it's sort of an invasive change for parted 1.8.x and the only real gain you get from it is listing the partition as 'openbsd'. We can't create, destroy, or resize UFS stuff from parted.
OK, further testing shows that we fall back on partition ID checking when the filesystem test returns nil. I have installed OpenBSD (a painful process I hope to never repeat) and then installed FC along side. The partitioning UI in anaconda reports the type of my OpenBSD partition as "OpenBSD". Now, we can't look deeper in to the OpenBSD partition. That is, we wouldn't be able to show the slices in that partition, but we do show the entire primary partition as OpenBSD. In your case, I'm guessing that even though you had a partition of type 0xA6, the filesystem check determined that the filesystem on that partition was VFAT. We always trust the filesystem test over the partition type, even in cases where they disagree. It is entirely possible for format a Linux partition as VFAT or a Mac partition type as VFAT. In those cases they will show up as VFAT partitions even though the type is something bizarre. As Jeremy indicated, the type is mostly meaningless. I have verified that you can make a type 0xA6 partition, format it as VFAT, and then anaconda shows it as VFAT. Not much we can do in this respect, so closing this as not a bug. Though you did send me down the path of finding not-very-good UFS code in parted, so we'll look at that in the future. Our primary platform of concern with parted is Linux though. Thanks.
Well, so you are basically telling me that I don't know what I am talking about. That's fine - however in the description of your test I don't see that you used the partitioning scheme described in my first comment. I.e. extended partition and inside it four OpenBSD partitions. And no - they weren't vfat. Anyway, I see that you are assuming that most people come from Linux or VFAT world so it is not something that you should bother with.
Whoops, my mistake. Forgot the _extended_ partition. But before all that, I wasn't trying to say you don't know what you're talking about. My hope with posting above was so that future users experiencing similar problems may hit some of the terms above in a Bugzilla search. Sorry it came across otherwise. I also wasn't trying to say your filesystems were VFAT even though they were UFS. I was trying to say _they passed the VFAT filesystem test_. Whatever we are doing to check to see if it's a VFAT filesystem, that's returning true for the OpenBSD partition on an extended partition setup. Knowing now that it was an extended partition, we definitely fall through and say it's VFAT if all the other tests fail. That's wrong and lazy. I remember adding that catchall because some systems reported the extended partitions as something other than a Windows filesystem even when it was a Windows filesystem. Reopening this bug.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
I have tried to reproduce this on the latest RHEL and rawhide trees we have and I can't make it happen again. I have created an extended partition of type 0x0f and then four logical drives inside that extended partition with type 0xA6. They are correctly reported as 'OpenBSD' in anaconda now. Closing this as RAWHIDE because I think other changes that have gone in to parted have fixed this bug.