On Wed, Dec 17, 2008 at 20:48, Jeremy Katz
> On Wed, 2008-12-17 at 14:31 -0500, Neil Horman wrote:
>> Not that I don't think a unifying tool to create an initramfs is a bad
>> (quite the contrary, I think it would be great), but I'd like to point
>> one of your underlying premises is a bit shaky. That an initramfs has
>> purpose, that being to get the rootfs mounted, isn't entirely accurate.
>> and various embedded systems being the prime examples here. Many
>> systems run entirely out of the initramfs, and contain all the code they
>> do so in them. Additionally, kdump in most environments, attemps to
>> core files entirely from the initramfs as well, operating under the
>> that the rootfs may not be functioning properly after a crash. By and
>> these initramfs images tend to be larger and offer a more typical (if
>> standard) user operating environment.
> While I'd like to think that embedded systems are not going to do
> something custom, you, I and everyone else know that's unlikely. ;-)
> The kdump case is one that I think is at least reasonable to get to
> eventually (and also, installer initramfsen), but I think that getting
> the cases of "initramfs for booting a system" consolidated first makes
> the most sense.
Maybe Bernhard Walle, who currently maintains the SUSE initramfs, can
possibly take care of that. He's is working on kdump stuff.
>> I'm looking at your tree now, and it
>> looks like a good start on standardizing the initramfs for the nominal
>> you have plans to include (or are you interested in including) support
>> alternate infrastructure (like busybox instead of nash), interactive
> Well, the use of nash right now is due to the fact that there isn't
> historically any switchroot utility shipped in util-linux. Hopefully
> we'll get something there and then the only user of nash that's there
> right now can go away.
SUSE uses a small binary run-init copied from klibc:
Maybe it's time to add something like that to util-linux? Karel?
> busybox, etc are really all just extra pain as compared to using real
> system utilities... once you accept that you're dynamically linked,
> you're better off just maintaining one set of the utilities as opposed
> to having one set in coreutils and one set in busybox.
Busybox is nice as an option to be able to rescue/hack. It should
definitely be provided as an optional "plugin" for people who need it.
But there is no chance to depend on it by default, for the very same
reason klibc, or any other libc is not an option.
Full-featured distros who make their money with support, can just not
afford to support tools compiled differently from the tools in the
real rootfs. SUSE used klibc for one release, and stopped doing that
immediately, because you go crazy if you run into problems with bootup
problems on cutomer setups you can not reproduce with the tools from
the real rootfs.
We need to use tools in initramfs which will not work realibly, or not
at all, with other libcs. We will have one dynamic glibc there anyway,
so there is no valid reason to also use any single statically linked
binary, or any other libc by default. Really, it's just nice to use
the same environment in the real root and in initramfs, and you also
get the smallest possible size that way, if you need to include only a
single "advanced" tool.
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html