Re: [PATCH] 5 year old bug in main.c (initrd). Can this please be fixed?

From: Christopher E. Brown (cbrown@denalics.net)
Date: Thu May 25 2000 - 14:24:54 EST


On Thu, 25 May 2000, Dave Cinege wrote:

> I must argue it is an arbitrary limitation and a bug. It *precludes* you from
> using the initrd as your root and executing /linuxrc. (Something I have
> probably 100,000 machines doing) The point is there is NO REASON (but personal
> preference) to skip /linuxrc when your root is the first ramdisk.
>
> The choice to skip execution of /linuxrc should be in userland. In /linuxrc
> itself or implied by the absence of the file. Making this choice in the kernel
> disenfranchises users of a standard mechanism.
>
> Personally I'd like to see /linuxrc executed if it's present regardless of
> initrd, to allow for a standerized 'pre-init'. I'd be happy to just see this
> fixed however.
>
> Dave

        Just adding here. Personally I went to a 2 stage load for my
flash based routers. When running *much* larger images than the LRP
(8MB to 64MB) uses things got fun, as the double load (load initrd
into memory, then copy/convert to ramdisk, then clear first initrd
copy) blew up due to a lack of memory.

        The solution was a micro initrd image that does all the
creation/setup on /dev/ram1 straight from flash, then switch to
/dev/ram1 for root.

        Given the move of the latest LRP stuff twards larger images
(not a mainly floppy based system) this might me a good way to kill 2
birds. If done right the on disk footprint is approx the same as your
current loading system, but allows loading *much* larger images
within the current kernel functionality.

---
As folks might have suspected, not much survives except roaches, 
and they don't carry large enough packets fast enough...
        --About the Internet and nuclear war.

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:14 EST