Bug 497293 - allocatePartitions extended partition handling needs work
allocatePartitions extended partition handling needs work
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-23 04:51 EDT by Hans de Goede
Modified: 2009-08-28 12:01 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-28 12:01:40 EDT
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 Hans de Goede 2009-04-23 04:51:05 EDT
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 05:29:01 EDT
(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 06:09:07 EDT
(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 10:27:10 EDT
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 12:01:40 EDT
Fixed in anaconda-12.16-1.

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