LattePanda Sigma Power Loss Protection Setup Guide
When deploying the LattePanda Sigma running Ubuntu 22.04 in mobile or unstable power environments, sudden power loss without a proper shutdown can lead to filesystem corruption.
This guide introduces a set of configurations to minimize the risk of OS corruption and data loss, while maintaining compatibility with ROS2, Docker, and custom applications.
1. Environment

2. Configuration Overview


3. Setup Instructions
3.1 (Optional) Install sshpass
If configuring remotely with password authentication:

Otherwise, skip this step.
3.2 Mount /tmp as tmpfs
3.2.1 Benefits
/tmp is used for inter-process communication and temporary file storage, but its contents do not need to persist after a reboot. By moving /tmp to a RAM-based tmpfs , you can:
- Reduce the number of disk write operations and minimize the risk of incomplete writes during sudden power loss
- Extend the lifespan of the NVMe SSD by reducing write cycles
- Ensure that even if files in
/tmpare lost or corrupted due to power loss, the OS remains unaffected
3.2.2 Steps
In Ubuntu 22.04, /usr/share/systemd/tmp.mount is provided, but it is not enabled by default.

3.2.3 Verification

3.3 Add noatime to fstab
3.3.1 Benefits
By default, every time a file is read, its access time ( atime ) is written to disk. By enabling noatime , these write operations are eliminated:
- Read operations no longer trigger write operations
- Disk I/O is reduced, lowering the likelihood of partial writes during sudden power loss
3.3.2 Steps

Updated /etc/fstab (root partition entry):

To apply the changes immediately without rebooting:

3.3.3 Verification

3.4 Verify errors=remount-ro (Default Setting)
3.4.1 Benefits
This option is enabled by default in a standard Ubuntu installation.
When a filesystem error is detected, instead of continuing to write and potentially causing further damage, the system automatically remounts the filesystem as read-only.
3.4.2 Verification

If you need to add it manually, append errors=remount-ro to the options field of the ext4 entry in /etc/fstab .
3.5 Configure systemd journald
3.5.1 Benefits
By default, system logs (journald) are buffered in memory and written to disk every 5 minutes.
In the event of a sudden power loss, up to 5 minutes of logs may be lost.
By setting SyncIntervalSec=15s :
- The potential log loss is reduced to a maximum of 15 seconds
- Logs around the time of failure are more likely to be preserved, making debugging easier
Additional options:

3.5.2 Steps

3.5.3 Verification

3.6 Change the Docker Logging Driver
3.6.1 Benefits
The default Docker logging driver (json-file) does not enable log rotation by default. As a result, log files can grow indefinitely during long-running operations.
By switching to the local logging driver:
- Automatic log rotation (10MB × 5 files) prevents excessive disk usage
- Binary format logging is more efficient than plain JSON text
- Reduces the risk of incomplete writes to large log files during sudden power loss
The Docker storage driver ( overlayfs , based on Copy-on-Write) is enabled by default. Since container layers are managed atomically, container images are less likely to be corrupted even in the event of a power failure.
No changes are required for this setting.
3.6.2 Steps

3.6.3 Verification

4. Behavior During Power Loss (After Configuration)

5. Backup and Recovery
A backup of /etc/fstab was created before making any configuration changes. If any issues occur:

6. Limitations: Cases Not Covered by This Configuration
Data Loss During Writes
Data that is being written to disk at the exact moment of a power loss may still be lost.
This can be mitigated at the application level by using atomic write patterns (write to a temporary file, then rename) or implementing WAL (Write-Ahead Logging).
NVMe Write Cache
NVMe drives typically flush their internal write cache using barrier commands, but some drives may include additional internal buffers.
For industrial applications, it is recommended to use NVMe SSDs that support Power Loss Protection (PLP).
Hardware-Level Protection
Software configuration alone cannot fully prevent issues caused by sudden power loss.
Combining this setup with hardware solutions such as UPS (Uninterruptible Power Supply) or supercapacitors can significantly improve system reliability.
We would like to sincerely thank @todateman, an engineer from Japan, for sharing this valuable and practical project. This article is based on the original post, which can be found here: https://qiita.com/todateman/items/33a413988bcd3d859145#1%E5%89%8D%E6%8F%90%E7%92%B0%E5%A2%83

