[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dbootstrap now working, busybox needs serial con change.

On Fri Nov 12, 1999 at 04:21:47PM +0100, Eric Delaunay wrote:
> Adam Di Carlo wrote:
> > Erik Andersen <andersen@xmission.com> writes:
> > > Hmm. I've been thinking about writing a micro syslogd for busybox, and I
> > > could have busybox just log this crap to to the syslog. Then those that
> > > want to see logging stuff could add something like this to /etc/init.d/rcS:
> > > 
> > >     # Setup a 256k ramdisk on /dev/ram2 and mount it over /var
> > >     # so syslogd can log stuff...
> > >     #
> > >     echo -n "Building ramdisks: "
> > >     dd if=/dev/zero of=/dev/ram2 bs=1k count=256 > /dev/null 2>&1
> > >     /bin/mkfs.ext2 -n30 /dev/ram2 256 > /dev/null 2>&1
> > >     mount /dev/ram2 /var -t ext2 -o rw
> > >     mkdir /var/log
> > >     echo "done."
> > 
> > Yuck yuck yuck.  Isn't there a better (simpler) way?
> I like this solution especially for nfsroot because the filesystem could then
> be mounted read-only instead of rw with root access.  It will be more secure.
> We could then write all temporary data to /var/tmp for instance.
> I don't think it is needed for initrd because the ramdisk is already writable.
> Just keep enough space to store the log (256k could be too much, maybe 100k ?).

Ok, we have one for and one against (if I am considered neutral).
If we can get a consensus, I will implement whatever folks decide

I'm about to blow away my neutrality, but I like the usyslogd
plus ram disk approach.  We just mount the ram disk on /tmp, and 
make /var/{log,run,lib,whatever} symlinks to /tmp.  Then we just
decide on some arbitrary upper bound for tmp data (100k, 256k, 
whatever) and that will be the size of the ramdisk.

How many tmp files are used during install?  What are reasonable
upper bounds on their sizes?


Erik B. Andersen   Web:    http://www.xmission.com/~andersen/ 
                   email:  andersee@debian.org
--This message was written using 73% post-consumer electrons--

Reply to: