Blocker status of RHBZ #1033778 (shrinking unknown volumes)

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


Hi folks! So as promised on IRC here's a mail to discuss this issue. is proposed as a
release blocker. As I understand it, dlehman is strongly of the opinion
that it shouldn't be accepted, on technical grounds. However, it does
constitute a fairly clear violation of the release criteria.

The bug - as I understand it - is that a particular type of partition
("Apple Core Storage" volumes, whatever those are) appears as "Unknown"
in anaconda, and the guided install workflow (the "Reclaim Space"
screen) allows you to try and resize it. If you do this, it fails to
work at all and causes complete loss of all data on the partition.

The Final release criteria state:

"Any installer mechanism for resizing storage volumes must correctly
attempt the requested operation."

with a footnote:

"This means that if the installer offers mechanisms for resizing
storage volumes, then it must run the appropriate resizing tool with
the appropriate parameters for the resize the user chooses. The reason
it's worded this way is we specifically don't want to cover cases where
the requested resize operation then fails for some reason - dirtily
unmounted or over-fragmented partition, for instance. We only want to
cover the case that the installer's resize code itself is badly

It seems pretty inarguable that as the criteria currently stand, this
bug violates them, and thus it should be a Final release blocker.
However, we delayed the decision at this week's blocker review meeting
since we were aware you folks might want this not to be a blocker.

For clarity, if it were to be accepted as a blocker, this would not
mean that anaconda would be required to resize such partitions
successfully, nor does it necessarily imply that anaconda must be able
to *recognize* such partitions. So far as the blocker process is
concerned it would be a sufficient resolution if *either* anaconda
attempted to resize such partitions 'appropriately' (I'm not sure if
that is even possible) *or* refused to attempt to resize them. The
criteria do not, I think, place any effective restrictions on exactly
*how* the latter resolution could be effected.

So, I guess the question is: do we think the criteria should stand as
written but this bug be rejected, and if so on what grounds? Do we
think the criteria should be adjusted to reflect some kind of technical
restriction? Or do we in fact think the bug should be accepted (and
presumably the 'fix' should be to disallow resizing of this kind of
partition somehow)?

I asked on IRC whether it would be possible to disallow resizing of
'unknown' partitions. As I understand it the problem with this is it's
difficult or impossible to distinguish between an empty partition and
one that contains an unknown filesystem (and, presumably, one that is
not empty, but contains garbage).

I wonder, though, is that actually a problem? Do we need to allow
'resizing' of such partitions, or can we simply say that you should
delete and recreate such partitions, and we will only allow the
operation we call 'resizing' for partitions we definitely know the
filesystem of and that we can safely resize that filesystem?

Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net

Anaconda-devel-list mailing list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux