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
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
