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
FAQs
- Why is power-loss protection optimization necessary on edge devices like Sigma?Because sudden power loss can corrupt the filesystem and break data consistency. On systems like LattePanda Sigma running Ubuntu in mobile or unstable power environments, NVMe writes may be interrupted unexpectedly. This can lead to partial writes, filesystem errors, or even boot failure, making system-level mitigation necessary.
- Why mounting /tmp as tmpfs improves system reliability?It reduces disk writes and prevents temporary file corruption from affecting storage. /tmp is used for temporary runtime data and does not require persistence. Moving it to RAM (tmpfs) eliminates SSD write pressure and ensures that sudden power loss does not leave corrupted temporary data on disk.
- How does noatime help in power-loss scenarios?It reduces unnecessary disk writes triggered by file read operations. By default, Linux updates file access time (atime) on every read, generating extra write I/O. Disabling this reduces disk activity, lowering the chance of incomplete writes during sudden power interruption.
- Why does journald sync interval affect log reliability?Because it defines how much log data can be lost during a crash or power failure. If logs are flushed every 5 minutes by default, up to 5 minutes of system logs may be lost in a sudden shutdown. Reducing the sync interval shortens this window, improving post-failure debugging accuracy.
- Why can software-level optimizations not fully eliminate power-loss risks?Because storage hardware caching and write behavior cannot be fully controlled by the OS. Even with reduced writes and safer filesystem settings, NVMe internal buffers or in-flight writes may still be interrupted. Therefore, hardware-level protections like UPS or SSDs with power-loss protection (PLP) are still required for critical deployments.
