Read Only Debian Squeeze on internal NAND

Hi, I tried several embedded linux systems for my target device (seagate dockstar) and finally went back to Debian/Emdebian. The result is partly based on Jeff's work.

Since I like to install the system onto the internal NAND flash, my main requirement was to use a READ ONLY root file system - or at least one without write access besides configuration issues.

The obviously volatile result was made public here:
http://gitorious.org/dockstar/emdebian-multistrap

If anyone looks for an example for:
a) create the rootfs apart from the target hardware
b) read only rootfs
c) using multistrap of Emdebian to create a Debian compatible rootfs
might have a look at this.

The solution is not perfect but works for me. Makefiles would be a better way than bash skripts, but at the beginning I wasn't aware of the recipe/make character.

The skript set produces a ubi-image, ext2 image and tar.gz of the generated rootfs. The way how this is created is ugly and not very generic. But most of the settings could be set via configuration variables.

The final rootfs includes samba, transmission, autofs and mediatomb besides the common packages needed for a proper debian system (ping and wget are served via busybox for example). The resulting size is about 100MiB and fits well in the 219MiB parition on the 256MiB NAND. After installation I have a 50% usage on the rootfs.

Gimmick: /var is overlayed via aufs: RO-base (squashfsimage) + RW in-memory -> solves most write ambitions of many packages. If you really need a configuration change under /var/* you can resquash the sqfs-image.

Currently I am working on automounting my storage disk and show its mount state via the dockstar leds. If the led indicates "nothing is mounted" it is safe to power down the dockstar without ssh in and shutdown (rootfs is readonly). Note: Loading the kernel and initramfs from nand is faster that loading from usbstick.

If you prefere a full featured system, do NOT use NAND. Just take a USB stick and put a full debian (or plugbox linux) on it and live with the disadvantages like "ssh in and shutdown manually".

Thanks for posting this. A couple of questions:

Why do you bother with ubifs if you want a read-only system? Squashfs will be more space-efficient.

Also, are you able to use your union-mounted /var to do a full apt-get update/upgrade cycle? The package lists can approach 100MB if you have several repos in your apt sources. And doesn't the /var/lib information needed by dpkg get lost?

Hi Eric. Many thanks for the feedback.

Squashfs - Simple question, two reasons:
A) Squashfs is readonly, I won't be able to mount it rw, change some configuration for the next reboot. Using squashfs results in changing the configuration every time apart from the target and reflash it. That was NOT the goal.
B) It does not provide any wearleveling (which is not a big problem, since the configuration issues meant to be rare), but NAND memory could also break just be reading (I didn't believe that before, but the web thinks, that's true)
UBIFS) provides wearleveling, inline compression, kernel and ramfs could be loaded by u-boot from ubiparition, writing on it is still supported in case of changeing some package configuration after flashing (I don't like to flash the whole squash image every time I add a new drive or user)

The system was not designed to be a FULL featured Debian system, but anyway it is possible to call an apt-get update and install some packages on it. I don't want to keep 30MiB just for a package database. The database is built via apt-get update in memory (/var/rw-overlay) and will be lost on next reboot - that's desired. I don't intend to install packages that often, but it is possible in case of "emergency".

Btw: Running package updates on squashfs-rootfs won't work... ;-)