Re: [RFC]: d-i, /dev, busybox
One thing that hasn't been considered is devfs. I think we may want to
think about it for the installer (which, I stress, does not mean that
the system we install has to use it -- that's not in our hands). But
we're using the 2.4 kernel anyway, and devfs makes it easy to see what
hardware the kernel detected by just looking at the dev entries, and we
don't have to worry much about adapting a large code base to devfs (as
Debian does in general).
Anyway....
Erik Andersen wrote:
> Is the goal to end up with a ramdisk that contains the installer?
> How about the following variant on A:
That's pretty elegant. Here's a varient that solves yet another problem:
> * boot with load_ramdisk=1 initrd=debian.gz root=/dev/ram0
Use root=/dev/ram1 instead.
> # fit /dev/* inodes into 96k (leaves 6k free w/1041 devices)
> dd if=/dev/zero of=/dev/ram1 bs=1k count=96
> /sbin/mkfs.minix -n30 -i 1200 /dev/ram1 96
> mount /dev/ram1 /mnt -t minix -o rw
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.
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.
> # copy what few /dev entries we have into the ramdisk
> cp -a /dev/* /mnt
> umount /dev/ram1
Instead, copy the whole root filesystem in.
>
> * Kernel mounts up /, but since we told the kernel
> at boot time that / is /dev/ram0, well and lo and
> behold, sitting on /dev/ram0 is the initrd that just ran.
> The kernel doesn't care, it mounts it up as usual.
> /dev/ram1 is is still mounted on /dev
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?)
The downside to this scheme is it requires size_of_initrd * 2 memory
during the stage where both are mounted. But that number is pretty
small, probably smaller than the full memory overhead of the
installation system once it gets all the modules downloaded.
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.
--
see shy jo
Reply to: