TuxScreen on SourceForge TuxScreen CVS search the Wiki
Browsing -> Wiki -> Main -> [UsingCramfs]
edit, info, topics, orphans, hubs and nodes, or recent changes in the Wiki create a new user or login

The "Compressed ROM File System," aka cramfs, is a read-only zlib-based compressed filesystem. It's a useful alternative to JFFS2 in two respects:

  • It's firmly read-only. While much less convenient than a read-write flash filesystem, it also means the contents of the filesystem can't be screwed up either accidentally or maliciously. This might come in handy for a TuxFirewall, say.
  • cramfs is very slightly smaller than jffs2. I presume this is mostly because of fs on-disk structure, since they're both based on zlib.
Making the tuxscreen boot off cramfs is fairly easy:

  1. Configure your kernel. Set CONFIG_CRAMFS=y or enable 'Compressed ROM File System' under the filesystems section in menuconfig. Build, upload, reflash.
  2. Fix /dev. BuildRoot makes /dev a symlink to /var/dev, which is a symlink to /boot/var/dev. /boot/var/dev and its contents are created by mkfs.jffs2 using sources/device_table.txt. It's a nice feature, since you can avoid having a bunch of files around only root can make -- it's also used to make tinylogin suid, also a priveleged operation. You could flee to root for a bit to make the files, make tinylogin suid, and put the result in /boot/var/dev, thus correcting the problem. Or you can use devfs.
  3. Using devfs: enable CONFIG_CRAMFS and CONFIG_CRAMFS_MOUNT. Replace the /dev symlink in the filesystem tree with an actual directory. Build, upload reflash. On the buildroot I tested, this will work most of the way, but since /dev/tty[1-4] are missing you can only log in from the serial console. Or edit /etc/inittab to refer to /dev/vc/[1-4] instead.
There are some valid reasons not to use devfs, one of which is that it makes the kernel bigger by an amount greater than the filesystem shrinks when you remove /dev/*. I tried that route first mostly because it involved fractionally less work. A better way would be to patch mkfs.cramfs to support a device-table file as mkfs.jffs2 does.

If you're doing setup work on a filesystem, having the thing in cramfs adds a lot of work. One way to do it is to put the root on NFS instead. DebianOverNFS has an explanation of how to achieve something resembling an NFS root -- mount it readonly, and you'll have something functionally a lot like cramfs but editable from your host PC while you get things arranged, then turned into a cramfs image at the end.

SourceForge Content of these pages are owned and copyrighted by the poster. SourceForge