Did your earlier correct guess that it's the CHUNK_PUMPHDA (0x20) in the upgrade file that tells the firmware to do the re-partition operation, not work out? Omitting that would seem a more robust solution ..
No, that would only work with the new images. But I'm also trying to prevent a major mishap should somebody get confused and try to install an older image. Much more robust this way. It just failed on the last attempts because I didn't have the math entirely correct. What it's doing now is rather simple: disallow upgrader writes outside of the existing /dev/hda5 partition. Period. It's just taking a long time because I don't run MS Windows here, so I cannot actually test it very easily.
Quote:
I still also think that you should arrange that, whatever the disk geometry, the music partition ends up at the same sector offset it would with the stock image. And that the easiest way to achieve that would be to repurpose, not resize, the existing partitions.
Nope. That doesn't help us. The current spare partition is still too small for 64MB of swap, and some people already use it as an adjunct to the root partition. So it stays as-is, and will not be" repurposed". And the dynamic data partition also could use some growing space to handle the larger running orders that may appear on these new huge drives.
The alternative is to use a swap file, rather than a swap partition, and to place that file onto /dev/hda4. Except I remember that 2.2.xx kernels happen to perform much better when swapping to a partition rather than a file (fixed in newer kernels).
There's nothing sacred about the factory layout that has long since been abandoned -- there'll never be another factory load to worry about, so we can simply use whatever new format we like. With safeguards to prevent accidents when somebody uses an ancient factory build.
Previous Topic
Index
