Self-Hosting Movies with MoviX
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).
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.
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.
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.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Concerning Containers' Connections: on Docker Networking
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Three More Lessons
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development