Building Tiny Linux Systems with BusyBox, Part 3
Another good thing Erik and others have been working on is uClibc, the free embedded C library. I had previously identified this library as being under the GPL license, but I was mistaken. uClibc is under the LGPL and is thus fine for linking with proprietary applications. You can now make BusyBox statically linked to run with uClibc rather than libc5 or libc6. The result is less than 300K in size, and of course, it gets even smaller when the ROM filesystem is compressed. In the uClibc source directory, edit the configuration file and change HAS_MMU to true, HAS_FLOATS to true and KERNEL_SOURCE to the location of your kernel source. Change the definition of the CC to be $(CROSS)gcc -Os to optimize for smaller code size. If your version of gcc does not support the -Os flag, use -O2 instead. Run make to build the libc.a library. In this article, uClib supports only static linking, but dynamic linking has just started to work. We'll give it a little time to stabilize and will cover it in the next issue.
Now, go back to the BusyBox source, edit the Makefile and look for the lines that say ``to compile vs. an alternative libc, you may need to use/adjust the following lines of source to meet your needs''. Below that section are lines that define LIBCDIR, LDFLAGS, LIBRARIES, CROSS_CFLAGS and GCCINCDIR. Most or all of these definitions are commented out. Uncomment the definitions to enable linking with uClibc. Change the definition of LIBCDIR to be the location of your uClibc source. Edit Config.h, and comment out the BB_GETOPT and BB_FEATURE_NFSMOUNT definitions to disable the getopt command and the ability to mount remote NFS filesystems with the mount command. As I write this, there's a bug preventing the BusyBox getopt command from working with uClibc, but that might be fixed by the time you read this article. uClibc does not currently include network support, although I'm sure that someone will add it eventually.
Now, rebuild all of BusyBox with the make clean and make commands. On my system, the result is a statically linked executable of 297,620 bytes in size.
Remove the file tiny-linux/bin/getopt. That file won't be generated this time because we turned off the definition of BB_GETOPT. If we don't remove it, we'll end up with two versions of BusyBox and a lot of wasted space.
Use the instructions above under ``Getting Comfortable with the 2.4 Kernel'', starting with the command:
make PREFIX=../tiny-linux install-hardlinks
This generates another floppy. Boot the floppy to test it.
Probably the biggest missing feature in your tiny Linux system so far is the lack of writable storage. Let's fix that now. We'll use a VFAT filesystem for the writable storage. This is an extension of the old DOS FAT filesystem to handle long and mixed-case filenames, introduced for Windows 95. Since your floppy already uses a DOS filesystem to hold the kernel and the compressed ROM image file, it's easiest to use VFAT to extend that filesystem for this example. Become root. Create a tiny var directory. This directory tree will hold files that will be writable on your tiny Linux system. You will copy it to the floppy later on, and it will be mounted on /floppy/var when your tiny Linux system boots.
Move your entire tiny-linux/etc directory to tiny-var/etc using the command:
mv tiny-linux/etc tiny-var
Create two other directories: tiny-var/shm and tiny-var/home. The first directory is used by the mount command as a placeholder when providing shared memory, and the second is used to hold home directories for users.
Now we'll create symbolic links in tiny Linux to redirect some directories to /var so that you will have access to your writable storage and then redirect /var to /floppy/var. We do the symbolic links in two levels here so that the location of all of the writable storage can be changed by replacing only one link:
cd tiny-linux rm -f -r var mkdir floppy ln -s floppy/var var ln -s var/etc etc ln -s var/home home
Create the shell script startup.sh as shown below:
#! /bin/sh /bin/mount -t vfat /dev/fd0 /floppy exec /sbin/initThis script will run when the system starts, instead of init, because we'll provide a special command-line argument to the kernel. It will mount the floppy so that the contents of /etc are correct before init starts. Note that exec/sbin/init is different from simply running /sbin/init. The exec command says to replace the shell with the given program, rather than run the program as a subprocess of the shell. Thus, init will run in the same process-ID as the shell, which in this case will be process-ID 1. This is important as the kernel gives process-ID 1 some special properties, and init will not run properly unless it's in process-ID 1.
Change the mode of the script so that it is executable:
chmod 744 startup.sh
Change directory up one level (cd ..):
Use an editor to modify the file tiny-var/etc/inittab, which tells /bin/init, the system startup program, which processes to start. The entire contents of the file should look like this:
::sysinit:/etc/init.d/rcS ::askfirst:/bin/sh ::ctrlaltdel:/sbin/swapoff -a ::ctrlaltdel:/bin/umount -a
We're adding lines here to cleanly unmount filesystems at shutdown time, so that the floppy filesystem containing the writable files will be unmounted. Tasks on lines that start with ::ctrlaltdel: will be executed just before the system halts. We also turn off any swap partitions that are activated, just in case they live on a mounted filesystem.
Create the special device file necessary to mount the floppy:
mknod tiny-linux/dev/fd0 b 2 0 chmod 644 tiny-linux/dev/fd0
Now, regenerate the ROM filesystem from the tiny Linux directory, using genromfs as before, and compress it using gzip to create a new fs.gz.
Mount your floppy with this command:
mount -t vfat /dev/fd0 /mnt
and copy the new fs.gz to your tiny Linux floppy, replacing the old ROM filesystem.
Copy the tiny var directory tree to your floppy with the commands:
mkdir /mnt/var cp -R tiny-var/* /mnt/var
Tell the kernel to run /startup.sh instead of /sbin/init by editing the file /mnt/syslinux.cfg. Change the line that says
APPEND root=/dev/ram0 initrd=fs.gzto say
APPEND root=/dev/ram0 initrd=fs.gz init=startup.shChange directory to /, and unmount the floppy with this command
umount /dev/fd0You should now be able to boot the floppy, and the directories /var, /etc and /home should be writable.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
- BASH script to log IPs on public web server
1 hour 16 min ago
4 hours 51 min ago
- Reply to comment | Linux Journal
5 hours 24 min ago
- All the articles you talked
7 hours 47 min ago
- All the articles you talked
7 hours 51 min ago
- All the articles you talked
7 hours 52 min ago
12 hours 17 min ago
- Keeping track of IP address
14 hours 8 min ago
- Roll your own dynamic dns
19 hours 21 min ago
- Please correct the URL for Salt Stack's web site
22 hours 32 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?