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

[Artem Bityutskiy]

On Wed, 2012-09-26 at 12:53 +0200, Ricard Wanderlof wrote:
> On Wed, 26 Sep 2012, Artem Bityutskiy wrote:
> 
> > 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.
> 
> But the problem is that the first step fails as the system is still 
> running, and you can't unmount / while it is up.
> 
> > Also, I guess the rename path should not open the volume in the
> > exclusive mode.
> 
> Yes, that would be a workable solution, if there weren't any other 
> disadvantages (e.g. something getting confused by the volume name 
> changing, like df).

Well, what I say is that we only do the changes in the on-flash volume
table. The in-memory data structures are not changed. So nothing should
be confused in theory, except the user :-) Something like I'll send in
the follow-up e-mail, which Jaya can probably try.

-- 
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/3a5cfa2a/attachment.sig>