Runbook · RB-02
Disk Full
Your device disk is at or near capacity. A full disk stops the sync daemon and database writes, causing cascading failures across other health signals. This is the highest-urgency runbook — act within minutes of a critical alert.
Signals on your Status page
| Signal | What it means | Threshold |
|---|---|---|
| Disk used (%) | Percentage of the root/data partition in use | >85 % → warn, >95 % → critical |
| Sync queue depth | Grows when the sync daemon cannot write the queue journal | See RB-01 |
What Vulos does automatically
Auto-remediation (SUPPORT-02) cross-reference: when disk usage exceeds 90 %, Vulos runs the automated cleanup routine: purges compressed log archives older than 7 days, removes OTA staging partitions that are no longer the active or standby slot, and clears the app download cache. This typically recovers 5–20 % of disk space. A critical alert fires immediately. If usage remains above 90 % after cleanup, no further automated action is taken — manual intervention is required to avoid data loss.
What you can do
1. Identify what is consuming disk
SSH into the device (or use a console session) and run:
df -h / du -sh /var/log /var/cache /home /opt/vulos/data 2>/dev/null | sort -rh | head -20
Common culprits in order of frequency:
| Location | What grows here | Safe to prune? |
|---|---|---|
| /var/log | System and application logs | Yes — archived logs (.gz) older than 30 d are safe to delete |
| /opt/vulos/data/cache | App download and thumbnail cache | Yes — fully regenerable on demand |
| /opt/vulos/data/ota | OTA staging images | Yes — only the active and standby slot are needed |
| /opt/vulos/data/db | cr-sqlite database and WAL files | Do NOT delete — run vulos-db vacuum instead |
| /home | User files, downloads | User decision — review before deleting |
2. Run the manual cleanup command
sudo vulos-admin disk-cleanup --aggressive
This runs the same automated cleanup but with a longer log retention cutoff (3 days instead of 7) and clears all app caches regardless of age. Typical recovery: 10–30 % of disk space.
3. Vacuum the database
If /opt/vulos/data/db is large, compact the WAL and reclaim fragmented space:
sudo vulos-db vacuum # This is safe to run while the instance is running. # Expect 1–5 min for a typical 500 MB database.
4. Expand the disk (if still insufficient)
If cleanup is insufficient and your hypervisor or cloud provider supports live disk expansion, resize the volume and then expand the partition:
# After resizing the block device in your provider console: sudo growpart /dev/sda 1 sudo resize2fs /dev/sda1 # ext4 # or: sudo xfs_growfs / # xfs
Physical hardware: disk expansion is not possible without replacing the storage medium. Prioritise cleanup and offload user data to external storage before the device becomes completely unusable.
5. If disk is at 100 % and the system is unresponsive
Emergency recovery: at 100 % disk usage, SSH may not function. Use the break-glass console access from your Devices page (SSH recovery key). Once in, immediately delete the largest log files:
This recovers enough space to get SSH working, then proceed with the full cleanup above.
sudo find /var/log -name '*.gz' -delete; sudo journalctl --vacuum-size=50MThis recovers enough space to get SSH working, then proceed with the full cleanup above.
Prevention
- Vulos alerts at 85 % disk usage — do not ignore warn-level disk alerts.
- Configure logrotate to keep at most 7 days of logs on embedded or small-disk hardware.
- Run vulos-db vacuum monthly on instances with high write volume.
- Use the Status page disk signal as a trend monitor — a steadily climbing line means you need more storage.
- For app-heavy deployments, consider a separate data partition mounted at /opt/vulos/data so log growth cannot fill the root partition.
Related runbooks
- RB-01 — Sync Queue Stuck (disk full often causes this)