PictureFrame Linux®

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

Backstory

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.

Sub projects

• bootloader and configuration
  (I used GRUB because I thought it would be convenient to netboot with TFTP. I didn't get netbooting to work, but GRUB worked great otherwise)
• custom kernel tailored to my hardware - kernel.config (based on 2.4.23, IIRC)
• ramdisk image
  • The list of programs I wanted to be on the system - programs.txt
    (this file is an input to the build.pl script below)
  • filesystem heirarchy template
    • standard unix directory structure - template.tgz
    • essential unix configuration files
    • scripts that implemented my application
      • linuxrc My system startup script
      • usbhunt A script to pull photos from a digital camera when connected via USB (this also resizes the images to fit on screen)
      • cdhunt A script to pull photos from a CD when inserted (requires cd_poll)
      • slideshow A script to display images in the image store directory; or a "please wait" image after receiving SIGUSR1
    • Utilities to do something unusual (needed by my scripts)
      • execvt.c A program to run other programs on new virtual terminals
      • cd_poll.c A program to detect media change events on the cdrom
        This only works on drives that implement GET_EVENT
      • cdpoll-new.c A program to poll cdrom drives for valid media.
        I didn't use this, and actually developed it later for another project. This works on drives that do not implement GET_EVENT. It's only included here for informational purposes.
    • Shared libraries that couldn't be discovered automatically
  • script to merge the template and programs into a ramdisk image image - build.pl
    (This script also identifies required shared libraries and includes those.)
• Procedures for doing the install
• Instruction manual (this never got done)
• Hardware transformation

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.

• /etc/nsswitch.conf
  I didn't identify this as important at first, so I didn't include it. Lots of things broke as a result. Without it, /etc/passwd isn't even looked at! I had no users. SSH complains that "you don't exist, go away!"
• Plugin modules in general - the build script uses 'ldd' to find shared libraries, but there are some things this technique won't catch, mainly plugin modules. The things that got me were: /lib/libnss_*.so, /lib/security/pam*.so, /usr/lib/ghoto2/*/* and /usr/lib/gphoto2_port/*/*
  (I found these by using strace on the programs that needed them.)
• GRUB refused to recognize my network card, even when I build it with the driver for that card. I blame the hardware for this one.
• Boot options to the kernel
  For reasons I still don't understand I needed to pass the following options to the kernel: root=/dev/ram0 ramdisk_blocksize=1024 ramdisk_start=0. It's the ramdisk_start option that got me; I thought it would default to zero, but it didn't. This took a while to figure out.
• Don't use a journalling filesystem (ext3)
  Any journalling filesystem has to reserve extra space for the journal. I started using ext3, because, well, I wasn't thinking. My end product was a read-only ramdisk image, where journalling wasn't useful anyway. When the build script was running, the filesystem would fill up early, and in a non deterministic fashion, because the journal takes up space. I eventually realized my mistake, and switched to ext2.

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 10.0.0.10 88 < initrd.img.gz . (Where 10.0.0.10 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.

References

• Duo Digital Frame was my inspiration
• From Power up to Bash Prompt was a useful reference.

disclaimer

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