On Wed, 2009-04-22 at 18:51 +0200, Radek Vykydal wrote: > David Lehman wrote: > > On Wed, 2009-04-22 at 13:51 +0200, Radek Vykydal wrote: > > > >> Behaves like in F10, tested. > >> Note that the patch dosn't fix the case when VGs are regrown > >> (shrinked) upon editing of existing request, but that is more > >> general bug - traceback on failure of size checks after editing > >> of partition size. I think I'll look at it too. This is more troublesome than the original report. The basic thing is that we allocate /boot and some pvs. Once the pvs are part of a vg, they become immutable, and are no longer modified by allocatePartitions or growPartitions. So, if the user does autopart w/ review, then tries to create a new partition w/ size 1 and unlimited growth, that will fail since the disks are totally allocated (/boot being a fixed size, plus the pvs which are now immutable due to being pvs in a vg). This is correct, IMO. So we pop up the dialog saying "not enough free space". The next thing we do is try to back out the last changes by canceling the actions generated by the last invocation of the partition editor dialog. This fails when it should succeed. Here's what I think is happening: We go to allocate the /boot partition initially with size 200M. With Joel's changes from a few weeks about to make partition allocation more flexible, we end up with a /boot that is slightly less than 200M -- the difference being 63 sectors at the beginning of the disk, which we used to account for explicitly. So when we try to reallocate the original requests there is no free space region large enough to satisfy the 200M /boot request, so the rollback fails. Do we need to introduce a tolerance of +/- 1MB, or should we be more careful to actually allocate the requested size in the first place? Thoughts? > >> > > > > I think the correct behavior is to not change the size of a partition > > once it is part of a VG or an MD array. I have a patch here that filters > > immutable partitions before calling allocatePartitions and > > growPartitions. It might be a slight departure from F10, but it makes > > the most sense IMO. I was going to post the patch today, but you > > reassigned the bug to yourself and posted this one while I slept. Very > > sneaky ;-) > > > > > > > I agree that your way is more sensible. > To my defense, I assigned it to me from anaconda-devel-list (who > never sleeps) - I hope it makes me a little less sneaky :) You are correct -- my mistake. > > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
