Erik van Konijnenburg announced Yaird, "Yet Another mkInitRD". Implemented in Perl, he describes the work in progress and proof of concept as "a rewrite of mkinitrd based on hotplug algorithms." Erik explains that he reviewed the existing versions of the mkinitrd shell script and concluded, "they capture a lot of knowledge about the boot process, but don't always understand when a new kernel uses a different module name than the old kernel, may rely on modules compiled into the kernel, and don't always catch errors at the earliest opportunity." Instead, yaird utilizes the sysfs virtual filesystem and existing hotplug algorithms to determine what drivers are needed to support the current hardware, thereby minimizing the number of special cases and general information about modules that the application itself must know about.
The mkinitrd and yaird applications create an initrd, or "initial ramdisk". This ramdisk usually contains a small root filesystem with preloaded drivers necessary for accessing the block device that holds the real root filesystem, and that knows how to start the init process. The kernel first loads the initrd filesystem, and then is able to access the block device with the real filesystem to load kernel modules, and ultimately to remount the real root filesystem. If all necessary drivers are instead compiled into the kernel, an initrd is usually not necessary. However distributions providing kernels that work on countless varieties of hardware don't necessarily have this option. Erik explains that using yaird, "a distribution can produce a kernel with a large amount of modules that will run unchanged on practically any hardware, without introducing a large number of unused drivers that would waste RAM. In a sense, the initrd image customises the kernel to the hardware it happens to be running on."
From: Erik van Konijnenburg [email blocked] To: linux-hotplug-devel, [email blocked] Subject: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts Date: Thu, 17 Feb 2005 21:06:20 +0100 OK, time to stop polishing and start publishing. This is to announce yaird, Yet Another mkInitRD, a rewrite of mkinitrd based on hotplug algorithms. MOTIVATION ========== Why a rewrite? The versions of mkinitrd that I studied, Debian sid and Fedora FC3, have some problems: they capture a lot of knowledge about the boot process, but don't always understand when a new kernel uses a different module name than the old kernel, may rely on modules compiled into the kernel, and don't always catch errors at the earliest opportunity. Assumption: there are three issues that cause most of these problems. - Backward compatibility: sysfs provides a wealth of information about hardware, but if you have to support 2.4 kernels, you have to limit yourself in the use you can make of that information. - Originality: hotplug does a pretty good job of finding the appropriate modules for a device, basically because it closely follows the algorithms the kernel uses for matching hardware with modules. Deviating from those algorithms is unlikely to produce a more robust result. - Shell scripting: beyond a certain level of complexity, the shell syntax makes it difficult to focus on the data structures you're trying to process and makes it difficult to do rigorous error checking. Yaird is intended to find out whether that assumption is correct: if so, a program to build initrd images will be more reliable if it's written in perl, if it uses sysfs to determine what hardware needs to be supported, and if it closely follows the methods hotplug uses find the modules needed to support some hardware. STATUS ====== There is working code: yaird booted the machine this note is written on. Code is available online, there also is a paper that discusses the workings of the application in detail. http://www.xs4all.nl/~ekonijn/yaird/ So far, the program works correctly on every machine it's been tested on, but with only two test boxes that does not mean much. Basic creature comforts are in place: "configure; make" but no RPM or deb files, a README and help option but no manual page. Features: - understands SATA and IDE. USB sticks and SCSI should work, but are untested. - understands MDADM and LVM2, activates only necessary devices, understands stacks like LVM on top of stripe on top of mirror. - handles both initrd and initramfs. - understands USB keyboards. - understands hotplug blacklist. - knows that a module compiled into the kernel does not need insmod. - understands /etc/fstab, including niceties such as labels, uuids and octal escapes. - image generation understands symbolic links and shared libraries. (should support 32bit emulation on 64bit kernels; untested). - templating system to simplify tuning the initrd image to the distribution. - avoids hard-coded device numbers; does not require devfs. - testing mode gives detailed overview of the systems hardware and the modules needed to support that. There are rough edges in practically every feature: this is suitable for testing, but not for production use. TODO ==== (1) Testing so far is 100% successful, but with just two boxes to play with, that's not saying much. If you can find space to test the code on your system, your results are highly appreciated. At this point, hardware testing is most valuable: I already know that dm-crypt is unsupported for now, but whether this stuff can boot a powerbook, sparc, or just about anything else is an open question. (2) Feedback. This may be an interesting idea, but how does it relate to other new stuff floating about? In particular, what about the work that's going on putting udev on initramfs: are these approaches complementary or alternatives? Different perspectives on where this stuff fits in would help. (3) Support more configurations. dm-crypt is unsupported for now, and so are multipath, swsusp, EVMS, NFS and loopback mounts. Implementing this stuff becomes interesting once there are some tests results that the basic ideas work in practice. Regards, Erik
From: Jeff Garzik [email blocked] Subject: Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts Date: Thu, 17 Feb 2005 16:50:05 -0500 Erik van Konijnenburg wrote: > Features: > - handles both initrd and initramfs. Comments: * Having a mkinitrd that's not a shell script is a godsend. I would endorse yaird on that fact alone :) * I've long wanted a "mkinitfoo" that would create .cpio.gz for initramfs by default. So, good job there, too. * Eventually your script will need pull in, into the initramfs, klibc and programs linked against klibc. Jeff
The explanation for initrd is wrong.
This is wrong.
The initrd image does not contain any kernel image. It is a filesystem containing only modules and other files necesarry to mount the real root file system.
To proper boot you need both a separate kernel image and (usually) an initrd.
--adrian
no initrd
> (usually) an initrd.
or without initrd.
It does contain *parts* of th
It does contain *parts* of the kernel, the modules which I imagine might be said to be some kind of 'kernel image'.
Noooo
Please kill initrd instead, it is the singlemost annoying thing in Linux. Please make an OS that can boot by itself and don't need this stupid arcane beast. Take a look at how FreeBSD boots to see the light, Linux really sucks in this aspect.
In what way does FreeBSD hand
In what way does FreeBSD handle it better?
The only thing I can think of is that the bootloader seems to load modules for the kernel before it hands over control, but for Linux to be able to use that every bootloader (LILO, GRUB, aboot, yaboot, silo, etc) would have to be updated to load the moudles and be able to read the root filesystem to get to the modules.
And from what I can remember, the only optional thing loaded by the bootloader is ACPI and anything added by the user after installation, all of the filesystem and driver modules are compiled in statically.
multi-stage boot
No, you don't need to modify existing boot-loaders, you just need a multi-stage bootloader. Many boot-loaders are *already* multi-stage capable. Basically, instead of the initial boot-loader loading the Linux kernel, it would load a second boot-loader that is specifically designed to load the kernel and modules. GRUB comes with several such second-stage bootloaders, if you want to see this working in action.
They already have an alternat
They already have an alternative. It's called initramfs and the script explicitly supports it.
Initramfs needs to mature a bit more though (in combination with the software that is generally needed for the initramfs, such as udev, hotplug-ng, klibc, etc) before it can completely replace initrd, and once it does work, people need time to move over from initrd to initramfs.
You miss something
when linuxrc script read sysfs know what to load immediately and do not need to to test what is in machine anymore, so this make startup and autoconfiguration as soon as possible.
(next could happen that someone plug an usb, but it's another matter)
UFS support
Ever built your FreeBSD kernel without UFS or controller support? It doesn't get too far. The only reason the GENERIC kernel boots is because of all the compiled-in drivers.
initrd allows flexibility. It permits a default kernel without a bunch of compiled-in drivers. It saves time and space compared to the FreeBSD method.
If you don't like initrd, juse compile all the drivers that you need to boot.
Okay, so what's the point?
There's no significant space saving if you're loading the same _required_ modules from initrd or compiling it into the kernel, what purpose does initrd serve other than being convenient for installations? I'm not sure how you're "saving time," either.
But you're not loading the sa
But you're not loading the same modules. That's the point. For example, instead of having SCSI support compiled in 'just in case', mkinitrd will determine if you need SCSI support and add that to the initrd. Those modules wont end up there unless you need them and have your root fs on a SCSI device.
SCSI support is in no way -required-. Neither is IDE, or anything else.
Modular IDE?
Is IDE support now modular? I know that one upon a time it wasn't.
It's modular when it's not br
It's modular when it's not broken, I'm using it modular on my home machine right now.
I know when I started using S
I know when I started using Slackware GNU/Linux in 1997, I had IDE/ATA disabled in Linux. Maybe when linux was first released to the public in 1992 or 1993 or whenever, maybe then it wasn't modular.... but I don't thin Linux was even modular then, but I really wouldn't know.
Well, it's necessary because ...
1) Boot arrangements are becoming more complex. Root-on-RAID, root-on-LVM, root-on-network-filesystem and whole-disk encryption schemes, for example, require that you run some sort of user-space helper program before you mount the root filesystem.
Many Linux distributions are also expected to ship a generic, universally-bootable kernel of some sort. These are usually used during installation, and sometimes they also double as the main production kernel.
Unfortunately:
2) The number of bus types people expect to boot from is increasing. (Firewire, USB and Ethernet, for example.)
3) The number of drivers for each bus type is also increasing (the new Nvidia and Silicon Image IDE drivers, for example).
4) The code size of the kernel binaries is increasing (the 'mm' subsystem, for example, which is included in every kernel build has grown on i386 from ~300k in 2.4.18 to ~550k in 2.6.8).
(Continued ...)
(...continued) As a result
(...continued)
As a result, monolithic generic kernels have become much too big (7MB vmlinuz on i386) to fit on traditional boot media like floppies. They may also be too big to boot on <16MB systems.
One solution to this is to ship lots of specialized kernels instead of one huge generic kernel (as Debian woody did). This generally causes installation headaches because of the number of combinations of 2) and 3). Maintaing this many kernels is also difficult because:
5) The rate at which security patches are issued (between kernel releases) is also increasing.
The other solution (which comes at the expense of complicating the boot process) would be to have a slimmed-down, minimal kernel with an initrd scheme that teams up with a hardware detection system to load drivers only as needed. Most of the major distributions (Mandrake, SuSE, Red Hat and Debian) are moving towards this.
So—what may not make sense for a desktop system (where you build your own hand-rolled kernels) may not make sense for large-scale deployments where the same software has to work on myriad different hardware configurations.
Initrd is necessary
There are situations where an initrd is necessary, even when the right bits are all compiled into the kernel, e.g. when the root partition needs some extra code to be run to initialize it, like with RAID, LVM, or encrypted disks.
initrd is needed for udev
AFAIK with the ongoing transformation from devfs/static dev to udev all your base will be needing some sort of initrd to bootstrap the devices.
- Peder
initrd is *not* needed for udev
I run a udev based system without an initrd. I have a static
/dev containing /dev/null and /dev/console, which is used for the
initial boot, until udev launches (before filesystems are mounted).
who cares like initrd or
who cares like initrd or dont like it...........if u do great, if u dont then use something else