It works fine -- the extra space is simply ignored, and one ends up with a 16MB root filesystem, with 16MB of unused spaced at the end of it, just as already happens on some big drives today.


Mmm.. I was going to say, no that's actually unsafe to do, because if the player ever runs (even once), it will write to the disk (dynamic data), and possibly screw up (write to the wrong part of the disk) due to lack of working LBA48 support in the kernel.

But in practice, the entire dynamic data partition is still well below the LBA28 boundary, so it actually will work and is safe to do -- just never try to remount the music partitions r/w.

In practice, though, there is no reason to ever use a "stock" .upgrade file on a bigdisk player, as there are hijacked versions available to use instead.

But it could indeed get a bit messy, because if we go ahead with 32MB root on bigdisks, then we'll have a mix of 16MB and 32MB players out there, and the 32MB .upgrade files won't work on the 16MB players (or worse, the firmware might happily write out all 32MB..).

So, I guess the solution for space on root has to be to use the spare partition, and perhaps update /bin/init etc.. to automatically mount it at boot, and have rw/rwm mount it r/w along with the others.

Ugh. I guess I'll first check and see what the firmware does with a 32MB root file on a 16MB partition..

Cheers