Subject: Re: [vserver] ramFS Host
From: "Michael S. Zick" <mszick@morethan.org>
Date: Sun, 6 Jan 2008 07:48:29 -0600

On Sat January 5 2008 18:36, Ed W wrote:
> 
> > I do something very similar in my alpine linux distro. Instead of just
> > continuing in initramfs, the init script mounts a tmpfs, finds a base
> > installation (2-3MB) and "switch_root" to the tmpfs. From here it loads
> > a set of packages (from usb/cdrom/cf) and configuration (from
> > usb/floppy/cf).
> >
> > >From this base installation it is possible to mount disks, raid, iscsi,
> > lvm and fire up vserver guests.
> >   
> 
> 
> Hi Natanael
> 
> I have followed your posts in gentoo-embedded mailing list.  I have only 
> examined alpine-linux a little, but I'm not quite sure why you use the 
> tmpfs rather than say keeping with the initramfs and perhaps using aufs 
> to overwrite with additional packages, and perhaps even adding a 
> writeable /etc directory?  (Actually on the wrt linksys distros they 
> often add a writable partition with symlinks into /etc, or vice-versa)
> 
> Having only an initramfs seems like a very sensible solution for 
> Michael?  He could use a second partition for writable stuff and mount 
> it rw - then simply symlink in anything required from the static 
> partition to give a kind of updatable /etc/ (or whatever)
> 
> I'm researching something similar myself, but in my case I want quite a 
> lot of stuff in the base distro (30-60MB perhaps) and so your tmpfs 
> approach seems like quite a waste when I only have 128 or 256MB or ram 
> on the devices I want to use...?
>

The system I am targeting is unusual for an embedded system in the amount
of ram.  Stock is 0.5Gb user expandable to 2.0Gb. 

There is a lot of information on the web about people trying to trim down
a desktop or full-sized laptop distro for this machine.
I am trying the other approach - start with what I would use for an embedded
system - let natural growth and feature creep claim the additional resources.

I am including auFS in the build. auFS includes patches for L-Vs.  
Also squashfs+lzma compression probably for /lib/modules/<version>/ 
maybe for other parts of the tree.  Haven't checked that yet for L-Vs support.

The builds I am making are using initial ramFS (which is r/w) not initrd
(which is r/o) - so finding a place for writable areas is not a concern.

Mike

> Anyone else got any other thoughts on this?
> 
> Cheers
> 
> Ed W
> 
>