Self-Hosting Movies with MoviX

How to build your own dedicated distribution.
Making the CD

To create a bootable CD containing the kernel and filesystem created above, you need a boot image. The most convenient choice you can make is the IsoLinux boot image, called isolinux.bin and part of the SysLinux package, so your system is able to load the initrd.gz no matter what its size.

Begin by creating a new directory, say /cdrom. Then, create a /cdrom/isolinux/kernel directory; put the initrd.gz and isolinux.bin files in /isolinux and the kernel in isolinux/kernel. Finally, inside /isolinux edit a isolinux.cfg file to tell the boot loader the boot options you want to use (see Listing 2).

Listing 2. Simple isolinux.cfg File

The format of this file is similar to the lilo.conf format; consult the SysLinux web site for detailed information. A nice improvement is the possibility of calling up to 10 text files from the boot prompt, using the F1-F10 keys. That is, there is a way to make the user able to access documentation about boot parameters right at boot time, directly from the CD. For the type of distribution we are talking about, this is a useful feature. Another nice feature is the capability to visualize pictures rather than text, for example, making it possible to add a “splash” boot logo to the distribution (16 colors at most; otherwise, try the BootScriptor package).

To produce a bootable CD image, run mkisofs with the following options:

mkisofs -o /tmp/distro.iso -r -V "My distro" -v -no-emul-boot \
  -boot-load-size 4 -boot-info-table -b isolinux/isolinux.bin \
  -c isolinux/isolinux.boot /cdrom

Then, burn the image:

cdrecord dev=0,0 -v -eject /tmp/distro.iso

Now you can reboot the system to be sure the burning was successful and the CD is really bootable.

Detecting Hardware

As is, this CD already is a pretty good hardware checking tool, and it easily can be turned into a good recovery tool. Indeed, simply by booting from it, you can find out the brand and model of most PC hardware (everything except ISA cards) by looking at /proc/pci and /proc/cpuinfo. By taking a look at the kernel boot log with dmesg, you also may find information on the P&P ISA cards. Adding to it binaries such as e2fsck, you have all the tools necessary to recovery a Linux system experiencing problems.

On the other hand, no card is supported by the system at this point—no NIC, no audio card, no SCSI card, nothing. Although this probably is okay for a rescue CD, it most likely is not okay for our mini-distribution.

The standard way of activating kernel hardware support is to use kernel modules, but simply loading all possible modules is not a good idea. You need some autodetection tool. Several autodetection tools have been developed by big Linux distributions: kudzu (Red Hat), libdetect (Mandrake, but now they use kudzu too), discover (Progeny). But these seem much too complex for the kind of small distribution we are building.

Luckily, you can base a simple autodetection procedure on the devfs. Indeed, its automatic creation of device nodes can be used as an effective way of checking whether some device has been recognized by the kernel. For example, the device node /dev/sound/dsp automatically is created only when you load the right module for your audio card. So, you can easily write a script that loads, one by one, every single audio module and verifies every time whether the audio device appeared. If it did, then you successfully loaded the driver and can stop the loop; otherwise, you can unload the module and go on. See Listing 3 for a simple Perl example.

Listing 3. Loading Audio Card Module with Perl

Hence, our method of autodetecting some kind of card, say the audio one, follows this path:

  • go back to the distribution kernel directory and activate the support for all possible audio cards as modules;

  • compile all modules with make modules

  • install the modules on your system with make modules_install (to avoid overwriting the “true” modules directory, make sure you rename it before installing the distribution's);

  • re-mount the initrd.gz file on /distro (remember to gunzip it before mounting it or it won't work);

  • copy the newly created directory /lib/modules/2.4.20 to /distro/lib/modules/; if the space left is smaller than ~.5MB, build a new initrd, as explained above, and assign to it more space;

  • add some script to load all possible modules and add a line to call it in rc.S

I don't have enough data to tell you whether this method is always reliable, but I've been using it in all MoviX packages for four months. Thus far, I have received no negative feedback, so at least I can tell you it is not totally unreliable.

Repeating this procedure for every kind of driver you need, you can easily build a script able to autodetect all hardware supported by Linux on any PC. You can find working examples of such scripts in each MoviX package.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Self-Hosting Movies with MoviX

Anonymous's picture

Thanks for this very informative article, it's just what I'm looking for.

BTW, to avoid overwriting the modules of the running Linux, you can do

make INSTALL_MOD_PATH= modules_install

Suggestion for yet another dedicated distro.

Anonymous's picture

A distribution that boots into:

Freevo: http://freevo.sourceforge.net

or:

MythTV: http://www.mythtv.org

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix