Offtopic: ubifs and best practice for supporting browser based firmware upgrades

[Artem Bityutskiy]

On Wed, 2012-09-26 at 13:42 +0800, Jaya Kumar wrote:
> I think what this means is that after doing the rootfs upgrade using
> ubiupdatevol, I must reboot into a 3rd partition running a minimal OS
> to perform the ubirename of roofs_reserve and then reboot again. This
> step seems expensive to have to boot into a 3rd partition to do the
> rename operation.
> 
> I see someone else also has encountered this,
> http://comments.gmane.org/gmane.linux.drivers.mtd/39415 and solved by
> having a initramfs. I guess I could do that. But still seems messy.

Yes, the way it is currently implemented is:

1. ubirename /dev/ubi0 rootfs rootfs_reserve
2. UBI figures out that old 'rootfs' should be removed.
3. UBI changes the volume table and wipes old rootfs from there,
   and changes name 'rootfs_reserve' to 'rootfs'.

   Now if you have a power cut, you will no longer see the old rootfs
   vloume, only the new one.
4. Then UBI actually deletes the old volume from all the in-memory
   data structures. Obviously, you cannot use this volume at the same
   time.

But this can be improved, I did not think a lot about this, but I guess
if you just skip step 4, it should work. The rename will succeed, but
you will still see the old layout. And only when you reboot, you'll have
the old rootfs deleted and the new one being in place.

Or not even reboot - detach and attach back should be enough. I guess
you can hack this.

Also, I guess the rename path should not open the volume in the
exclusive mode.

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120926/a3798dee/attachment-0001.sig>