>You might be able to reduce the iso size some by making a tarball of /var
>(using tar -y or tar -z) instead of keeping /var2 as a tree.
>Granted you would then need to have tar(1) in the iso, which may cancel out
>much of the savings if you would not otherwise have needed it.
Actually, /var is
Peter Steele wrote:
> In my read-only CD-ROM boot case, /var is created as a MFS device
> automatically and populated, but a basic directory layout only is
> used. Nothing from the CD-ROM /var is copied into the MFS /var
> that is created.
>
> I cannot figure out how BSD can do this automagically,
>Not that I know of, unless you use the advantages of mfs then. Full circle,
>bud. Now you're asking for necessities of the mfs or mfsroot systems.
I don't want to go there, and don't need to. I came up with a simple way to
populate /var from the original contents so I'm happy. The CD boots, c
On 4/6/10, Peter Steele wrote:
>>What incidentally does /var get populated with? Our image has a custom
>> directory under /var but this did not show up in the MFS versions of this
>> directory. I can get >around this but I wonder what else might not be
>> included?
>
> I found something else that
>I'm probably missing something here, but I'm not sure that's correct. If the
>OP wants his own /var, then diskless(8) describes how
>/var can be automagically populated (see also /etc/rc.initdiskless). The
>nanobsd.sh script (designed with flash drives in mind) uses
>this method. I looked int
On 4/6/10, Matthew Seaman wrote:
> On 07/04/2010 06:28:40, Peter Steele wrote:
>> I found something else that's missing--/var/db/pkg is empty. It looks
>> like what the auto-var process does is a construct basic directory
>> structure but no data. Is there a solution to this? Can I get /var to
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/04/2010 12:09:56, Peter Steele wrote:
>> Can you write a few shell scripts? You'ld need to create a tarball
>> of the /var contents you need on the box, and explode it onto /var
>> at boot time -- if you're using auto-var on MFS all the time,
>
>Can you write a few shell scripts? You'ld need to create a tarball of the
>/var contents you need on the box, and explode it onto
> /var at boot time -- if you're using auto-var on MFS all the time, you'll
> need to set that up to happen on every reboot.
Obviously I can do that. What I was rea
On Wed, 7 Apr 2010 00:28:40 -0500 Peter Steele wrote:
> I found something else that's missing--/var/db/pkg is empty. It looks
> like what the auto-var process does is a construct basic directory
> structure but no data. Is there a solution to this? Can I get /var to
> be populated with the full co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/04/2010 06:28:40, Peter Steele wrote:
> I found something else that's missing--/var/db/pkg is empty. It looks
> like what the auto-var process does is a construct basic directory
> structure but no data. Is there a solution to this? Can I get /va
>What incidentally does /var get populated with? Our image has a custom
>directory under /var but this did not show up in the MFS versions of this
>directory. I can get >around this but I wonder what else might not be included?
I found something else that's missing--/var/db/pkg is empty. It look
On 4/6/10, Peter Steele wrote:
>>If FreeBSD cannot write to /tmp or /var on boot, it automatically
>>creates a MFS filesystems for those mountpoints and mounts them during
>> boot. You don't need to do anything.
>>
>>It works as the same readonly compactflash environments out there.
>
> What inci
>If FreeBSD cannot write to /tmp or /var on boot, it automatically
>creates a MFS filesystems for those mountpoints and mounts them during boot.
>You don't need to do anything.
>
>It works as the same readonly compactflash environments out there.
What incidentally does /var get populated with?
On 4/5/10, Peter Steele wrote:
>>If FreeBSD cannot write to /tmp or /var on boot, it automatically creates a
>> MFS filesystems for those mountpoints
>>and mounts them during boot. You don't need to do anything.
>>
>>It works as the same readonly compactflash environments out there.
>
> D'oh! Man
>If FreeBSD cannot write to /tmp or /var on boot, it automatically creates a
>MFS filesystems for those mountpoints
>and mounts them during boot. You don't need to do anything.
>
>It works as the same readonly compactflash environments out there.
D'oh! Man, wish I had known that. I just tried it
On 4/5/10, Peter Steele wrote:
>> But ... why are you constricting yourself to use mfs_root? I have many
>> times ran FreeBSD completely from CDrom, which
>>will give you all 700 (or a DVD, 4.3G) usable space.
>>
>>I'd be happy to help, if you have questions. but please direct the
>> questions t
> But ... why are you constricting yourself to use mfs_root? I have many times
> ran FreeBSD completely from CDrom, which
>will give you all 700 (or a DVD, 4.3G) usable space.
>
>I'd be happy to help, if you have questions. but please direct the questions
>to the mailing list.
The reason I was
On 4/5/10, Peter Steele wrote:
> We have a USB boot stick based cloning process that we're considering
> porting to a DVD based media. I'm not sure though that it's possible due to
> the restrictions I've seen in the mfsroot environment we'd have to use. For
> example, in our USB disk procedure, w
>It sounds like http://mfsbsd.vx.sk/ would be helpful to you.
>(I havent used it yet due to lack of time but it looks good.)
Hmmm, that just might do the trick. I'll check it out, thanks.
___
freebsd-questions@freebsd.org mailing list
http://lists.freeb
On 05/04/2010 18:03, Peter Steele wrote:
> We have a USB boot stick based cloning process that we're considering porting
> to a DVD based media. I'm not sure though that it's possible due to the
> restrictions I've seen in the mfsroot environment we'd have to use. For
> example, in our USB disk
20 matches
Mail list logo
