I'm looking for methods and software to help create a variant of lubuntu that will restore itself to an install state and/or update on every boot. I'm thinking of doing things like putting the root filesystem on a squashfs and using unionfs and tmpfs to make root writable, but automagically restorable. I'm thinking of updating the squashfs with rsync. Perhaps there are other ways to approach the problem. Perhaps root needn't be writable at all. All thoughts welcome.

The home dir would be writable in the usual way.

The goal, if it matters, is a Linux that's simple to maintain from the home office, but that functions correctly for customers. We have some custom software that we wish for customers to be able to run trivially on equipment we provide. Ideally these devices would have a "restore to factory" function that would put it back the way we intended. If this is part of the normal boot cycle, so much the better.

Why lubuntu? Personal preference for this application. It has a usable desktop, but doesn't take up much ram.

  • 1
    Sounds like you're looking for a linux version of "deep freeze", try the code here utux-utux.blogspot.com/2008/02/… it basically takes a copy of the dir and restores it. Maybe it'd provide a headstart ?
    – Sirex
    Jan 6, 2011 at 14:12
  • 2
    I'd just make the file system read only... Only /tmp and /var need to be writable (and even that can be RO depending on what software you run).
    – Chris S
    Jan 6, 2011 at 14:16
  • 1
    That's simple to do with ZFS and a snapshot of root. I'm not sure if anyone has done a Linux boot on ZFS due to the licensing issues but there are plenty of other Unix distributions available.
    – JOTN
    Jan 6, 2011 at 14:17
  • Sirex, that might be a good head start. I like it. Chris S, you're probably right. There's probably no good reason to leave / writable or even have a /var depending on how much stuff I can strip out.
    – jettero
    Jan 6, 2011 at 14:27
  • Somewhat of a duplicate: serverfault.com/questions/177357/…
    – l0c0b0x
    Jan 6, 2011 at 22:06

2 Answers 2


SquashFS is the underlying mechanism used in LiveCDs. There are others, but they all represent an overlay. What you want to do is study LiveCDs to see how they get the root mounted on top of the CD (read only) and either a RAM filesystem (easily disposed of) or lay onto a loopback device file on a local drive (non-volatile).

What I think you want to do is create a local file for squash and either delete it as the last step of a shutdown or the first step of a startup. Automatic cleanup is required. Then you guys can distribute an image of the base machine with periodic updates.

Oh, and before you get any bright ideas, multiple overlays might be possible but are strongly discouraged due to some nasty VFS complications.

Of course, you could create loopback files on a local drive for home directories, as though they were encrypted home directories, which might allow for easy backup to external media.


This is pretty much what you get with, e.g., Knoppix. It uses a read-only filesystem that gets merged with a read-write tmpfs filesystem when the system boots. When you reboot, you lose all your changes.

You might also be able to manage this using LVM snapshots. You'd probably need a cusom initramfs that would delete and re-create the snapshot when the system boots.

  • 2
    +1, a live boot CD is what is being described. Jan 6, 2011 at 19:09
  • The computers we're using don't actually have CD drives. I think Knoppix main benefit is the boot cycle. I'm not sure it helps with mounting a squashfs or anything else.
    – jettero
    Jan 10, 2011 at 11:14
  • Knoppix boots on a read-only filesystem and then merges in a read-write filesystem at boot time. That's exactly what you've described. Lack of CD drives isn't much of a limitation, and even if it were using Knoppix as an example would save you from reinventing the wheel.
    – larsks
    Jan 10, 2011 at 16:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .