Jacques NIlo wrote: > My proposal - and what I have implemented in my last > experimental LEAF 2.4.16 image (the b1 version)- is the > following: > > a/ Whatever is provided after the initrd= variable will > contain the smallest possible filesystem. The smallest I > found consists of a 1,2M (uncompressed... ) minix FS > populated with busybox, sed, ash, libc.so.6, linux-ld > a /dev/console and linuxrc. > This compressed fs is loaded in /dev/ram0 then is moved > to tmpfs on which every other packages are loaded after a > pivot_root instruction.
You and initrd.txt both talk of pivot_root - but I can't find the command anywhere. > Once the boot process is > completed (end of linuxrc), the initrd fs is unmounted > and /dev/ram0 released. > > b/ This file (called initrd.lrp in my latest version) can > be backuped like any other package. This can be done by a > 15 lines shell script (lrcfg.back.initrd) called by > lrcfg.back.script. > > c/ There are basically 3 options which could be followed: > > c1 - We apply that technique to the root.lrp file itself > as it is now in Dachstein. The problem with this is that > it is a bit memory expensive: at the end of linuxrc you > have all your dachstein distro uncompressed in tmpfs plus > root.lrp uncompressed in /initrd. Only at the end of > linuxrc (in fact in the first lines of /etc/init.d/rcS > which is executed nest) are /initrd unmounted > and /dev/ram0 released. > > c2 - We apply a "split technique". This is the route I > followed. Original root.lrp is splitted in two pieces: > the bootstrap part (initrd.lrp) and what is left in > root.lrp. > > c3 - We look for the smallest possible initrd.lrp. That > would imply the following route: initrd.lrp would only > consist of a statically build version of busybox (against > uClibc) containing only the applets necessary > for /linuxrc to be executed (ash, sed, mkdir, ...). No > more libc in this scheme and the non necessary applets of > busybox would be provided in root.lrp dynamically linked > to libc.so. This is basically the route followed by > Oxygen. I have not tested that but I think that what will > be gained in memory will be lost in the combined size of > root.lrp and initrd.lrp since you will have both > statically build applets and libc.so. Actually, Oxygen does NOT do this, as busybox is entirely statically linked, and includes all applets as before. Many of the "necessities" of running a Linux system were split out until root.lrp became as small as I could make it - it's under 350k now. The only thing you mentioned that makes me think using the initrd volume for normal work would be bad is that mention of tmpfs. Will newer kernels use tmpfs instead of minixfs - or do they use whatever you want? How will that work? Anyway, in the case of Oxygen, you do not have statically linked applications duplicated by dynamically linked ones. glibc is a separate library and is not part of root.lrp (it is libc.lrp). busybox is just like it was always, only now it is statically linked. > That is why I think that the approach I suggested is a > good compromise. For Dachstein, it probably is - though I tend to think that moving towards a minimalist root.lrp is a good idea. Moving towards a minimalist root.lrp isn't that much different than moving towards a tiny boot loader. Once your root.lrp is as small as you can get it - why not flip it over and make it a initrd.gz image? > I think this approach can be refined > further in testing the following ideas: > c2a/ Use busybox ash and sed in initrd.lrp I thought POSIXness used sed extensively; does busybox sed give all you need? > c2b/ Split busybox in two pieces (but ***both*** > dynamically linked) between initrd.lrp and root.lrp This means you need libc.so during boot (500k+) and also means that "busybox --install" will conflict. You also need to track to binaries, maintain two versions (such as when you upgrade busybox) and takes away a lot of nice otherwise "extra" commands that might be nice during boot. One day, I took stock of what Oxygen does during the boot process - before init is even loaded. It's pretty amazing... and a little scary :) busybox makes it possible... _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
