Originally Posted By: mlord
What I don't know (for sure), is exactly what it does when the .upgrader encounters a "DISK" chunk, which seems to mean "create a partition table", sometimes.

Are you dead sure it's "sometimes" and not "always"?

Quote:
Where is the decision made as to whether or not to overwrite the on-disk partition table with a new one? Does the Windows-based upgrader decide, or does linuxrc on the initrd decide?

I'm just wondering if an altered swap/spare/dyndata partition is reverted when a v2.01 or v3a11 software .upgrade file is applied over top of the built disk.

Because all of the .upgrade files seem to include the "DISK" chunk for hda, not just the builder .upgrade.

This was all done before I even started at Empeg, but I expect that all stock upgrade files unconditionally repartition the first drive. That would mean that as long as we didn't move the music partition, we could in theory have fiddled with the other sizes from version to version. We never did change anything, though.

I still think that if the goal is to get more swap on Hijacked players, the easiest thing to do would be mkswap /dev/hda2 (or hdb6), and suborn sys_swapon and sys_swapoff to additionally do their thing on the second swap-partition whenever invoked for /dev/hda6. IMO you really don't want to create a population of players incompatible with stock upgrade files.

Peter