[Leaf-devel] Linux 2.4.16
I noticed several differences (perhaps others will find more). I had much less in my kernel, but perhaps bigger things Compared to the version the Jacques had, my compilation did NOT have: * EISA support * Hot Pluggable Device support * PCMCIA * QoS * 1000Mbit * Wireless LAN * Token Ring * ISDN * Network Filesystems ...and had less: * Block devices * Networking options * Ethernet card support However, my compilation DID have the following - which perhaps are much bigger (?): * MTD Support (DiskOnChip) * Bridge support (not a module) * IDE Support * SCSI (maybe) * Amateur Radio (AX.25 and KISS mode) * Frame buffer support * Video Selection * VFAT support * GR Security * Linux Progress Patch What's the big ones? IDE? SCSI? LPP certainly seemed to be quite big. Perhaps I'll just try to modularize most of the above (IDE, Amateur Radio, etc...) to strip it down. By the way, am I the only one who keeps dreaming of an ampr.org address? To me, wireless means something different :) -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] linux 2.4.16
Hello David Ewald and all others on the list. Jacques Nilo has a 2.4.16 (unpatched) kernel on /leaf.sf.net/devel/jnilo/kernel-2.4.16/ The configuration files are there too. We are working on a pppoe disk based on this kernel. greetings and a happy new year to all of you Eric Wolzak leaf.sf.net/devel/ericw ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Linux 2.4.16
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David > Douthitt > Sent: Sunday, December 30, 2001 11:39 PM > To: LEAF Development > Subject: Re: [Leaf-devel] Linux 2.4.16 > > < -- snip -- > > > > Second question: I STILL can't get 2.4.16 under 500k in > > size - I can't even get it under 600k - even compressed. > > Even though I strip practically everything out. Why is > > that? Do I really have to give up over 100k of floppy > > space to the Linux kernel? > I've been running 2.4.16 with the GRsec patch version 1.9 since November 28th with no problems. The size of my compressed kernel is 554911 Bytes. It is booting from an initrd with no classic LRP patches. The only thing different, probably, is that I haven't compiled in the hooks for the majority of modules and I have all of my drivers, including IDE disk access, compiled into the kernel. Andrew ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux 2.4.16
On 12/31/01 at 5:42 PM, Ewald Wasscher <[EMAIL PROTECTED]> wrote: > David Douthitt wrote: > > >Second question: I STILL can't get 2.4.16 under 500k in > >size - I can't even get it under 600k - even compressed. > >Even though I strip practically everything out. Why is > >that? Do I really have to give up over 100k of floppy > >space to the Linux kernel? > Do you care to share your kernel configuration file? I > know 2.4 is bigger, but I'm surprised it's that big. Then you may be surprised to hear that with the LPP patch saw one version over 990k...! This version resulted in a 910k file; if you assume that 240k or so is the Linux Progress Patch (LPP) what's the rest of it? -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set CONFIG_M486=y # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=4 CONFIG_X86_USE_STRING_486=y CONFIG_X86_ALIGNMENT_16=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # CONFIG_X86_UP_APIC is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set # CONFIG_HOTPLUG_PCI is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set # CONFIG_MTD_PARTITIONS is not set # CONFIG_MTD_REDBOOT_PARTS is not set # CONFIG_MTD_CHAR is not set # CONFIG_MTD_BLOCK is not set # CONFIG_MTD_BLOCK_RO is not set # CONFIG_FTL is not set CONFIG_NFTL=y CONFIG_NFTL_RW=y # # RAM/ROM/Flash chip drivers # # CONFIG_MTD_CFI is not set # CONFIG_MTD_JEDECPROBE is not set # CONFIG_MTD_GEN_PROBE is not set # CONFIG_MTD_CFI_INTELEXT is not set # CONFIG_MTD_CFI_AMDSTD is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # CONFIG_MTD_OBSOLETE_CHIPS is not set # CONFIG_MTD_AMDSTD is not set # CONFIG_MTD_SHARP is not set # CONFIG_MTD_JEDEC is not set # # Mapping drivers for chip access # # CONFIG_MTD_PHYSMAP is not set # CONFIG_MTD_PNC2000 is not set # CONFIG_MTD_SC520CDP is not set # CONFIG_MTD_NETSC520 is not set # CONFIG_MTD_SBC_GXX is not set # CONFIG_MTD_ELAN_104NC is not set # CONFIG_MTD_MIXMEM is not set # CONFIG_MTD_OCTAGON is not set # CONFIG_MTD_VMAX is not set # CONFIG_MTD_L440GX is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLKMTD is not set CONFIG_MTD_DOC1000=y CONFIG_MTD_DOC2000=y # CONFIG_MTD_DOC2001 is not set CONFIG_MTD_DOCPROBE=y # CONFIG_MTD_DOCPROBE_ADVANCED is not set CONFIG_MTD_DOCPROBE_ADDRESS=0 # CONFIG_MTD_DOCPROBE_HIGH is not set # CONFIG_MTD_DOCPROBE_55AA is not set # # NAND Flash Device Drivers # CONFIG_MTD_NAND=y # CONFIG_MTD_NAND_ECC is not set # CONFIG_MTD_NAND_VERIFY_WRITE is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is
Re: [Leaf-devel] Linux 2.4.16
David Douthitt wrote: >Second question: I STILL can't get 2.4.16 under 500k in size - I can't >even get it under 600k - even compressed. Even though I strip >practically everything out. Why is that? Do I really have to give up >over 100k of floppy space to the Linux kernel? > Do you care to share your kernel configuration file? I know 2.4 is bigger, but I'm surprised it's that big. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux 2.4.16
On 12/30/01 at 4:23 PM, David Douthitt <[EMAIL PROTECTED]> wrote: > I'm trying to set up Linux 2.4.16 with the Linux Progress > Patch (LPP) on my desktop before I try it on a floppy... > Now when the system boots, I get the nice boot screen > (from LPP) and all works until init starts - which messes > up the nice boot screen. Few lines more and the screen > clears and starts giving messages in blue. In short > order, it is obvious that the entire filesystem - ALL > mount points - are mounted read-only (!). > > Anyone know what is going on? I think I figured out what it was, though I can't say why everything was read-only. I'd forgotten to say that I'm running Mandrake 8.0, and that there was a message that it could not open the console as there was no such device It appears that, since I've enabled framebuffer support, that enabled Mandrake's cute boot-time startup to run (Aurora), and this did not expect to be running on /dev/tty2 (the console) and this caused problems. Once I took this out, the boot-time messages scrolled by on the bottom line, init still corrupted the screen, but the system booted - and aurora took over after the kernel was done booting up. > Second question: I STILL can't get 2.4.16 under 500k in > size - I can't even get it under 600k - even compressed. > Even though I strip practically everything out. Why is > that? Do I really have to give up over 100k of floppy > space to the Linux kernel? Well? :) Perhaps I'll just create a system with syslinux, configurations, Linux 2.4, and root.gz on it - and use packages from a second disk (the 2.0 unpatched devel disk...) -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Linux 2.4.16
I'm trying to set up Linux 2.4.16 with the Linux Progress Patch (LPP) on my desktop before I try it on a floppy... The system has been trouble Even though this system came with 2.4.3, it still won't boot right with 2.4.16 and LPP. First it came up and said that /dev/hda7 had no superblock on it - except that it was perfectly fine. I figured that devfs was the bug in this case So I took it out - now it works. Side note: devfs was supposed to solve problems - but I used it and it created them. Now when the system boots, I get the nice boot screen (from LPP) and all works until init starts - which messes up the nice boot screen. Few lines more and the screen clears and starts giving messages in blue. In short order, it is obvious that the entire filesystem - ALL mount points - are mounted read-only (!). Anyone know what is going on? Second question: I STILL can't get 2.4.16 under 500k in size - I can't even get it under 600k - even compressed. Even though I strip practically everything out. Why is that? Do I really have to give up over 100k of floppy space to the Linux kernel? -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux 2.4.16 and LEAF
> > > 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). > > How does this affect the steps I put forth? I don't see that it does. There ARE minor changes... > I had assumed that /linuxrc would just run; now you say that the "root" > parameter needs to point somewhere other than /dev/ram0 . That's > alright, but that doesn't change the steps does it? > > According to initrd.txt, it would appear that the usual way of doing > things is, at the end of /linuxrc, to pivot_root and then run init. That's one way...keep reading... > I was thinking one doesn't need to pivot_root at all - and the > documentation alludes to such situations. Is there a problem if > pivot_root isn't used? > > Is it right to say that pivot_root and /proc/sys/kernel/real-root-dev > are both new to Linux 2.4? No. /proc/sys/kernel/real-root-dev came straight from my 2.2.x documentation. OK, in the normal kernel 2.2.x (and I believe 2.4.x), linuxrc is a mechanism mainly intended for installing kernel modules so you can boot off that brand-new fiber-channel SAN array (or SCSI drive, or whatever) without having to build thousands of unique kernels if your making a distrubition. The kernel sort of does an implicit 'pivot root' when running a typical boot-sequence with an initial ramdisk. First, the initrd is mounted as root, and linuxrc is run. When linuxrc exits, the kernel mounts the real-root-dev, and spawns init (hopefully never to return). The linuxrc script can CHANGE the value of real-root-dev while it is running by writing into /proc. If linuxrc does not do this, the root device will remain whatever it was before (either the device hard-coded into the kernel, or whatever you passed on the kernel command line). OK, now one problem is that linuxrc doesn't always get run. If the kernel is booting with an initial ramdisk, AND the root device is the ramdisk, the kernel assumes you built a tiny recovery file-system and want to run init, NOT linuxrc, so the above processing is completely bypassed (the ramdisk is mounted as the real-root-device, and init is run...if it ever returns, it's kernel panic time). This is the reason for the existance of the linuxrc-always patch...it runs linuxrc EVEN IF the root device is the ramdisk. Again, the code in init/main.c goes a long way towards explaining exactly what's going on...compare the patched and un-patched version to see the changes the LRP patches make. IMHO, the "boot-loader" functionality should be done with /linuxrc functionality, and once enough of a root filesystem has been pieced together on some other mount-point, the boot code exits, the kernel mounts the new FS as root, and init starts running. Exactly how much is done in the "boot-loader" code, and how much is done in startup scripts once init is running is still up in the air at this point, and there are lots of tradeoffs. Regardless, the boot code in the initial ramdisk could easily be discarded or copied to the new root filesystem, depending on particular system requirements... ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux 2.4.16 and LEAF
Charles Steinkuehler wrote: > > > 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). How does this affect the steps I put forth? I don't see that it does. I had assumed that /linuxrc would just run; now you say that the "root" parameter needs to point somewhere other than /dev/ram0 . That's alright, but that doesn't change the steps does it? According to initrd.txt, it would appear that the usual way of doing things is, at the end of /linuxrc, to pivot_root and then run init. I was thinking one doesn't need to pivot_root at all - and the documentation alludes to such situations. Is there a problem if pivot_root isn't used? Is it right to say that pivot_root and /proc/sys/kernel/real-root-dev are both new to Linux 2.4? ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux 2.4.16 and LEAF
Jacques NIlo wrote: > > > You and initrd.txt both talk of pivot_root - but I > > can't find the command anywhere. > > It's in busybox. Read initrd.txt in kernel Doc for > instruction. I saw initrd.txt - and have 2.4 systems here, too. Doing a which pivot_root or a man pivot_root fails on all systems - except there is a manpage on the 2.4 system. Compiling busybox under Linux 2.2 (and glibc 2.1) generates a message that pivot_root is unsupported and has been stubbed out. > How big would be this same BBOX library dynamically > compiled against libc? The difference is the cost in term > of size. Oxygen busybox was about 170k or 190k dynamically linked - since Oxygen uses a LOT of busybox applets. Statically compiled, busybox 0.60.1 is 330k; busybox 0.60.2 came out to 300k. I statically linked with uClibc; if you statically link against glibc (like I did by mistake :) it comes out to 550k or so. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux 2.4.16 and LEAF
> > 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. > > I don't know what you mean by that... What would root= be, then? And > what does that have to do with /linuxrc? > > I'm just getting a handle on this initrd thing... Sorry...shorthand for root device equals anything EXECPT /dev/ram0, so linuxrc will run with an unpatched kernel (see main.c in kernel source for the tests the kerenl does to decide if it should run linuxrc or not). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux 2.4.16 and LEAF
> You and initrd.txt both talk of pivot_root - but I can't find the > command anywhere. It's in busybox. Read initrd.txt in kernel Doc for instruction. > 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. How big would be this same BBOX library dynamically compiled against libc? The difference is the cost in term of size. > 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? As of today initrd fs can **only** be ext2 or minix. If it could be tmpfs it would solve a lot of pbs... > > 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. I agree > I thought POSIXness used sed extensively; does busybox sed give all you > need? I am not sure. That is something to check. > > 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. I am not sure it's that difficult. May be worth just trying. 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
Re: [Leaf-devel] Linux 2.4.16 and LEAF
Charles Steinkuehler wrote: > 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. I don't know what you mean by that... What would root= be, then? And what does that have to do with /linuxrc? I'm just getting a handle on this initrd thing... > 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). I saw that... > 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). Oxygen root.lrp is already there; what you all call "root.lrp" for me is: sed.lrp, init.lrp, inetd.lrp, timezone.lrp, cron.lrp, et al. There's even e3.lrp, sysklog.lrp, ps.lrp, and more - 29 packages total on the root disk. So why not make root.lrp into initrd.gz? Looking at Oxygen root.lrp, all that is there is really: busybox, a few scripts, a dozen modules or more, boot time scripts, and the root package files in /var/lib/lrpkg. That's it. Busybox is 330k, and the modules all together might make up another 100k or 200k. Everything else is tiny. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux 2.4.16 and LEAF
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
Re: [Leaf-devel] Linux 2.4.16 and LEAF
> 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/ini
Re: [Leaf-devel] Linux 2.4.16 and LEAF
> 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). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Linux 2.4.16 and LEAF
I was going through past mailing list messages (I have 1301 on hand :) and was trying to find out what had been going on with patching 2.4 for LEAF. I remembered that the LRP patches were made obsolete, both by massive changes to the kernel initrd code and by the future removal of initrd, as well as by the combined patch that Charles and Dave C. have available. Then there is Jacques' work in making the LEAF patches obsolete permanently. If I read his docs right, this is *MUCH* simpler than I thought. Remember that the Oxygen root.lrp is basically stripped as far as I can get it already - for example, it doesn't have inetd, cron, sed, libc, and other things... I don't think it even has init... 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 5. Modify syslinux.cfg with new kernel parameters: initrd=initrd.gz init=/linuxrc Is this right? Then to update the initrd.gz could be like thus: 1. Create root.lrp 2. Create secondary Minix filesystem 3. Unarchive root.lrp in new filesystem 4. Compress new filesystem with gzip 5. Put initrd.gz on disk 6. Unmount and destroy ramdisk used to create image ...this requires a lot of memory (to create another file system). It has the benefit of not requiring changes to the package managers, since they will create root.lrp just like always. Anyway, updating root.lrp really should only be done by us developers anyway - since packages would be the way to go otherwise. Being able to use no patches would remove the dependence on patches that don't exist, allow upgrading 2.4 based systems to 2.4.16 - most I've seen are 2.4.5! - and would allow LEAF to work when initrd is removed entirely... Sounds better and better all the time. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
