This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 216262 - Wrong partition types displayed for entries in an extended partition
Wrong partition types displayed for entries in an extended partition
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: parted (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
Brock Organ
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-18 03:48 EST by Pavel Tsekov
Modified: 2008-02-12 22:45 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-12 22:45:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Pavel Tsekov 2006-11-18 03:48:37 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.
Comment 1 Jeremy Katz 2006-11-28 12:58:07 EST
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?
Comment 2 Pavel Tsekov 2006-11-28 15:27:37 EST
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.
Comment 3 David Cantrell 2006-12-01 16:37:47 EST
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.
Comment 4 David Cantrell 2006-12-01 16:56:26 EST
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.
Comment 5 Pavel Tsekov 2006-12-02 01:55:41 EST
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.
Comment 6 David Cantrell 2006-12-02 09:29:33 EST
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.
Comment 7 RHEL Product and Program Management 2007-10-19 16:32:47 EDT
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.
Comment 12 David Cantrell 2008-02-12 22:45:15 EST
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.

Note You need to log in before you can comment on or make changes to this bug.