Hello, I would like to know if initrd is here to stay, now that klibc and initramfs are ready. As the multipath-tools maintainer, I'm facing the choice to 1) put the multipath configuration tool in the initrd * dynamic binary is possible * storage hba drivers as modules loaded * no klibc limitations (no mntent for libsysfs ...) 2) put the multipath configuration tool in the initramfs * small static binary * storage drivers must be compiled static ? * udev available ? Putting it this way, it seems the initrd is the right place for stuff like lvm2, multipath, mdadm ... but I'd like to be sure before dropping the provisional klibc support in the tools. Please comment. Regards, cvaroqui
christophe varoqui wrote:> Hello, > > I would like to know if initrd is here to stay, now that klibc and > initramfs are ready.Initrd has the following advantage for distros: you can replace it without kernel recompilation.> As the multipath-tools maintainer, I'm facing the choice to > > 1) put the multipath configuration tool in the initrd > * dynamic binary is possible > * storage hba drivers as modules loaded > * no klibc limitations (no mntent for libsysfs ...)You are free to make uclibc-based initramfs, with all these features.> 2) put the multipath configuration tool in the initramfs > * small static binary > * storage drivers must be compiled static ?No> * udev available ?It is also available in initrd.> Putting it this way, it seems the initrd is the right place for stuff > like lvm2, multipath, mdadm ... but I'd like to be sure before dropping > the provisional klibc support in the tools.It's just a matter of convenience for distro-makers. -- Alexander E. Patrakov
christophe varoqui wrote:> Hello, > > I would like to know if initrd is here to stay, now that klibc and > initramfs are ready. > > As the multipath-tools maintainer, I'm facing the choice to > > 1) put the multipath configuration tool in the initrd > * dynamic binary is possible > * storage hba drivers as modules loaded > * no klibc limitations (no mntent for libsysfs ...) > 2) put the multipath configuration tool in the initramfs > * small static binary > * storage drivers must be compiled static ? > * udev available ? > > Putting it this way, it seems the initrd is the right place for stuff > like lvm2, multipath, mdadm ... but I'd like to be sure before dropping > the provisional klibc support in the tools. >A few of the choices you have up there are bogus, since they have nothing to do with initrd vs initramfs; you can use klibc with initrd and you can use glibc, uclibc or newlib with initramfs. Supporting klibc would be a good idea regardless. initrd won't be obsoleted immediately; not for several kernel generations (at least using pivot_root, the "poke a device number into proc and exit linuxrc" crap might go away sooner.) initramfs is clearly the way forward, though, in large part because it supports merging of binaries carried with the kernel and user-provided stuff, which means we can (finally) move stuff that is currently kernel functionality into the initramfs. -hpa
On Tue, Sep 14, christophe varoqui wrote:> Putting it this way, it seems the initrd is the right place for stuff > like lvm2, multipath, mdadm ... but I'd like to be sure before dropping > the provisional klibc support in the tools.I would like to see a way to construct a general purpose initramfs image that fits everyones need. It should also be part of the normal kernel build process. Whats really missing right now: * UUID and LABEL detection in klibc mount, libblkid and libuuid from e2fsprogs should be part of klibc mount * all the root on raid, lvm, evms should be sorted out. you are the one who can implement it. * fsck for jfs, its probably the only root filesystem that requires manual fsck All this requires glibc right now in our initramfs image. Once we have klibc support for all the common root filesystem stuff, it can be part of kbuild in one or another way. The whole topic will give a larger thread than reiserfs, bk and cdrecord together. So I will better shut up now and implement it, one day... -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG
On Wed, Sep 15, Dave Dodge wrote:> On Wed, Sep 15, 2004 at 10:25:31PM +0200, Olaf Hering wrote: > > root on nfs > > root on iscsi > > There are probably some other networked options. For example root > on nbd has been tried here: > > http://borderworlds.dk/projects/#nr > > How about copying root into a ramdisk from an ftp/tftp/http server? > Someone in a thin-client environment might try something like that.Then you need a wget/curl like tool to grab it. That looks like a custom solution.> Also: root on encrypted loop. There are several basic encryption > options, including (I think) whose module you use. There are lots of > ways the key might be acquired: interactively from keyboard, floppy, > USB storage, smart card, and so on.None of this is currently supported by our mkinitrd/mkinitramfs. But sure, all that can be added to such a project. -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG
On Wed, Sep 15, 2004 at 08:04:52AM +0600, Alexander E. Patrakov wrote:> Initrd has the following advantage for distros: you can replace it > without kernel recompilation.Is this still unique to initrd? I thought somewhere along the way the kernel acquired the ability to load an external initramfs. The populate_rootfs code in 2.6.8.1 seems to imply that it can recognize and unpack an initramfs if you pass it in through the initrd area. -Dave Dodge
Dave Dodge wrote:> On Wed, Sep 15, 2004 at 08:04:52AM +0600, Alexander E. Patrakov wrote: > >>Initrd has the following advantage for distros: you can replace it >>without kernel recompilation. > > > Is this still unique to initrd? I thought somewhere along the way the > kernel acquired the ability to load an external initramfs. The > populate_rootfs code in 2.6.8.1 seems to imply that it can recognize and > unpack an initramfs if you pass it in through the initrd area. >Yes, newer 2.6 kernels can load an initramfs using the initrd mechanism just fine. They look for /init (why not /sbin/init or /linuxrc is antoher issue...) and invoke it if present. -hpa