Re: [RFC]: d-i, /dev, busybox
On Tue Feb 13, 2001 at 10:32:41AM -0800, Joey Hess wrote:
>
> Instead, allocate enough space for the whole initrd filesystem, plus
> some more space for /dev (if devfs is not used), and some more space for
> modules we will retreive and install later.
Keep in mind then you will need to up the default size of a ramdisk if it
is going to exceed 4Meg.
> I wonder if a ramfs filesystem could be used here? That would be truely
> ideal, since we could just mount it and not have to worry about how much
> space to allocate. ramfs filesystems go away when unmounted though, so
> I'm not sure how we could pivot root into it.
No problem using ramfs. When an initrd exits, the kernel does a pivot_root to
whatever device is specified in /proc/sys/kernel/real-root-dev. I am a bit
embarrased to admit it, but I once built a special purpose embedded CD where it
booted up, scanned a long list of devices, tried to mount them, and then looked
for a magic file I had placed on the CD (you can't know apriori where you
booted from). If/when the file was found, I mounted it via loopback, echoed
the major<<8+minor into /proc/sys/kernel/real-root-dev and then then kernel
ended up with a read-only root-fs that was loopback mounted from the cdrom.
You can do all sorts of goofy things this way.
Also, FYI, iI got a patch to implement pivot_root in busybox which I will
be applying today...
>
> In my varient, it mounts ram1 (or does some ramfs pivot_root(2) magick),
> which is a fully usable ramdisk with dev entries and extra free space.
> It seems the initrd memory can then be freed up using
> "blockdev --flushbufs /dev/ram0" (does busybox have an equivilant
> program?)
freeramdisk
> Another advantage of this varient is that it lets initrd.gz be a cramfs,
> since we no longer need to be able to write to it.
You never have to write to root so cramfs is _always_ feasable. I use a scheme
similar to what I outlined earlier to run on read-only rootfs systems all the
time. You need a writable /dev and /tmp (with the /var/<foo> directories being
symlinks to /tmp), which is easily done by making ramdisks (or similar) and
mounting then on top of the underlying ro fs.
-Erik
--
Erik B. Andersen email: andersee@debian.org, andersen@lineo.com
--This message was written using 73% post-consumer electrons--
Reply to: