making the TX2 field-ready (power loss prevention)


This is more a generic embedded linux than a Nvidia one, so I’d understand if this post gets deleted.

I have a great project with a TX2 in a sealed enclosure for underwater applications. My program runs on a terminal (no desktop) and doesn’t write any data. I have two requirements:

  1. being able to push updates frequently and remotely.
  2. being able to turn off by removing power.

Can I simply rely on the ext4 filesystem? I haven’t found anything about using overlayroot in the tx2 (no success cases at least).


I haven’t found a way to correctly create an initramfs which is required for overlayfs.

ext4 being shut down incorrectly would not corrupt the file system…but it would cause parts of the file system to go missing.

Thanks for your answer. So if parts of the filesystem go missing… it wouldn’t boot anyways so the consequence is the same as with a corrupted filesystem. I cannot just rely on ext4 then.

Not sure how to handle it then. For what I see in the forums no one has achieved that in the TX2. Shutting down properly is not an option in my environment. Any suggestion is welcome.

I am not a linux expert, so any advice would be welcome. I see two options here:

  1. Using data=journal in /etc/mtab. Not sure if that’s 100% safe against power loss.
  2. Changing /etc/mtab to mount / as ro. Not sure if It will still boot, and if it can be easily undone if I need to update something.

Again, I don’t boot to a desktop and my application doesn’t write to disk.

Any help is welcome. Thanks!

I can see a possibility, but let me describe part of what goes on which is related to this.

The journal is basically a log of changes, and until the driver knows a change is actually flushed to the disk the journal itself is not updated and the non-flushed data is considered the same as “as if the write never began”. Most of the file system is never in need of writing, and only the parts which are still in the journal are in danger of being lost. Something not marked as written will no longer exist after a hard power reset.

There are parts of the file system which are normally written to, e.g., the “/tmp” location and some lock files in “/var” (other files in “/var” as well, e.g., logs, but locks are important…a stale lock can prevent something from working, but missing logs won’t break anything). The files in “/tmp” are considered temporary (as the name implies) and are not an issue if the journal causes some of the recently changed but uncommitted files there to disappear. Some of the files in “/var” might be a different story, but some of those might be ok as well.

Files anywhere else which change (such as in a home directory) are usually at risk of being lost. Again, not all of those matter, but some do.

So you could run in synchronous mode to never cache. Performance would drop through the floor. In the case of solid state memory the life of the memory would be drastically reduced. Power consumption would go up dramatically.

Some temporary files are mandatory, e.g., some temporary files related to login. An illustration is that if the file system completely fills, then login becomes impossible.

If you were to mount “/var” and “/tmp” on different partitions from “/”, then for the most part a read-only file system would accomplish what you want. You’d still have issues at time with the “/home” due to temp files for X11. You could mount a separate partition for “/home” as well, and leave that read-write. With the rest of “/” being read-only you would be guaranteed a bootable system. You wouldn’t be guaranteed that nothing would go wrong with the X server (and the X server session is tied to the GPU…the session writes temp files in the user’s home directory).

My feeling is that you could come close to what you want, but you’d never have a real guarantee. It just depends on what the cost is for failure and how much tolerance you have for that failure. Without knowing your exact situation there isn’t much practical advise which can be given and only generalities can be considered.