On Thu, 25 May 2000, Dave Cinege wrote:
> 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.
No more ugly then never exiting linuxrc.
> > 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
It does, system loads a < 1M initrd image and runs /linuxrc,
first thing linuxrc does is create the rootfs on /dev/ram1 (eithor by
catting a raw image through bzip and into the device, or via
mkfs/etc. I have done it both ways).
In most cases I pipe a raw image though bzip2 -d and into
/dev/ram1. Then mount /dev/ram1. This gives me a more complete
toolset, and linuxrc then loads the extended stuff onto the rootfs,
starting with the dynamic stuff (configs), and/or addin packages
beyond the base image. linuxrc then syncs and umounts /dev/ram1,
fscks it, and exits. The rootswap to /dev/ram1 then happens, and
/dev/ram0\/dev/initrd is freed.
My initrd image ammounts to linuxrc, bash, bzip2, cat, mount,
and a small /dev. All the other tools are part of the base image
linuxrc loads into ram1.
---
As folks might have suspected, not much survives except roaches,
and they don't carry large enough packets fast enough...
--About the Internet and nuclear war.
-
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