[yocto] Creating a volatile image

[ChenQi]

On 07/03/2013 03:48 PM, Paul D. DeRocco wrote:
> When an .hddimg image is used on a hard disk or flash drive, the target root
> directory is implemented as a loop device referring to the rootfs.img file
> contained in that drive. This means it is a true non-volatile file system.
> Is there a way to make the entire file system volatile?
Three ways to achieve this goal.

1. If you're using yocto 3.8 kernel, you can enable aufs by add the 
following line to local.conf.
KERNEL_FEATURES_append = " features/aufs/aufs-enable.scc"
This will enable the aufs support and your live image (iso or hddimg) 
will appear to be writable.
This aufs support in live image is added recently.
commit: 29e55997caeb9c6367f9a340e153f829228f36ed
subject: init-live.sh: try to make a union mount when possible

2. If you're using other kernel versions, an option is to use 
device-mapping.
But you might need to write your own recipe to include the dmsetup 
command into the image.
In addition, you need to modify the init-live.sh script a little.
dmsetup is not used in OE/Yocto for now.
ArchLinux uses this method to make its liveCD version work.

3. As a temporary workaround, you can bind mount the directory you need 
to write to with a tmpfs.
e.g.
mkdir -p /var/volatile/lib
mount --bind /var/lib /var/volatile/lib


Best Regards,
Chen Qi

> I'm trying to ensure that my flash drive is written to as rarely as
> possible. To this end, I'm putting my app's volatile data on a separate
> partition, and I'd like to run the OS out of a big ramdisk, loading it on
> startup and then discarding it on shutdown. In other words, I want a
> Groundhog Day system, which always boots up as though it is a brand new
> clean install.
>
> I've spent a couple hours trying to decipher various .bbclass files,
> Googling about the various file systems, and so on, and I haven't seen
> anything that looks like this capability is already provided somehow in the
> Yocto system. Is there an easy way to do this? Or is there only a hard way
> to do it, involving way more expertise in the build system than I've got?
>
> Alternatively, is it practical to make the existing file system readonly? My
> system is based on core-image-base, with no graphics. What will break if it
> can't write to anything outside of /tmp or /run or /media/ram or
> /var/volatile? And is there a built-in way to do that?
>