Bug 497293

Summary:	allocatePartitions extended partition handling needs work
Product:	[Fedora] Fedora	Reporter:	Hans de Goede <hdegoede>
Component:	anaconda	Assignee:	David Lehman <dlehman>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	11	CC:	rmaximo, rvykydal, vanmeeuwen+fedora
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-08-28 16:01:40 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 Hans de Goede 2009-04-23 08:51:05 UTC

Description of problem:
There are various issues with allocatePartitions extended partition handling.

1) It will remove pre-existing non empty ext. partitions without scheduling
   a destroy action

2) Imagine the following:

1. empty disk, custom part.
2. users adds 4 partitons
3. user changes his mind goes back to 3 partitions

Now we will have a create action for an extended partition from storage/partitioning.py:599, but no matching destroy action from when the user changed his mind -> boom

Comment 1 Radek Vykydal 2009-04-23 09:29:01 UTC

(In reply to comment #0)
> Description of problem:
> There are various issues with allocatePartitions extended partition handling.
> 
> 1) It will remove pre-existing non empty ext. partitions without scheduling
>    a destroy action
> 

I think we are removing pre-existing ext. partitions only explicitly with delete,
being pre-existing, they are not handled implicitly in allocatePartitions.

> 2) Imagine the following:
> 
> 1. empty disk, custom part.
> 2. users adds 4 partitons
> 3. user changes his mind goes back to 3 partitions
> 
> Now we will have a create action for an extended partition from
> storage/partitioning.py:599, but no matching destroy action from when the user
> changed his mind -> boom  

Yep, this is a catch.

Comment 2 Hans de Goede 2009-04-23 10:09:07 UTC

(In reply to comment #1)
> (In reply to comment #0)
> > Description of problem:
> > There are various issues with allocatePartitions extended partition handling.
> > 
> > 1) It will remove pre-existing non empty ext. partitions without scheduling
> >    a destroy action
> > 
> 
> I think we are removing pre-existing ext. partitions only explicitly with
> delete,
> being pre-existing, they are not handled implicitly in allocatePartitions.
> 

My bad, that should have read:
1) It will remove a pre-existing empty ext. partitions without scheduling
   a destroy action

Notice the change from "non empty" -> "empty"

Comment 3 Bug Zapper 2009-06-09 14:27:10 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 4 David Lehman 2009-08-28 16:01:40 UTC

Fixed in anaconda-12.16-1.