UPDATE #28
Today, I have added a feature about a permanent storage for some configuration parameters.
First of all, it is important to clarify that a recovery image for its nature SHOULD NOT rely on any kind of persistent data otherwise its mission to be ALWAYS available and ALWAYS identical in its features among services different boots would be gone and moreover a persistent data can break it.
However, because the RedFish OS can be also used for assisting developers, modders and debuggers. It make sense that they can save some persistent data somewhere which is strictly associated with the bootable recovery image like the WLAN name and password, for example.
This can be acceptable as far as and as long as that data can be used just after the boot and by a manual procedure like a specific menu. The functions are:
redfishos:~ # rflist boot_perm
boot_perm_umount
boot_perm_is_mounted
boot_perm_device
boot_perm_loopdev
boot_perm_setup
boot_perm_mkfs
boot_perm_mount
boot_perm_free
redfishos:~ # boot_perm_mount; df -h $PERMCFS
Filesystem Size Used Available Use% Mounted on
/dev/loop0 3.9M 512 3.9M 0% /perm
To activate the permanent area the function boot_perm_setup() and boot_perm_mkfs() will provide the necessary features. I choose the VFAT in order to maximize the free space because it is just 4MB and the EXT4 or even the EXT2 filesystem would have took too much space. The size is purposely small to prevent and to disincentive its misuse.
How does it work?
The main idea is that apart the RedFish OS recovery image everything else is compromised or potentially unreliable. Possibly, also the RedFish OS recovery image could be broken but with a single fastboot upload the recovery image can be easily restored.
The script that generates the recovery image prevent the image to be bigger than 60MB and thus 4MB are always left free at the end of the boot_a partition. The last 4MB are left free and unwritten by the fastboot command and this grants the persistence among uploads.
The same happens for the boot_b partition, obviously.
The system knows on which partition is booted from and it will uses the related last 4MB. A menu voice that allows to copy the persistence area from boot_a and boot_b will be added but not the viceversa because it is dangerous supporting the idea that the user can arbitrary choose to boot from boot_b rather than boot_a. Because the boot_b can also contains something completely different like an emergency phone or an hidden system/data.
Everything else is just a set of functions in shell scripting.
Persistence menu
The persistence menu is a contextual one:
Depending the state of the persistence, it shows some options rather than others.
