Felix looked at this a while ago, but we never reached a consensus:

Hello Richard

Please find attached a patch for UpgradeUBI.lua to solve the issue I've seen when upgrading from a backup image.

Let me know if the changes are along the lines you had in mind or what you think could be improved.

I've tested it and it seems to work ok.

Thanks
Felix 

On Apr 17, 2009, at 11:20 AM, Richard Titmuss wrote:

> Close. My comments:
>
> - Make sure the parseCmdLine() is before any changes to the flash, all the parsing should be first in case it fails. (This may already be like this, I've only looked at the patch and not where it merges in the code.)
> - Don't delete kernel, cramfs at the start. They may not be too badly broken, and if the upgrade fails it would meant the unit won't boot at all. Instead delete them just before the renamevol. In fact I think you can not delete them at all, then the rename will replace the old versions. That would be best, but you'll need to test it. 


Hello Richard

All the parsing takes place before any manipulation to the flash happens. I'll include the complete function next time so it's easier for you to read.

It seems to work if I don't delete 'kernel' and 'cramfs' explicitly and let renamevol taking care of it when updating from backup image.

However this method uses more flash during download and afterwards the volume table has a hole in it.

Before I started I had these volumes:                        0, 1, 2, 3, 4
First upgrade from backup image w/o deleting:                0, 1, 2, 3, 4, 5, 6
After reboot:                                                0, 1, 2, 5, 6
I did another update from backup image and now I have:        2, 3, 4, 5, 6
After another normal update I am back at:                    0, 1, 2, 3, 4

Do you think that is ok?

Thanks
Felix

Fixed in fab4 r6120.

This pretty much uses Felix's first patch, as holding three images in flash won't always work.

*** Bug 11853 has been marked as a duplicate of this bug. ***