I think we may still have a problem with it, so don't get too carried away just yet.

My theory is, that since the mkfs needed a *lot* of virtual memory (swap) before it would work, then the fsck will probably have the same issue.

Maybe not immediately, no, that would be too obvious.
But perhaps after you've painstakingly added 120GB of tracks to the beast -- *then* it might croak, with no easy means of recovery.

So another builder update will be needed before you can trust it on big drives. We need to change the partitioning scheme, as Roger suggested a while ago, to allocate a much larger swap partition on /dev/hda6.

The code that currently partitions the drive, is in a closed-source binary called init_drive, which is why I didn't fix it right off on the current pass through.

So I'll have to write a shell script to replace that binary, and then we can update the builder one more time. And I might even remember to co-locate the new swap (hda6) alongside the root (hda5) partition, in an attempt to minimize head movement when swapping.

And perhaps integrate the builder functionality into a new universal upgrade file, that includes the player software etc.. for a one-step install. But this would likely also require replacing the closed-source init binary with something more flexible.

And we should probably arrange for the swap to *always* be enabled whenever the player boots up, which will require another init change to force a mkswap on it each time around.

Cheers