Re: non-responsive FreeBSD-9.0 after dump command
Le Wed, 18 Jan 2012 16:42:10 -0700, Dale Scott dalesc...@shaw.ca a écrit : # mount /dev/ada0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/ad1as1d on /backup (ufs, local, soft-updates) # # cd /backup # dump -0aLf 20120118.dump / There is no output after hitting enter, and afterwards the system is generally unresponsive. A command (e.g., whoami) typed into the VirtualBox server console and an ssh terminal is echo'd, but that's all. I had started top in a seperate ssh terminal before issuing the dump command, and it shows mksnap_ffs running with 98%-100% WCPU for about 55 minutes, at which point top stops updating. I gave up after 70 minutes and yanked the virtual power cord. There are several reports that snapshots are broken on ufs+SUJ and dump takes a snapshot. Regards. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
non-responsive FreeBSD-9.0 after dump command
I'm getting a non-responsive system after issuing dump on a relatively fresh install of FreeBSD-9.0-RELEASE. The system is a VirtualBox 4.1.2 vm, with a 20GB GPT system drive and a 20GB MBR backup drive. Since it was created, the ports tree has been updated and apache22, mysql55-server and python/django installed (and a number of minor utilities). Everything seems to work ok, except for dump: # mount /dev/ada0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/ad1as1d on /backup (ufs, local, soft-updates) # # cd /backup # dump -0aLf 20120118.dump / There is no output after hitting enter, and afterwards the system is generally unresponsive. A command (e.g., whoami) typed into the VirtualBox server console and an ssh terminal is echo'd, but that's all. I had started top in a seperate ssh terminal before issuing the dump command, and it shows mksnap_ffs running with 98%-100% WCPU for about 55 minutes, at which point top stops updating. I gave up after 70 minutes and yanked the virtual power cord. I then created a new FBSD-9.0 VM (system install from dvd only, and also create/fdisk/label/mount a new virtual backup drive). On this vm, dump works as expected! I moved the virtual backup drive from new to old, and also re-partitioned/re-labled the backup drive on the problem system, but no effect. FWIW, fdisk reports that on both system disks (non-working and working), the chunks do not start on track boundaries (I used auto installing the systems). Does any of this make any sense to anyone? Any ideas on how to correct the situation? I don't mind re-configure the new vm like the old, but not knowing what went wrong concerns me (and if it's just going to happen again). My basic intent is to get version 2 of a live server working first as a vm, then restore a dump onto real hardware. Thanks in advance for any and all assistance, Dale - Transparency with Trust http://www.dalescott.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Dump Command?
Is it possible to dump a file system except for a specified directory? Or does the dump command require that the WHOLE file system is dumped? I remember gtar being able to negate archiving specific files. Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dump Command?
On Sat, 19 Jan 2008, Chris Maness wrote: Is it possible to dump a file system except for a specified directory? Or does the dump command require that the WHOLE file system is dumped? I remember gtar being able to negate archiving specific files. See the dump man page for the nodump flag, which can be set with chflags(1). -Warren Block * Rapid City, South Dakota USA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: core dump with dump command in single user mode
Joe Auty [EMAIL PROTECTED] 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: core dump with dump command SOLVED
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 [EMAIL PROTECTED] 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: core dump with dump command SOLVED
On Feb 16, 2006, at 9:52 AM, Giorgos Keramidas wrote: On 2006-02-16 09:29, Joe Auty [EMAIL PROTECTED] wrote: 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... That's very likely. I usually start single user mode with something like the following: # adjkerntz -i # swapon -a # fsck -p # mount -u / # mount -va Having a swap partition enabled definitely helps to avoid ending up without any free memory ;) I was doing swapon -a too, but perhaps this command does not enable swap directories that have been attached to /etc/rc.conf? --- Joe Auty NetMusician: web publishing software for musicians http://www.netmusician.org [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: core dump with dump command SOLVED
On 2006-02-16 09:29, Joe Auty [EMAIL PROTECTED] wrote: 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... That's very likely. I usually start single user mode with something like the following: # adjkerntz -i # swapon -a # fsck -p # mount -u / # mount -va Having a swap partition enabled definitely helps to avoid ending up without any free memory ;) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: core dump with dump command SOLVED
On 2006-02-16 09:56, Joe Auty [EMAIL PROTECTED] wrote: On Feb 16, 2006, at 9:52 AM, Giorgos Keramidas wrote: On 2006-02-16 09:29, Joe Auty [EMAIL PROTECTED] wrote: 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... That's very likely. I usually start single user mode with something like the following: # adjkerntz -i # swapon -a # fsck -p # mount -u / # mount -va Having a swap partition enabled definitely helps to avoid ending up without any free memory ;) I was doing swapon -a too, but perhaps this command does not enable swap directories that have been attached to /etc/rc.conf? It enables all partitions listed as 'swap' in /etc/fstab. You are probably using a `swapfile', instead of a swap partition, so that wouldn't enable it, because the relevant file system may not be mounted at the time you run 'swapon'. This is one of the reasons behind my tendency to use a separate swap partition instead of swapfile=foo in `/etc/rc.conf' :-/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: core dump with dump command in single user mode
On Feb 14, 2006, at 5:46 PM, Lowell Gilbert wrote: Joe Auty [EMAIL PROTECTED] writes: On Feb 14, 2006, at 9:08 AM, Lowell Gilbert wrote: Joe Auty [EMAIL PROTECTED] writes: Hello, Following the instructions here: http://www.unixcities.com/howto/ index.html I did a: Those directions are a little outdated, but the problem is really just that you didn't follow the directions closely enough: dump -0f - /usr | restore -rf - /backup/usr should have been more like dump -0f - /usr | (cd /backup/usr;restore -xf - ) Okay, I'm still getting: no space left in string table abort? If I say n, it just core dumps Funny, I can't find that message in the source for dump at all. The message, in -STABLE, is Do you want to abort dump?. I also can't seem to find the string table error message, but I may just have failed to search the right library so far. Are you running something before 5.2? I'm running 5.4. Perhaps restore is generating this particular error message? I don't know. Any other suggestions? Plenty. If there are no special files (fifos, etc.) on the disk, any archiver will do it. e.g., tar(1) Would using dd be a valid workaround to cloning my disk? Sure. If you really want a *clone* of the disk, it's a good option. If having the same data files in the same filestructure would do, then copying other attributes is overkill. 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? 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? --- Joe Auty NetMusician: web publishing software for musicians http://www.netmusician.org [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: core dump with dump command in single user mode
Joe Auty [EMAIL PROTECTED] writes: Hello, Following the instructions here: http://www.unixcities.com/howto/ index.html I did a: Those directions are a little outdated, but the problem is really just that you didn't follow the directions closely enough: dump -0f - /usr | restore -rf - /backup/usr should have been more like dump -0f - /usr | (cd /backup/usr;restore -xf - ) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: core dump with dump command in single user mode
On Feb 14, 2006, at 9:08 AM, Lowell Gilbert wrote: Joe Auty [EMAIL PROTECTED] writes: Hello, Following the instructions here: http://www.unixcities.com/howto/ index.html I did a: Those directions are a little outdated, but the problem is really just that you didn't follow the directions closely enough: dump -0f - /usr | restore -rf - /backup/usr should have been more like dump -0f - /usr | (cd /backup/usr;restore -xf - ) Okay, I'm still getting: no space left in string table abort? If I say n, it just core dumps Any other suggestions? Would using dd be a valid workaround to cloning my disk? My disk is over a 100 gigabytes, could this be what is causing dump to crap out? --- Joe Auty NetMusician: web publishing software for musicians http://www.netmusician.org [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: core dump with dump command in single user mode
Joe Auty [EMAIL PROTECTED] writes: On Feb 14, 2006, at 9:08 AM, Lowell Gilbert wrote: Joe Auty [EMAIL PROTECTED] writes: Hello, Following the instructions here: http://www.unixcities.com/howto/ index.html I did a: Those directions are a little outdated, but the problem is really just that you didn't follow the directions closely enough: dump -0f - /usr | restore -rf - /backup/usr should have been more like dump -0f - /usr | (cd /backup/usr;restore -xf - ) Okay, I'm still getting: no space left in string table abort? If I say n, it just core dumps Funny, I can't find that message in the source for dump at all. The message, in -STABLE, is Do you want to abort dump?. I also can't seem to find the string table error message, but I may just have failed to search the right library so far. Are you running something before 5.2? Any other suggestions? Plenty. If there are no special files (fifos, etc.) on the disk, any archiver will do it. e.g., tar(1) Would using dd be a valid workaround to cloning my disk? Sure. If you really want a *clone* of the disk, it's a good option. If having the same data files in the same filestructure would do, then copying other attributes is overkill. 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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
core dump with dump command in single user mode
Hello, Following the instructions here: http://www.unixcities.com/howto/ index.html I did a: dump -0f - /usr | restore -rf - /backup/usr And after a while (after copying .56% of my files), gave me the following error: no space for string table asked me if I want to abort, I said no, and it core dumped. It did this while in single user mode with the volumes on both of my hard drives mounted (I was trying to dump from one HD to the other). What do you suggest I do? --- Joe Auty NetMusician: web publishing software for musicians http://www.netmusician.org [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
