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
pgpT8Lz9rAWkG.pgp
Description: PGP signature
