On Mon, 2016-02-22 at 12:32 -0800, Adam Williamson wrote: > Hi folks! So as promised on IRC here's a mail to discuss this issue. > > https://bugzilla.redhat.com/show_bug.cgi?id=1033778 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 What is the appropriate tool (and parameters) for resizing the formatting on a device with unrecognized/unknown formatting? > 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 > broken." > > 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? > > Thanks! _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
