[...] > > > 4) There is a "parted -s /dev/hda resize 3" command. Partition 3 is the > > extended partition. As we discussed before, it can not be added to the > > perserve list. > > > > In my case, it seems that the empty space which used to be at the end of > > partition 3 (partition ends at 74447009279B) will be moved out of it > > (partition being resized to 73945267199B, to coincide with the end of > > hda12, the last logical partition). This makes the empty space unusable > > for future partitions, because it will now be located between partitions > > 3 (extended) and 4 (primary) and nothing can be put into it without > > re-extending partition 3 again. So why shrink it in the first place? > > > > Perhaps "preserving an extended partition" is not such a bad (or > > useless) notion after all? > > > > Ok, that I'll have to look into properly, it's getting too late... It's > intentional that the extended partition is just as large as necessary, but I > have no idea why this is achieved via resize. Looks like a bug, but I'll have > to > double-check. >
[...] Hmm, no, not really a bug. Some time ago apparently I decided that whenever a logical parition is to be preserved the underlying extended partition must also be preserved in some way. Well, and resizing seemed to be a proper approach. Ok, setup-storage is not as clever as to understand that free space outside the extended partition is not as good as free space inside the extended partition *in this case*. We could add some logic to achieve this, but I wonder if it is worth the trouble: If you just add a logical partition in your config, even without a mount point, and a size of "0-" you'll get the extended partition maximized. Well, unless there is some other bug :-) Hope this helps, Michael
pgpDFNuEQuucZ.pgp
Description: PGP signature
