Configuring a Linux Filesystem for Uncontrolled Shutdowns¶

In many cases, it is desired to be able to boot a MityDSP-L138 or MityARM-1808 unit into linux and run in such a way is to allow uncontrolled power-offs, resets, or shutdowns. There are two basic approaches that are generally used:

1. Read Only Filesystem - Configure the root and/or permanent filesystems to be mounted as read only during operation.
2. RAMDISK - On boot, copy a small root filesystem to a RAM disk, then mount it read-write.

In both cases, non-volatile storage of runtime data is still possible by creating alternate partitions on NAND, MMC, SPI-NOR, SATA, etc and mounting them as read-write. However, software will still be required to deal with the ramifications of data loss during writes while an uncontrolled shutdown occurs.

Read Only Filesystem¶

This section outlines the steps required to configure a read-only root filesystem (in NAND, for this example) in order to support arbitrary power cycles or uncontrolled shut-down operations. This section is a work in progress.

Advantages to this technique:
- Allows for uncontrolled power downs
- Allows for large software deployments, limited only to non-volatile storage capacity

Disadvantages to this technique:
- Generally involves slower access time during runtime, limited by media access rates
- Requires more tuning of software / OS scripts to deal with read-only root filesystem

Converting the mitydspl138 base image to a read only filesystem¶

The first thing you should do is allow the system to boot normally. When first booted, several one time initialization steps occur to configure the unit, including the creation of ssh keys assocaited to the host (for dropbear), etc. Plus, you need the root file system to be writable to prepare it for read-only mounting. After the unit comes up, the following steps can be taken:

1. Disable udev caching by commenting out the "DEVCACHE" line in /etc/default/udev
2. Disable volatile caching by commenting setting "VOLATILE_ENABLE_CACHE=no" in /etc/default/rcS
3. Configure dropbear to look at the rsa key generated during the initial load.
   

   root@mitydsp # echo "DROPBEAR_RSAKEY=/etc/dropbear/dropbear_rsa_host_key" > /etc/default/dropbear
   

   
   The above command will use the previously generated rsa key for the dropbear ssh server. You also need to modify the dropbear script to reference a temporary directory (which doesn't actually get used, but will cause the script the fail if the mkdir command is not successful). Below is a patch to the file.
   

   @@ -33,9 +33,9 @@
    done
   
    if [ $readonly_rootfs = "1" ]; then
   -  mkdir -p /var/lib/dropbear
   -  DROPBEAR_RSAKEY_DEFAULT="/var/lib/dropbear/dropbear_rsa_host_key" 
   -  DROPBEAR_DSSKEY_DEFAULT="/var/lib/dropbear/dropbear_dss_host_key" 
   +  mkdir -p /var/volatile/dropbear
   +  DROPBEAR_RSAKEY_DEFAULT="/var/volatile/dropbear/dropbear_rsa_host_key" 
   +  DROPBEAR_DSSKEY_DEFAULT="/var/volatile/dropbear/dropbear_dss_host_key" 
    else
      DROPBEAR_RSAKEY_DEFAULT="/etc/dropbear/dropbear_rsa_host_key" 
      DROPBEAR_DSSKEY_DEFAULT="/etc/dropbear/dropbear_dss_host_key" 
   

4. Update the /etc/fstab and change the entry for the root filesystem to be readonly. The entry should look something like:
   

   rootfs               /                    auto       defaults,ro           1  1
   

5. Finally, you need to update the bootargs passed from u-boot to the kernel and specify that the rootfs should be mounted "ro".

Updating / Tweaking the RootFS after it is readonly.¶

If you need to update your root filesystem (add new apps or packages, etc.) after you have converted it to read-only, the procedure is fairly simple:

1. As root, remount the root filesystem to be writable:
   

   mount -n -o remount,rw /
   

2. make your changes
3. Then remount as read-only:
   

   mount -n -o remount,ro /
   

Booting to a RAMDISK¶

This section outlines the steps required to create a small root filesystem image that may be stored to NAND and extracted to a RAMDISK during bootup. The RAMDISK may then be mounted as read/write and normal operation may continue.

Advantages to this technique:
- Allows for uncontrolled power downs
- Generally provides fastest software access / load time (images are already in memory)
- root filesystem is mounted read/write while running, easier to maintain standard scripts / services, etc.

Disadvantages to this technique:
- Available RAM for application reduced by filesystem size
- Reduced filesize typically means reduction of available OS features / libraries unless provisions are made to mount additional directories read-only