Mounting Filesystem over existing directory

[Laurent Bercot]

> This would mean that when an
> update is done you end up with one partition that has the latest
> software and one partition that has the previous version of the
> software.

 Exactly. You always have one partition that is guaranteed to work.


> Only issue is the space required for the additional partition.

 Since your rootfs is read-only, you can use cramfs or squashfs, so
your firmware fits on a postage stamp. You don't need to store an
uncompressed version of your rootfs, ever. (Except in RAM cache,
of course, but that's totally transparent.)


> From you response to Micheal's query, i understand that the platform
> should allow to specify which partition to boot from. In other words
> we should
> 1. be able to update the the kernel boot arguments
> 2. platform should probably have the ability to accept some sort of
> argument that tells it to boot using another set of boot args in case
> the main one fails.

 Yes, updating bootloader information is required, but you only need to
store two bits of information:
 - what partition you should be booting on
 - whether you are testing an update

 Your bootloader code should get this information from your nvram, and
do its thing accordingly.


> Is that correct. In my system i can update the kernel boot args. But i
> believe that if the mounting of the root partition fails then the
> kernel will panic.

 You can do some basic tests before rebooting, including whether the
mounting works (mount /dev/something /mnt/test) and whether the new
firmware looks like something you actually made
(chroot /mnt/test /bin/true && /bin/verify /mnt/test/somepublickey)

 If all else fails, you should have a hardware watchdog that reboots
the device when the kernel's gone fishing, and your bootloader will
then fall back on the old rootfs.

-- 
 Laurent