PictureFrame Linux®

How simple can you make a GNU/Linux® system? What are the minimum things that Linux® needs to do something useful?


In December of 2003, I wanted to convert an old laptop into a digital picture frame, and I found myself asking these questions. Now, a laptop isn't the sort of embedded system where you really need to economize on space. If I were really trying to minimize the size of the distribution, I would have used things like BusyBox and dietlibc. I had a perfectly good distribution installed on it before I started. I wasn't trying to minimize size; I wanted to minimize complexity.

In doing so, I created a system that boots in about 5 seconds (of which several are the BIOS check). It spins down the hard drive when it's done loading the pictures, so it's nearly silent. It does nothing it doesn't need to do, so it uses little electricity and generates very little heat. It's compressed kernel image is 1.1MB and the compressed filesystem is 8.1MB, but I wasn't really trying to make those small - it could be done in much, much less space.

False start

At first, I started with a Knoppix installation and tried to remove everything I didn't need. Unfortunately, a standard Linux® distro has so much stuff that isn't needed for an embedded application that just sorting through the packages to find what I needed was too painful. I literally spent an hour unselecting debian packages for removal - and for many was uncertain whether I needed them or not. Even when I was done, there would have been hundreds of packages that Debian considers important, but I probably didn't need.

Starting from zero

Instead, the approach that I took was to build a custom kernel that had just the drivers I needed, and build a custom filesystem that had just the programs I needed. Start with nothing, and add only what was essential. Rather than building every piece by hand, I took all the programs and libraries that I needed from my workstation/server. (which was running some flavor of Debian). The tricky part was determining what the truly required programs and libraries were, and building a process for getting them set up.

Concept of Operations

The digital picture frame boots linux® and runs a script that displays pictures in a cycle using the program 'fbi'. The main filesystem is a ramdisk and the hard disk spins down when idle. The hard disk contains the image-store.

When a CD or DVD is inserted, the system will scan it for JPEG images, and copy them to the image-store on the hard drive. When this is complete, the disk is ejected.

When a camera is attached to the USB port, the system runs gphoto2 to copy all pictures off of it into the image-store, and resizes the images to fit on the screen.

When USB flash media is attached to the USB port, search it for JPEG images. (This never got implemented)

The network will configure using DHCP, with reasonable defaults ( and Samba will share out the image-store. Security will be implemented by unplugging the ethernet cable when not wanted, and all the software will be on the ramdisk partition, where it can't be modified. The image-store will be mounted noexec.

(DHCP didn't get implemented in time.)

If possible, have USB keyboard emulation work, and have bash running on additional virtual terminals.

Sub projects

The stumbling blocks

Here's some of the things I got stuck on. Sadly, I was so rushed I didn't take notes on some of the others.

Other neat techniques

File transfer with netcat

When I couldn't get ssh or scp to work, (but before I took the laptop apart) I could still transfer files over the network by using netcat, aka 'nc'. On the laptop/pictureframe, I'd do something like this: nc -l -p 88 > /mnt/hd/initrd.img.gz, and on the workstation/server, I'd do this: nc -q 1 88 < initrd.img.gz . (Where was the IP address of the laptop/pictureframe)

using Virtual Terminals without init

The pictureframe doesn't have 'init'. It doesn't have 'getty' or 'login'. Most things it doesn't run as daemons; it just runs them on a linux VT. There's a slick little program I found called 'execvt' to run programs on an unused VT. I had to adapt this program to the 2.4 kernel and to devfs, but that wasn't too hard.

When the system runs, it just runs bash as root on VT #1 & #2, runs the cdhunt script on VT #3, usbhunt on VT #4, and the slideshow on VT #5. This means that by attaching a keyboard, it's possible to monitor the progress of the scripts by switching VT's with "Ctrl-Alt-Fn", the standard Linux® thing.



Hopefully this project will inspire others to try similar things. I thought it was fun, and educational. Do so at your own risk. If you break your hardware, software, love-life, or head, don't blame me. If you have some success or questions let me know

Linux® is a registered trademark of Linus Torvalds.

Projects page, Dan Risacher