[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: NTH Bugs for F18 Final



On Thu, 2012-12-13 at 10:41 -0500, Chris Lumens wrote:

> > (875944) shrinking Windows partition creates an unusable dual-boot setup
> >  - https://bugzilla.redhat.com/show_bug.cgi?id=875944
> 
> We're not going to be creating new shrinking UI at this point in the
> release cycle.

So I just looked at this again. It may be just me, but it may not, so in
case anyone else missed it like me: the problem here is that newUI's
non-custom shrink path gives the user no opportunity to decide the size
of the shrunk partition. It just automatically decides to shrink it to
the smallest size anaconda thinks is viable.

In oldUI, when you picked 'Shrink an existing partition' from the
'partition options' page, you got a dialog that let you pick the
partition to shrink, and the size to shrink it to.

In newUI, all you can do is pick a partition and click 'Shrink', and
anaconda then decides for you that it should be shrunk to the smallest
possible size. You can't change this.

dlehman tells me that we take the absolute minimum possible size for the
partition (as the tools report it to us) and then pad it by 'the lesser
of 10% or 500MB'.

This is clearly ridiculous for probably the most common use case -
shrink an existing Windows installation and install alongside it. If a
regular old person with Windows installed on their entire disk grabs F18
and tries to install Fedora alongside it, following the path we 'expect'
- non-custom - they will probably wind up with their Windows partition
being 500MB larger than its current contents (I guess fragmentation
plays with this, but more or less). That seems to be me to be patently
not what they'd actually want. Hell, regular old Mysterious Windows
Bloat will probably fill up that 500MB in a week or two, never mind any
actual _use_ of the OS.

So, yeah, I'm pulling a tentative AWOOGA here: I don't think this shrink
functionality is fit for purpose as-is. Many apologies for not catching
this earlier, I somehow just never quite grokked that it'd be a big
issue.

I know adding UI at this late stage is dicey, but I think partition
shrinking is fundamentally not something that can be reduced to 'do it
or don't do it'. It's not a binary operation. I can't see any way of
fiddling with the padding numbers that will give a sensible result in
all - or even most - partition resize use cases. I'm not sure we can fix
this without adding back the option to set the shrink size, and I think
we _do_ need to fix it. If anything, the alternative would be to drop
the shrink function from the non-custom path - at least then people
couldn't shoot themselves with it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]