core dump with dump command SOLVED

Joe Auty joe at
Thu Feb 16 06:29:22 PST 2006

Thanks everybody for their help.

As it turns out, I guess dump was being starved for memory, as  
running it while booted into FreeBSD normally using -L to indicate a  
live filesystem worked just fine. I believe this is because there is  
an extra swap file available from a normal FreeBSD boot, as specified  
in my /etc/rc.conf. I'm not sure if my theory completely holds up,  
but there you have it.

Thanks again! I'm up and running...

On Feb 16, 2006, at 9:25 AM, Lowell Gilbert wrote:

> Joe Auty <joe at> writes:
>> I'm running 5.4. Perhaps restore is generating this particular error
>> message? I don't know.
> It would be hard to tell, without an intermediate disk to write the
> data to so you can separate the dump from the restore.  You might be
> able to trace one of the processes to see, but that requires a bit of
> technical knowledge.
>> I may have to go this route, see if I can put together the disk space
>> to manage this. Is there a way to get tar to just extract directly to
>> a destination directory so I don't have to contend with a single
>> large tarball I need to create disk space for?
> Sure.  As far as I'm concerned, that's the normal way to copy
> directory trees.  You just pipe the output of the tar process into
> another tar process that un-tars it in another place.
> E.g.:
> tar -C ~/work/debugger -cf - . | tar -C temp -xf -
>>>>                  My disk is over a 100 gigabytes, could this be  
>>>> what
>>>> is causing dump to crap out?
>>> Could be.  Check your memory statistics while you're doing it,  
>>> and see
>>> if you run out of VM.
>> What is a good strategy for dealing with this possibility, should I
>> go down that path?
> Start by watching top(1) while it's running...
> _______________________________________________
> freebsd-questions at mailing list
> To unsubscribe, send any mail to "freebsd-questions- 
> unsubscribe at"

More information about the freebsd-questions mailing list