[SOLVED] Strip down my working install to become an "appliance"
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Strip down my working install to become an "appliance"
I have always wanted to have music in every room in my house. After evaluating som technologies, I settled for the standard uPnP Media protocol.
So I bought a small, cheap computer (that used to be a thin client) with a VIA processor and compiled and installed Slackware 13.37 on it. Then I downloaded gmediarender, gstreamer and upnplib and compiled.
I have an uPnP Media Server on my NAS already, so I just needed to tell it to play on my new "streamer", and it really works! A small system, cheap enough for me to be able to buy some more of and install the same software on.
Problem is; in order to compile stuff, I installed ap, d and l packages. I have recompiled the kernel too to make it smaller and boot faster, so I installed k. But the system was only delivered with a 32MB IDE-compatible flash disk, so I temporarily installed a 4GB disk where all the stuff I needed could fit.
I have the flash disk as SDB right now, and my plan is to copy all I need to it and make it bootable and then but it back as primary again. And although I have been using Linux for many years now, this is something I have never done.
Does anyone have any good advice, links or pointers?
I'm going to list the sizes of the possibly critical packages in slackware 13.37+. I know you built gstreamer separately, but this is probably a good guess.
already at a total of 32 MB
I would build your system from scratch in a VM, only including the bare minimum, and space saving techniques. You might want to consider something other than gstreamer too. You could just strip slackware down some more, but it's hard to know what to keep and what not to keep without building it all yourself. And if you do build it yourself, you can use smaller alternatives like uClibc and busybox (these are possibly on your DD-WRT-- it is not stock "linux").
The most likely working approach to get your system running with only 32MB of disk space is not to strip down an existing distro, but to build one yourself with Linux From Scratch, I would think. This way you really have only the software you need and may be able to get it that small.
I don't know if this will be helpful to you but here is a link to a ZIP file with scripts that I created to make a scaled down Slackware boot CD. I did that in order to install Slackware on fake RAID where I needed to run "dmraid" from a custom boot CD.
The "bootcd.bin" file is an ISO image. In the ZIP file, the "customcd.conf" file is a Linux kernel configuration that you can use to build a kernel. It adds a "-CD" suffix to the kernel name. The "customcd" script creates a RAM filesystem and then an ISO CD image of the boot CD. The CD is about 8MB worth of data, and the actual file-system (sans kernel files) is around 5MB. If you have a lot of RAM in the system then you can create a compressed RAM filesystem and put that in the flash. That avoids the problem of needing to write to the flash for the OS to run.
The other folders have simplified configuration files.
This is not exactly what you will need but it may be a starting point.
If you don't want to build a linux from scratch, an option is to reuse files from a regular Slackware install to build a small initramfs with few core files, your app and its dependancies, and run all in RAM.
I quickly built a tree with the busybox contained in /usr/share/mkinitrd/initrd-tree.
Just added the dependencies (ldd is your friend here)
- bash, mc (my swiss-army knife), sshd and their deps (slang, ... etc.)
- dhcpd (but you could go with fixed addresses and get rid of it)
- alsa utils, all gst stuff (in bin, lib and share -- must admit I don't know anything about gst, so maybe you can trim the list!)
- a minimal /etc, /dev (no udev -- /dev includes direcly the (known) devices for your hardware)
Of course, no X environment, no doc, no man page, no messages in multiple languages, etc...
The complete initramfs image (cpio then gzip) is 10.1 MB. Without bash, mc and sshd, it goes down to less than 8MB.
It does not include any kernel module (I assume you have a kernel suited to your hardware).
With a dedicated kernel (let say 3MB - you can probably make it smaller), the total space on your flash disk should be below 15 MB (around 30 MB in RAM).
Add a few MB for kernel modules if needed, wireless tools if needed, core stuff I probably forgot, audio stuff and applications you may want to add... You will end with an "appliance" in less than 20 MB (kernel + initrd).
I haven't used Slackware since the latest kernel was 0.97, and I guess I overestimated how much I could strip down the install by just being very restrictive when I select packages...
I already use a CF card with IDE adapter. It is cool and quiet, but too expensive if I want to build multiple systems. The card and the adapter is actually more expensive than the computer.
Anyway, I'll start by looking into LFS, it sounds really interesting.
If that doesn't work for me I can try:
- using an initramfs image
- DD-WRT, or rather, OpenWRT
- a cheap USB stick (but it will look ugly!)
Anyway, thanks! I'll mark the question closed, and I might update it later if I find something interesting.
When using a RAM filesystem you can avoid wasting ram by building the required drivers into the kernel rather than using modules. A module takes up space in the RAM filesystem and also takes up space in RAM when loaded by the kernel. In essence you use twice the RAM for a driver by using a module. That's not true if the modules are somewhere else besides the RAM filesystem. If you use modules, try to put the modules outside the RAM filesystem, in flash or on a disk drive.
There are some other places that you may want to look for small Linux systems.
Damn Small Linux
Tomato USB (wireless router firmware)
Also, think about how you plan to interact with your music player. Will you have a keyboard and display on every "appliance" or will you use a small LCD display with buttons or touch screen? The point of making an "appliance" aside from lower cost is to make it convenient and tailored to the application. Have you looked at off-the-shelf network capable music players? Sometimes reinventing the wheel might not be as good as using what's already available. Of course, there is always the fun of creating something unique.
I work in the embedded software industry as a software engineer and product engineer. Sometimes an IBM compatible PC is not the best platform for an embedded application. There are other options to explore such as MIPS or ARM based boards or a System On a Chip (SOC). In your situation you want to keep engineering to a minimum and probably avoid hardware engineering completely. Still, you may be able to find some off-the-shelf Linux capable boards with hardware that will work for this. The main features to look for are a wireless/wired network interface, LCD, keypad/keyboard, and stereo or multi-channel audio output. You also need a CPU fast enough for the streaming and decoding of the audio.
Another choice is to use a separate USB audio output device, and get a board that has at least one USB port.
Also, think about how you plan to interact with your music player. Will you have a keyboard and display on every "appliance" or will you use a small LCD display with buttons or touch screen? The point of making an "appliance" aside from lower cost is to make it convenient and tailored to the application. Have you looked at off-the-shelf network capable music players?
My plan is to control music mainly using smartphones. There are a couple of nice apps that can work as an uPnP Media Controller. But for the player in the living room, I have a regular PC with a touchscreen. I have yet to choose software, but there are quite a lot of combined uPnP Controllers/Renderers out there.
Sometimes an IBM compatible PC is not the best platform for an embedded application. There are other options to explore such as MIPS or ARM based boards or a System On a Chip (SOC). In your situation you want to keep engineering to a minimum and probably avoid hardware engineering completely.
I have actually looked at that option too, but as you say, I need a board with audio, network, enough processing power and preferably an environment that makes it easy to implement the software. I have actually bought som stuff to play with (not only for this purpose). Then I came across these thin clients. They are small, silent, i386-compatible and cost about $50...
When using a RAM filesystem you can avoid wasting ram by building the required drivers into the kernel rather than using modules. A module takes up space in the RAM filesystem and also takes up space in RAM when loaded by the kernel. In essence you use twice the RAM for a driver by using a module.
Thanks for the tip! I was already set on compiling a kernel with everything I need (and only that) in it, but that was mainly because I wanted to speed up booting. I'm not done with that part yet though, I think I need to refresh my knowledge about the kernel build process quite a bit...