2

There's a system that a customer has that runs our software that is just going to be powered off at arbitrary times. UPS is not an option because the unit is moved from place to place.

Think of it as a psuedo-embedded system. It's headless and has no internet/lan connections, meaning that until the customer followed our instructions to remotely debug, no one had so much as logged in for several boot cycles before the problem arose.

The system uses, among other things, USB to serial converters running FTDI drivers. Recently the system was working great, and as expected, was powered off, then came up using uhci_hcd drivers for USB to serial converters.

Clearly something went wrong on shutdown and left the filesystem in some sort of bad shape.

Is there any way around this? I'm not concerned about guarantees for our software, I want to guarantee OS stability and consistency.

Do we need to rethink Ubuntu 10.04? I know it's a bit overkill if we don't even log in 99% of the time, but the driver support seems a little better and the installation is perhaps a little nicer than other distributions.

Does anyone have experience hardening a system in this manner? Things on my list would include automatically resolving file system checks with no user interaction, uninstalling unneeded packages that might cause configuration/timing issues, etc.

To be clear, data loss is NOT a concern -- always booting up into the same configuration is a top priority.

Any good resources for reading up on this? I don't even know what I would search for exactly -- I haven't done a ton in the way of hard core sysadmin stuff in the past.

JWman
  • 23

1 Answers1

1

Most embedded devices will split their storage into several sections. You could mount the OS partition read-only with a read-write ramdisk overlay -- any changes are not written to disk, so nothing to corrupt, and no possibility of the state changing on boot up. Add an additional partition for any data you need to write persistently, and use (if you're using ext3/4, data=journal will help ensure data consistency beyond the normal journaling.)

Note: you'll need the ramdisk overlay as many applications write various state files into /tmp or /var.

David
  • 1,101
  • That's a pretty good idea... Is this something you can configure post-install, or does it need to be on OS installation? Also we'd want to still have the ability to write log files, but this could be accomplished via flash memory or something I suppose... – JWman Jul 23 '11 at 14:22
  • Oh right, we'd still be able to write logs to a different partition, since you're proposing that only the OS partition be read only. – JWman Jul 23 '11 at 14:30