Red Hat Bugzilla – Bug 216262
Wrong partition types displayed for entries in an extended partition
Last modified: 2008-02-12 22:45:15 EST
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
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.
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
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.