Joel, you are correct -- I unfairly blamed you for this. I am currently trying to figure out the actual cause, but it involves parted reporting the first free sector as 0 if there are no partitions versus 63 if there are any partitions, even at the end of the disk. I apologize. Dave On Thu, 2009-04-23 at 18:28 +0200, Joel Granados wrote: > On Wed, Apr 22, 2009 at 12:16:05PM -0500, David Lehman wrote: > > 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? > > If your refering to 2297c5facd5ad14556a362380428d261c3fd5abf. what I > tried to do was to make the constraint a little bigger (2 sectors > larger) so we didn't trip on some special handling that parted does for > the first logical partition on an msdos label. The range depends on > whatever free (partitioning.py:767) is. So if we calculate free using > the initial 63 sectors, I don't think that this commit changed that > behavior. > > Is that the commit you where talking about? > > Regards > > > > > > >> > > > > > > > > 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 > _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
