[lkml]   [2008]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Dracut -- Cross distribution initramfs infrastructure
2008/12/17 Neil Horman <>:
> On Wed, Dec 17, 2008 at 01:54:54PM -0500, Jeremy Katz wrote:


>> Therefore I've started on a new project, dracut, to try to be a new
>> initramfs tool that can be used across various distributions. From the
>> README...
>> Unlike existing initramfs's, this is an attempt at having as little as
>> possible hard-coded into the initramfs as possible. The initramfs has
>> (basically) one purpose in life -- getting the rootfs mounted so that we
>> can transition to the real rootfs.


> Not that I don't think a unifying tool to create an initramfs is a bad idea
> (quite the contrary, I think it would be great), but I'd like to point out that
> one of your underlying premises is a bit shaky. That an initramfs has one
> purpose, that being to get the rootfs mounted, isn't entirely accurate. Kdump
> and various embedded systems being the prime examples here. Many embedded
> systems run entirely out of the initramfs, and contain all the code they need to
> do so in them. Additionally, kdump in most environments, attemps to capture
> core files entirely from the initramfs as well, operating under the assumption
> that the rootfs may not be functioning properly after a crash. By and large
> these initramfs images tend to be larger and offer a more typical (if not
> standard) user operating environment. I'm looking at your tree now, and it
> looks like a good start on standardizing the initramfs for the nominal case. Do
> you have plans to include (or are you interested in including) support for
> alternate infrastructure (like busybox instead of nash), interactive setup, etc?

Seconded: as a user of (various) distributions, I've come across
the following
problem: sometimes the initramfs, for whatever reason, does not manage to
find or mount the rootfs. In those cases I hate the developpers of
the distribution
because there is basically nothing that can be done in the initramfs
to see, test,
try, mount, modprobe, umount, ping, telnet, etc... Please, please, throw in a
full-featured busybox. Here is a good compromise I use:

Currently defined functions:
[, [[, arp, arping, ash, awk, basename, brctl, bunzip2, bzcat,
bzip2, cat, chgrp, chmod, chown, chroot, chvt, clear, cmp, comm,
cp, cpio, cut, date, dc, dd, deallocvt, depmod, df, diff, dirname,
dmesg, dos2unix, dpkg, dpkg-deb, du, dumpkmap, echo, egrep, eject,
env, expr, false, fbset, fdflush, fdformat, fdisk, fgrep, find,
findfs, ftpget, ftpput, grep, gunzip, gzip, halt, head, hexdump,
hostname, hwclock, ifconfig, ifenslave, insmod, ip, ipcalc, kbd_mode,
kill, killall, killall5, less, linux32, linux64, ln, loadfont,
loadkmap, losetup, ls, lsmod, md5sum, microcom, mkdir, mkfifo,
mknod, mkswap, mktemp, more, mount, mv, nice, od, openvt, patch,
pgrep, pidof, ping, ping6, pivot_root, pkill, poweroff, printf,
ps, pwd, readlink, reboot, reset, rm, rmdir, rmmod, route, rpm2cpio,
rtcwake, sed, setarch, setkeycodes, sh, sha1sum, sleep, sort,
stat, strings, stty, su, swapoff, swapon, switch_root, sync, tac,
tail, tar, tee, telnet, test, touch, tr, traceroute, true, tty,
udhcpc, umount, uname, uniq, unix2dos, unzip, vi, wc, wget, which,
xargs, yes, zcat

(linux32 and linux64 are probably not useful for general initramfs). With that
configuration, busybox (v1.13.0.svn, x86-32 executable) is 416224 bytes long
(dynamically linked with libc as only library needed).

Loïc Grenié
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2008-12-18 10:31    [W:0.098 / U:0.156 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site