[ previous ] [ next ] [ threads ]
 From:  "Frans King" <frans dot king at f333 dot net>
 To:  <maximkh at yahoo dot com>, <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] php script to edit the base files
 Date:  Sun, 6 Mar 2005 02:29:51 -0000
> -----Original Message-----
> From: Max Khitrov [mailto:maximkh at yahoo dot com]
> Sent: 06 March 2005 02:17
> To: m0n0wall at lists dot m0n0 dot ch
> Subject: RE: [m0n0wall] php script to edit the base files
> --- Frans King <frans dot king at f333 dot net> wrote:
> > The image contains a partition /dev/sdXa (where X is a number - at
> > least on
> > my system). /dev/sdXa gets mounted to /cf and this is where the
> > config file
> > is written to. On boot a disk image called mfsroot.gz is extracted to
> > memory
> > from /dev/sdXa and forms the root file system.
> >
> > That's why you see partitions but nonetheless, the root file system
> > is not
> > persisted following a reboot.
> So you're saying that the only way to edit the base files is to extract
> a second copy of all the files into the memory, edit some of them, then
> put them back into the gz file and overwrite the old one? Can someone
> explain the rationale behind this much complexity? I don't mean that in
> a bad way, it just seems that so much work went into figuring this out
> and I'm not seeing any advantage to it as opposed to just storing all
> the files on the hard drive or whatever you use and simply copying them
> to a ram drive one start up... Space?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch

The only way to go it is to get a copy of FreeBSD, uncompress the image
file, mount it (using a virtual device node), grab the mfsroot.gz file.
Uncompress that, mount it (using a virtual device node) and then edit the
files. Then unmount, compress, put back into the main image, unmount that,
compress the image and upgrade m0n0wall with this image. Complicated huh?

(See the m0n0wall hacking guide for the specifics)

I think this is just the way FreeBSD handles RAM disks. Linux works in much
the same way with its initrd images. Plus a compressed disk image is going
to be much smaller in size than a load of individual files and remember that
m0n0wall was designed for low power "embedded" systems.