Bug 61382

Summary: Disk Druid has troubles with partitions created with a help of fdisk
Product: [Retired] Red Hat Linux Reporter: Michal Jaegermann <michal>
Component: anacondaAssignee: Beth Uptagrafft <bhu>
Status: CLOSED WONTFIX QA Contact: Beth Uptagrafft <bhu>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: alpha   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-03-21 20:23:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michal Jaegermann 2002-03-18 21:12:59 UTC 
Description of Problem:

After a "BSD disklabel" type partition table was created with fdisk,
with all new partitions showing as either of "swap" or "ext2" kind
(not even "unused") in fdisk listings, then in the next step one is
dropped into a Disk Druid anyway in order to "edit" or, in other words,
to assign these partitions to file systems.  Somehow some of
these partitions show up as "Foreign" there and it is hard to find
a rhyme or reason why this happens in some cases but not in others.

If a person doing an installation is persistent enough then s/he may
find out that it is possible later to pick "Format partition as ...",
and that _this_ action will make such "Foreign" partition "assignable",
but I expect many to be lost on this step.

In the current state of Disk Druid using 'fdisk' is likely the simplest
and fastest way to create in all situations a correct partition table
without resorting to such tricks as using "Edit" on a "Free space".
There could be always situations when a level of control provided by
'fdisk' is required.
Comment 1 Phil Copeland 2002-05-01 02:29:31 UTC 
Difficult to track down whats going on.
I've made this into a release note

Phil
=--=