> If I understand right, the steps are: > > > > 1. Create and compile a kernel of your choice. > > 2. Create a Minix file system and populate it with the contents of > > root.lrp > > 3. Compress the Minix filesystem with gzip and put on disk as initrd.gz > > 4. Modify linuxrc to run /sbin/init at the end > > I don't think this is the best way to solve this. IMHO, it's better to have > the kernel boot with root=[!ram0], which will get linuxrc running. Linuxrc > should then set the real root device to /dev/ram (or your tmpfs or ramfs > device) by writing to /proc/sys/kernel/real-root-dev (see initrd.txt in the > kernel Documentation directory). > > Everything else looks OK. I'd only point out that if the initial ramdisk > becomes more of a bootloader, which is what I'd like to see, and I think > the direction Jaques is heading, root.lrp is just another package (although > likely the first to get loaded), and the initial ramdisk would be something > like boot.img, and should not have to change unless you need to change boot > methods (ie add new hardware support for a HDD, CD, or similar). > Hello everyone. Let's try to summarize what I have been trying to do so far:
1/ Why a 2.4.14 kernel ? Pros: Keep-up with the current kernel development tree. Netfilter New and latest drivers Access to the latest FS (TMPS and journaling facilities) Possibility to have access to a virtual development environment (see previous post) Cons: Size (for a floppy-based version which I think we all want to keep) Maturity/Stability The balance in my opinion is clearly in favor of the pros. 2/ Consequence To include the latest 2.4 kernels was implying to get rid of the "historical" LRP patches (or to rewrite them which was clearly too much of a work for me). As mentionned in earlier posts they do not pass the changes in initrd that where introduced in 2.4.10. I also think (personal opinion) that the more we stick to an original, unpatched kernel, the better and whatever can be done in userland should be done in userland. Also note that this lead to a reduction of 3K of the compressed kernel size :-) 3/ Strategy followed The idea was to keep the general LRP package architecture with a dynamic creation of the filesystem and the general backup facility for every package. 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. 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 statiscally build applets and libc.so. That is why I think that the approach I suggested is a good compromise. I think this approach can be refined further in testing the following ideas: c2a/ Use busybox ash and sed in initrd.lrp c2b/ Split busybox in two pieces (but ***both*** dynamically linked) between initrd.lrp and root.rlp I was myself surprised by the fact that these ideas where not difficult to implement at all in dachstein. It basically implies: 1/ Modification of /var/lib/lrpkg/root.linuxrc (i.e. /linurxrc) 2/ Modification of /usr/sbin/lrcfg.back.script 3/ creation of a small /usr/sbin/lrcfg.back.initrd script 4/ Two lines added in /etc/init.d/rcS And that basically it. And the combined size of the new root.lrp and initrd.lrp is quite similar to the original root.lrp size. OK I think that's all for this topic The other issue adressed by my last proposal was to rely on shorewall for the firewall and to simplify /etc/init.d/network and related files. But that's another story... Jacques -------------- Profitez de l'offre spéciale Tiscali Liberty Surf ! 50% de temps en plus pendant 3 mois sur tous les forfaits Internet. http://register.libertysurf.fr/subscribe_fr/signup.php3 _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
