Mounting Filesystem over existing directory

[Sameer Naik]

Hello Laurent,

Thanks for the insightful response.

On Fri, Jun 1, 2012 at 12:12 PM, Laurent Bercot
<ska-dietlibc at skarnet.org> 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.
>
>  That is the point of switch_root.
>  When you switch_root from an initramfs to another rootfs, you free up
> all the initramfs resources.
>  Of course, you can't do it if you are still using initramfs as your
> "main" rootfs.

Got it. I tested out switch_root and indeed the memory was being freed up.

(For anyone who stumbles upon this thread should read
http://en.wikipedia.org/wiki/Initrd for details on initrd and
initramfs)

>
>
>> 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.

My understanding is that when an update is required the updates are
only made to the other partition and the current partition is never
updated until a never update is found. 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. If we can correctly verify that the partition has gone
corrupted during the update (i.e. mount happens properly) and firmware
is working properly (i guess your s6 system allows to do this to some
extent) then this method will absolutely guarantee that the system
boots up into a functional system.

Only issue is the space required for the additional partition. If this
can be managed, then this is a perfect solution.

One way to reduce the space requirement could be to have a partition
with a compressed version of the filesystem waiting to be copied over
to the boot partition NAND corruption and other errors are detected.
So we would end up having a filesystem partition + compressed
filesystem partition that is never updated. Problem with this is that
if the filesystem is recovered form the from the compressed image,
then you could end up with a primitive version of the firmware.

So your method still tops.

>
>
>> 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.
Right, I will try to manage the space and get two filesystem partitions.

>
>
>> Problem with this system is, I may not be able to release the
>> resources used by the initramfs after switching the root (at least i
>> am not aware how it should be done).
>
>  You don't even need an initramfs. You just need to mount a tmpfs early
> on during the boot process to have a place to write to. It's very
> possible, and much simpler, to boot directly on your real rootfs.

>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.

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.

>
>  If you are building an embedded device, do not copy what mainstream
> Linux distributions do, with initramfs and /lib/init/rw and whatnot.
> This is extremely and needlessly complicated, and will only give you
> more resources usage, a longer boot time, and more opportunities for
> failures - not even mentioning more headaches.

This is true.
I have borrowed ideas from redhat linux on certain aspects of the
system, particularly the networking part. But all in all, its not what
a typical linux system would look like.


Regards
~Sameer
>
> --
>  Laurent