Bug 61382 - Disk Druid has troubles with partitions created with a help of fdisk
Summary: Disk Druid has troubles with partitions created with a help of fdisk
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.3
Hardware: alpha
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Beth Uptagrafft
QA Contact: Beth Uptagrafft
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-03-18 21:12 UTC by Michal Jaegermann
Modified: 2007-04-18 16:41 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-03-21 20:23:53 UTC
Embargoed:


Attachments (Terms of Use)

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
=--=


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