On Tue, Feb 16, 2010 at 21:01, Neil Brown <neilb@suse.de> wrote:> On Tue, 16 Feb 2010 16:03:43 -0900 (AKST) "Mr. James W. Laferriere" <babydr@baby-dragons.com> wrote:>> I am unaware of any record from Neil or other maintainer(s) of the>> /md/ device tree saying that they will not remove the 0.90 table and the>> autoassembly functions there . I'd very much like to hear a statement saying>> there will not be a removal of the autoassembly functions for 0.90 raid table>> from the kernel tree .>> I will not be removing 0.90 or auto-assemble from the kernel in the> foreseeable future.> None the less, I recommend weaning yourself from your dependence on it.> initramfs is the future, embrace it.

What are people's reasons for pushback against initramfs? I've heardlots of claims that "it's not trustworthy" and "it breaks", but in 7years of running bootable software RAID boxes on weird architectures(even running Debian unstable) I have only once or twice had initramfsproblems.

As a software capability, initramfs makes it possible to use*anything* as a root filesystem, no matter what is necessary to set itup. For example, I have seen somebody use DRBD (essentially networkRAID-1) as a root filesystem with a few custom hook scripts added tothe initramfs-tools configs. Other examples include using Sun ZFS asa root fs via an initramfs FUSE daemon, a feat which even Solariscould not accomplish at the time. Encrypted root filesystems alsorequire an initramfs to prompt for encryption keys and decrypt theblock device. Multipath block devices are another example.

You should also take a look at your distro installers. There is not asingle one made in the last several years which does not use aninitramfs to start networking or access the installation media. Infact, of all the distro installers I have had the most consistentbehavior regardless of system hardware from the ones which operateentirely out of their initramfs.

From a reliability perspective, an initramfs is no more essentialthan, say, /sbin/init or /boot/vmlinuz-2.6.33. Furthermore, all ofthe modern initramfs generation tools automatically keep backup copiesexactly the same way that "make install" keeps backup copies of yourkernel images. The two times I've managed to hose my initramfs I wasable to simply edit my grub config to use a file called something like"/boot/initramfs-2.6.33.bak" instead.

In fact, I have had several times where an initramfs made my bootprocess *more* reliable. On one of my LVM JBOD systems, I was able topull a group of 3 SATA drives whose backplane had failed and drop themall in USB enclosures to get the system back up and running in a halfan hour. With just straight partitions on the volumes I would havebeen hunting around for 2 hours to figure out where all my partitionshad gone only to have the USB drives spin up in a different orderduring the next reboot.

If you're really concerned about boot-process reliability, go aheadand tell your initramfs tool to include a fully-featured busybox,coreutils, bash, strace, gdb, and a half-dozen other developer tools.You may wait an extra 20 seconds for your bootloader to load the damnthing during boot, but you'll be able to track down that annoying10-second hang in your /sbin/init program during config-file parsing.

I've built specialized embedded computers with stripped-down chipsetinitialization code, a tiny Linux kernel and a special-purposeinitramfs burned into the flash. By using the fastboot patches anddisabling all the excess drivers, my kernel was fully operationalwithin the first half-second. It used the tools on the initramfs topoke around on the hard disk as a bootloader, then kexec() to load theoperational kernel.

Counting up all the problems I've had with system boot... I've had anorder of magnitude more problems from somebody getting careless with"rm", "dpkg --purge", etc than with initramfs deficiencies.