initrd
The term « initrd » is short for « initial ramdisk ». It refers to a file of the same name, used by Linux systems during the boot process in order to load certain modules (drivers, and the like) prior to the full system being brought online. An example usage of the initrd would be to load a module for a RAID card, so that the actual filesystem – and all of the delicious data contained within – can be accessed properly.
There are (perhaps unfortunately) a number of ways in which initrds can be constructed and implemented. Generally speaking, the actual file is a compressed archive, which may contain further archives, filesystems, configuration files, and so forth. Over the years, different distributions have handled the initrd in different ways, such that one distro’s method of constructing an initrd may be totally incompatible with that of another.
ramdisk
A « ramdisk » is, as the name implies, a sort of filesystem which has been loaded into RAM. Although it does not physically exist, it appears for all intents and purposes to be a normal disk, which has the advantage of being seamless to the user (and to the system). Ramdisks are handy because, compared to physical disks, they are fast. Within the context of the initrd, however, speed isn’t a concern – it’s the versatility of the ramdisk that is key. As in the module example i mentioned initially, the various bits and peices of hardware in a given computer often require special drivers to make them function properly. These drivers can be built directly into the kernel, but often, for reasons of ease of use and cross-compatibility, it’s easier to put them into the initrd, and then load them via the initial ramdisk that gets built when the machine boots.
The basic idea behind a « loadable kernel module » (or just module for short) is, again, to add support for hardware, special filesystems, and the like, which the kernel doesn’t natively understand. Modules can be loaded at any time, but for the most part, they are initialised at boot time, so that the kernel can interact with things like RAID, audio, or video cards, non-Linux filesystems (NTFS, for example), or even more esoteric items like robotic controllers and (the dreaded) software modems.
gzip (and tar, too !)
Gzip is, along with « tar », arguably the most ubiquitous archival format pairing in the Linux world. Generally speaking, a gzip archive is a single file which has been compressed using the gzip binary. Commonly, gzip is used to compress a « tar » archive, which normally does not use compression, but which can contain any number of files in a single archive. Together, they are used to create « .tar.gz » or « .tgz » files, which are more or less the standard way to create compressed archives in Linux ;
cpio
It is a rare and glorious thing when ancient technology is updated and used constantly from day one. Take the lightbulb, for example. Or fire. Or « cpio » . It’s basically like tar (mentioned above), in that it can be used to take any number of given files, and create a single archival file containing said files. Like tar, compression isn’t part of the deal, and gzip can be used to compress a cpio archive as normal.
While cpio has a long and storied history (it was first specified way back in 1977), over the years, it has increasingly replaced by tar in many implementations. Some time ago, Red Hat decided to use cpio (instead of tar) for their ultra-popular packaging format « RPM ».
Add Module into intird
step1:
$ cp
$ cd /tmp
$ file initrd.img
initrd.img: gzip compressed data, from Unix, last modified: Fri Nov 2 15:54:12 2007, max compression
step2:
$ gzip -d initrd.img
gzip: initrd.img: unknown suffix -- ignored
Uh oh ! By default, gzip doesn’t handle files with suffixes it doesn’t understand (i.e. « .gz » ). The easiest way to deal with this is simply to add the appropriate suffix, then try again :
step3:
$ mv initrd.img initrd.img.gz
$ gzip -d initrd.img.gz
This gives us a single file (as we expected) : initrd.img . Though it has the same name as the file we started with, it’s not the same data at all. This initrd.img is larger than the original, and most importantly, it’s a different type of file
$ file initrd.img
initrd.img: ASCII cpio archive (SVR4 with no CRC)
step4:
Unpack the initial Cpio Archive
As i mentioned above, cpio has a long and storied history, which is reflected in the myriad of arguments and options that can be provided during normal usage. The command we’ll be using at this stage will be :
$ cpio -i -d -H newc -F
The arguments are, in order :
* -i : « copy-in » is more or less like saying « extract » in the parlance of cpio.
* -d : « make directories » allows cpio to re-create the directory structure in the archive, instead of just unpacking everything to the same place.
* -H newc : « format type » defines the particular format used by this cpio archive. Over the course of cpio’s history, numerous formats have been used for various reasons : « newc » is an SVR4-based format that allows for large files and filesystems. Remember the archive type from above ? This is why we needed to make note of it.
* -F
* –no-absolute-filenames : as the name suggests, this forces cpio to unpack the contents relative to where we executed the command. Basically speaking, it prevents the possibility of cpio trying to write to our root filesystem, which could have disastrous results.
step5:
First we must make a directory in which to unpack the archive, then we can proceed :
$ mkdir /tmp/initrd
$ cd /tmp/initrd
$ cpio -i -d -H newc -F ../initrd.img --no-absolute-filenames
16442 blocks
The number of « blocks » refers to the amount of data that was unpacked – it is a measurement, like bytes. This value may be different for you, as not all initrd’s are created equal.
step6:
Just push in the required drivers to appropriate locations
step7:
$ cd /tmp/initrd
$ find . | cpio -o -H newc | gzip > /tmp/initrd.img
$ file /tmp/initrd.img
/tmp/initrd.img: gzip compressed data, from Unix, last modified: Wed Jun 10 19:39:51 2009
No comments:
Post a Comment