Mounting Filesystem over existing directory

[Michael Conrad]

On 6/1/2012 2:42 AM, Laurent Bercot wrote:
>> Out of curiosity, Is is possible to free up the resources used by
>> initramfs. I would be very interested in knowing how this can be done.
Initramfs is really just a tmpfs which the kernel copies files into at 
boot-time.  You free it by removing all files from it, and unmounting it 
(after switch_root, because you can't unmount "/").

My initramfs was only 5MB (busybox, rsync, dropbear-sshd, some symlinks 
and a script) so I didn't care.  I want busybox loaded into ram for the 
entire life of the system, so I could just "rm" the others to reclaim a 
tiny bit of ram and that's pretty much optimal for me.

>> In my case, i am developing a system for an embedded system with NAND
>> storage. Due to NAND corruption issues that mostly arise right now is
>> when system is powered off while NAND writes are being performed (i.e.
>> when files are being flushed out to the filesystem). This corruption
>> makes the system un-bootable. Due to this issue i want to make the
>> NAND filesystem readonly. Only at the time of system updates the
>> filesystem will be remounted in rw mode. This still leaves room for
>> the corruption to occur during system updates.
>   There's only one way to guarantee bootability even with updates:
> have *two* read-only partitions for the rootfs. Boot on one; when you
> download an update, write the binary file to the other one. Reboot. If
> it boots, use the new partition as your new rootfs; if not, fall back
> on the old one (it still works) and report a failure.
>> Right now i am thinking of having a initramfs filesystem with a
>> recovery system that starts a device recovery process if the system
>> partition cannot be mounted. So the intention is:
>   You can do that, but that means your device will be non-functional
> (i.e. stuck in recovery mode) at the first failing update. (And trust
> me, failing updates WILL happen.) Your users will complain, and
> rightfully so.
>   Better have two rootfs partitions so you can always guarantee that
> one of them boots into a functional system.

Interesting.  But where do you have the logic for choosing a boot 
device?  What if your new partition is fine, but core services fail to 
load?  How do you recognize that you need to start over with a different 
root partition?

My case is also an embedded system.  I just wanted reliability, system 
updates from USB drive, and the ability to power-off the system without 
notice (thus mounting read-only).  My init script mounts all the USB 
devices looking for a system update (squashfs file), and if it finds one 
it mounts the main partition read/write and uses rsync to copy the image 
to the local drive, then unmounts everything.  Then, it mounts the main 
partition read-only, creates the union, and execs 'init'.  In practice, 
it runs very fast, especially if no USB devices are present.

If anything goes wrong with the new version, I just pop in a USB drive 
with the old version.  The initramfs is simple enough that it never 
needs changed.

-Mike