On Mon, Oct 15, 2012 at 10:11:16AM -0400, Phillip Susi wrote: > On 10/15/2012 4:31 AM, Petr Uzel wrote: > > When parted encounters busy partition during its loop for informing > > the kernel about partition changes, it tries to compare geometry of > > the to-be created partition with the geometry of the existing > > partition (reported by the kernel). If these geometries match, > > there is nothing more to do for parted. > > > > However, this fails for msdos extended partitions, because kernel > > always reports size of extended partition to be 2s, no matter how > > big it actually is (to avoid having overlapping partitions in the > > kernel's representation of partition table). This makes the > > comparison of geometries to fail for extended partitions, so they > > need to be handled specially. > > Isn't this a bit of a contrived case?
It is not. In fact, one of our (SUSE) customers has been recently hit by this. I don't know yet which program on the customers system caused this (some hal* would be my guess). > I mean in practice, an extended > partition should never be in use. IIRC, the only reason the kernel > even creates the extended partition is to allow lilo to install itself > there easily, outside of that, nobody ever opens them. I agree nothing should ever open extended partition, but in reality you can not guarantee that. > What happens if the old partition was NOT an extended partition, but > the new one is? In other words, we are removing a primary partition > and replacing it with a primary that starts in the same place? Then > wouldn't this change prevent parted from complaining that it couldn't > make the change if the partition is in use? Isn't this a bit of a contrived case? :) No, really, good point - I'll try to reproduce this scenario and check what can be done about it. Thanks for the review, Petr -- Petr Uzel IRC: ptr_uzl @ freenode
pgpnTtfQxp5jv.pgp
Description: PGP signature
