core dump with dump command SOLVED
joe at netmusician.org
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 netmusician.org> 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.
> tar -C ~/work/debugger -cf - . | tar -C temp -xf -
>>>> My disk is over a 100 gigabytes, could this be
>>>> 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 freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-questions-
> unsubscribe at freebsd.org"
More information about the freebsd-questions