What happens when you flash a new ROM?

[Windrose]

Right. I'm sure this is a naive question, but say, for example, you have an SL5600 with the latest Sharp ROM running on it -- 1.32 or whatever. Sundry installed applications including whatever came out of the box.

Say you obtain and flash the latest OZ/Opie image, 3.5.1, onto the Zaurus, so now you're running that.

In that flashing process, what happens to the original bytes of the Sharp installation? I had innocently thought that the flash would basically nuke the entire original memory and overlay the new system, GUI, and apps. But in paging though the directory tree I note lots of material, largely under /home, that seem to be the original desktop filkes and config files for the Sharp apps. Were they left in place?

OZ/Opie seems to prefer building its desktop configuration tree under /opt? And installed apps seems to wind up maybeso in /usr somewhere? Can I recover the space used by the old Sharp files? How's this all work? I've tried to fox it out by searching through this forum and openembedded, but it seems a question not easily handled by search strings.

TIA,
Windrose

[lardman]

The 5600 has two partitions; iirc OZ doesn't touch the one which contains /home, which means that your old stuff will remain there.

OZ/Opie seems to prefer building its desktop configuration tree under /opt?

This is caused by the symlinks which are required to support a standard Linux fs layout while still having a non-writable root.

/opt/QtPalmtop is correct; the Sharp ROM symlinks /home/root/QtPalmtop (or something like that) to /opt/QtPalmtop to allow it to be writable (so you can install things).

And installed apps seems to wind up maybeso in /usr somewhere?

Some do, others end up in /opt/QtPalmtop/bin the same as the Sharp ROM in both instances.

Can I recover the space used by the old Sharp files? How's this all work? I've tried to fox it out by searching through this forum and openembedded, but it seems a question not easily handled by search strings.

Yes; delete selectively.


Si

[dansawyer]

This design seems problematic. A full reflash should effectivly 'format' the Z flash partition. The result should be the loss of all data in the 16M area. (32M on a 5600). Is there a reason this is not done? Otherwise the outcome of a flash is not deterministic.

Dan

[Windrose]

Thank you, Si, that clears up a lot.

Windrose

[lardman]

This design seems problematic. A full reflash should effectivly 'format' the Z flash partition. The result should be the loss of all data in the 16M area. (32M on a 5600). Is there a reason this is not done? Otherwise the outcome of a flash is not deterministic.

I don't think there's any particular reason; I agree that altering updater.sh to format the user partition would be a good idea (because the available flashROM is split into a ROM area and a user area on the 5600/C7xx/C8xx and probably C6k too).

Even better would be to merge the two (as root is writable anyway) to produce one partition and let OZ install when this has happened (because I don't think it can at the moment): I've no idea to go about this though I'm afraid.


Si

[Windrose]

Just arguendo, and not because I have any idea what I'm talking about, would the NAND backup/restore mechanism do that? That is, if a developer got a target 5600 Zaurus repartitioned into a single partition, and installed a standard bootstrap OZ/Opie or /GPE setup on it, could you then run NAND backup to get the memory image and distribute that in lieu of the canonical kernel-image, file-image, installer mechanism? Or does the NAND process not save and restore partitioning information?

W