"Christopher E. Brown" wrote:
>
> Just adding here. Personally I went to a 2 stage load for my
> flash based routers. When running *much* larger images than the LRP
> (8MB to 64MB) uses things got fun, as the double load (load initrd
> into memory, then copy/convert to ramdisk, then clear first initrd
> copy) blew up due to a lack of memory.
FYI this is fixed in the current incarnation if initrd-archive.
The untar and gunzip is performed through a buffer straight to the fs on
/dev/ram0, instead of the old way of untar -> /dev/ram1, gunzip ->/dev/ram0.
I'm also going to add the ability to spec the autofs size, so it does not have
to take over the entire size of the ramdisk. (IE ramdisk_size=16384
initrd_archive=minix,4096)
If I can get ramfs working (see other thread) it will require even less initial
memory at boot.
> The solution was a micro initrd image that does all the
> creation/setup on /dev/ram1 straight from flash, then switch to
> /dev/ram1 for root.
Considered it a long time ago, Used to even do soemthign like it. Just too god
damn ugly.
> Given the move of the latest LRP stuff twards larger images
> (not a mainly floppy based system) this might me a good way to kill 2
> birds. If done right the on disk footprint is approx the same as your
> current loading system, but allows loading *much* larger images
> within the current kernel functionality.
This still does not fix the first problem of not being able to get at /linuxrc
-
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 : Wed May 31 2000 - 21:00:14 EST