On Sat, 8 Jan 2000, Erik Andersen wrote:
> On Sat Jan 08, 2000 at 06:11:39PM +0000, Alan Cox wrote:
> > > isn't one), but do have the ability to load and execute a block of code
> > > (the kernel) from the network. This patch allows the kernel, once it's
> >
> > Then they can support an initrd. You can have the initrd compiled into or
> > appended to the kernel image.
> >
>
> This makes it terribly difficut for (embedded) distributions. Right now
> for powerpc, for example, I have to compile up and piece together the
> initrd, then compile the initrd into the kernel. This works fine for my
> embedded dist. installer, but then as part of the install process we
> need to adjust the _installed_ initrd (since there is no disk on the
> boxes in question) to handle things like IP addresses and passwords and
> such. To get this newly adjusted initrd to boot means I have to search
> for the initrd's gzip magic in the kernel, and then binary edit the
> kernel, and have the kernel whine on boot about trailing garbage in the
> initrd. This is very messy.
>
> I really, really, would like to avoid having the initrd compiled into
> the kernel. De-coupled is good, and IMHO the initrd-tftp patch is a good
> thing. Embedded folks like this patch!
I really liked the patch at the first glance, too. But Alan is correct,
you can just append a very small initrd to the kernel which does
dhcp (or bootp) and then loads the real rootfs ramdisk via tftp into
ram1 - entirely in userspace. Yes, someone needs to do this very small
neat first-stage initrd, but it seems at least possible to me.
Richard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:14 EST