setup-storage and preserving partitions

[Michael Tautschnig]

Hi!

> Here are the latest test results, using FAI 3.4~beta4+experimental4 ,
> setup-storage 1.2.1+exp . See attachment.
> 
> For the first time, setup-storage ran to completion with my inputs.
> Congratulations!
> 
> There are some things to remark, however:
> 
> 1) At some point, it gets a series of "Use of uninitialized value"
> errors. Please note that in the attached file, I moved the messages
> around a little bit to improve readability. In the original format.log,
> they appear in the middle of the "desired disk layout" output, a result
> of mixing stdout and stderr.
> 

Ok, thanks, these have been fixed in 3.4~beta4+experimental5.

> 2) It is discomforting to see all the "parted -s /dev/hda mkpart"
> commands being queued. Does not match my understanding of "preserving a
> partition". What if, for some reason, the parameters are in error and
> the partitions get messed up? I would like to define "preserving" as
> "not touching at all". Would that be difficult to implement?
> 

Kind of, yes. There are two problems actually, one implementation-specific and a
matter-of-taste one:

- The matter-of-taste thing: If partitions were not rebuilt the order if indices
  would change and not be consistent anymore with the on-disk byte order.
- The implementation-specific one: setup-storage builds this queue of commands.
  As this queue is processed, indices of partitions will change while removing
  partitions. The queued commands hence have to anticipate this. By enforcing a
  fixed order of removal commands this can be achieved, but I pretty much fear I
  get something wrong in doing this (some off-by-one-error maybe) which will
  destroy someone's to-be-preserved partition.

I'm more than happy to accept patches (and help with questions!) that do it the
nicer way but I fear I'm not going to implement this myself anytime soon.

> 3) It seems that many (all?) of the "parted -s /dev/hda mkpart" get
> executed twice. If they can not be totally eliminated, one pass should
> suffice?
> 

It's necessary if some partitions need to be resized. I just was too lazy to not
do so if nothing is being resized. Fixed in 3.4~beta4+experimental6. Could you
please retry with that one?

> 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.

> In a summary, in my mind the only commands which should be queued are
> the  mkfs.ext3  and  mkswap  commands. Would that be achievable?
> 

It's not completely infeasible, as outlined above. But it'll probably require
someone else's manpower.

Best,
Michael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url : http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20100702/fc991811/attachment.bin