restore in app-arch/dump-0.4.28-r1 bombs out on my system dump seems to work: DUMP: Date of this level 0 dump: Thu Jul 11 22:42:53 2002 DUMP: Dumping /dev/hde3 (/home) to /backups/sparky/0_home.bz2 DUMP: Added inode 37 to exclude list (journal inode) DUMP: Added inode 7 to exclude list (resize inode) DUMP: Label: none DUMP: Compressing output at compression level 2 (bzlib) DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 433698 tape blocks. DUMP: Volume 1 started with block 1 at: Thu Jul 11 22:42:56 2002 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 38.17% done at 551 kB/s, finished in 0:08 DUMP: 73.30% done at 529 kB/s, finished in 0:03 DUMP: Closing /backups/sparky/0_home.bz2 DUMP: Volume 1 completed at: Thu Jul 11 22:56:53 2002 DUMP: Volume 1 took 0:13:57 DUMP: Volume 1 transfer rate: 249 kB/s DUMP: Volume 1 470720kB uncompressed, 208585kB compressed, 2.257:1 DUMP: 470720 tape blocks (459.69MB) on 1 volume(s) DUMP: finished in 837 seconds, throughput 562 kBytes/sec DUMP: Date of this level 0 dump: Thu Jul 11 22:42:53 2002 DUMP: Date this dump completed: Thu Jul 11 22:56:53 2002 DUMP: Average transfer rate: 249 kB/s DUMP: Wrote 470720kB uncompressed, 208585kB compressed, 2.257:1 DUMP: DUMP IS DONE but restore fails: sparky sparky # restore -iv -f 0_home.bz2 Segmentation fault sparky sparky # strace restore -iv -f 0_home.bz2 execve("/sbin/restore", ["restore", "-iv", "-f", "0_home.bz2"], [/* 37 vars */]) = 0 fcntl64(0, F_GETFD) = 0 fcntl64(1, F_GETFD) = 0 fcntl64(2, F_GETFD) = 0 geteuid32() = 0 getuid32() = 0 getegid32() = 0 getgid32() = 0 brk(0) = 0x80f3ef4 brk(0x80f3f14) = 0x80f3f14 brk(0x80f4000) = 0x80f4000 brk(0x80f5000) = 0x80f5000 umask(077) = 022 rt_sigaction(SIGINT, {0x804b1b4, [INT], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, {0x804b1b4, [TERM], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++
does 0.4.29 give you the same kinds of problems?
Ian?
Pardon me - didn't boot up last night! 0.4.29 still segfaults, will try backup & restore without compression, then remerging zlib
Hmmm, segfaults without compression as well
If you do a dump and restore on a simple directory with a couple of files, does the problem still happen? What I am trying to figure out is if it is a compile problem on our part or a code problem on dump/restore's part. There are already no optimization flags set for the compile so I doubt it is a compiling problem. Please let me know what your experience is. Is it crashing on ALL restores or just specifically when working with your home directory?
Ian are you still around?
Sorry, too sunny in the UK ATM, I get segfaults even with a dir with one file in it. Haven't found one that works at all. BTW is this confirmed, or is it just me?
ns1 tmp # dump -f/home/raker/dumptest.bz2 -j /mnt/tmp/httpd DUMP: Date of this level 0 dump: Fri Jul 26 14:10:56 2002 DUMP: Dumping /dev/hde1 (/ (dir mnt/tmp/httpd)) to /home/raker/dumptest.bz2 DUMP: Added inode 8 to exclude list (journal inode) DUMP: Added inode 7 to exclude list (resize inode) DUMP: Label: none DUMP: Compressing output at compression level 2 (bzlib) DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 63188 tape blocks. DUMP: Volume 1 started with block 1 at: Fri Jul 26 14:10:57 2002 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing /home/raker/dumptest.bz2 DUMP: Volume 1 completed at: Fri Jul 26 14:12:18 2002 DUMP: Volume 1 took 0:01:21 DUMP: Volume 1 transfer rate: 671 kB/s DUMP: Volume 1 64800kB uncompressed, 54411kB compressed, 1.191:1 DUMP: 64800 tape blocks (63.28MB) on 1 volume(s) DUMP: finished in 81 seconds, throughput 800 kBytes/sec DUMP: Date of this level 0 dump: Fri Jul 26 14:10:56 2002 DUMP: Date this dump completed: Fri Jul 26 14:12:18 2002 DUMP: Average transfer rate: 671 kB/s DUMP: Wrote 64800kB uncompressed, 54411kB compressed, 1.191:1 DUMP: DUMP IS DONE That appeared to go fine... Now for the restore... ns1 tmp # restore -iv -f /home/raker/dumptest.bz2 Verify tape and initialize maps Input is from file/pipe Input block size is 10 Dump tape is compressed. Dump date: Fri Jul 26 14:10:56 2002 Dumped from: the epoch Level 0 dump of / (dir mnt/tmp/httpd) on ns1.eesbt.com:/dev/hde1 Label: none Extract directories from tape Initialize symbol table. restore > ls .: 2 ./ 2 ../ 507905 mnt/ restore > cd mnt/ restore > ls ./mnt: 507905 ./ 2 ../ 2343459 tmp/ restore > cd tmp/ restore > ls ./mnt/tmp: 2343459 ./ 507905 ../ 4390980 httpd/ restore > cd httpd/ restore > ls ./mnt/tmp/httpd: 4390980 ./ 4784184 icons/ 3473821 temp/ 2343459 ../ 2031689 original-htdocs/ 4390981 htdocs/ 2884361 source_images/ restore > quit ns1 tmp # It appears to work for me... :| So my next questions are... What kernel are you running? What version of e2fsprogs? What is the filesystem type that you are dumping from?
Just to clarify, this was a working setup until recently, so I can only assume some libs have become "out of alignment" as it were . . . anyway, your questions: What kernel are you running? 2.4.19-gentoo-r7 What version of e2fsprogs? e2fsprogs-1.27 What is the filesystem type that you are dumping from? ext3
New version of dump is in portage. Please test and let me know how it goes for you.
Hmmm, exactly the same result, tiny dump, no compression, ext3 sparky root # dump -0 -f root.bz2 .tuxracer DUMP: Date of this level 0 dump: Sun Jul 28 20:08:46 2002 DUMP: Dumping /dev/hde7 (/ (dir root/.tuxracer)) to root.bz2 DUMP: Added inode 8 to exclude list (journal inode) DUMP: Added inode 7 to exclude list (resize inode) DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 207 tape blocks. DUMP: Volume 1 started with block 1 at: Sun Jul 28 20:08:47 2002 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing root.bz2 DUMP: Volume 1 completed at: Sun Jul 28 20:08:47 2002 DUMP: Volume 1 200 tape blocks (0.20MB) DUMP: 200 tape blocks (0.20MB) on 1 volume(s) DUMP: finished in less than a second DUMP: Date of this level 0 dump: Sun Jul 28 20:08:46 2002 DUMP: Date this dump completed: Sun Jul 28 20:08:47 2002 DUMP: Average transfer rate: 0 kB/s DUMP: DUMP IS DONE sparky root # restore -iv -f root.bz2 Segmentation fault sparky root # strace restore -iv -f root.bz2 execve("/sbin/restore", ["restore", "-iv", "-f", "root.bz2"], [/* 39 vars */]) = 0 fcntl64(0, F_GETFD) = 0 fcntl64(1, F_GETFD) = 0 fcntl64(2, F_GETFD) = 0 geteuid32() = 0 getuid32() = 0 getegid32() = 0 getgid32() = 0 brk(0) = 0x80f3ef4 brk(0x80f3f14) = 0x80f3f14 brk(0x80f4000) = 0x80f4000 brk(0x80f5000) = 0x80f5000 umask(077) = 022 rt_sigaction(SIGINT, {0x804b1b4, [INT], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, {0x804b1b4, [TERM], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ sparky root # ltrace restore -iv -f root.bz2 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++
I just did another dump/restore. This time from an ext3 filesystem instead of ext2. My guess is that the problem may not be with dump itself if you are still experiencing problems. The next step instead of just compiling or recompiling dump is to do a a recompile of the dependancy tree. "emerge --emptytree dump" should recompile all programs that are prerequisites to dump along with dump itself. The output of strace is seemingly inconclusive but my first guess is this may be some problem related to readline. If you are running a gcc-3.1 based system then you shouldn't have a problem as readline works fine. If I remember correctly, there are some issues with newer versions of readline with gcc-2.x... By the way, what version of gcc are you using?
gcc 2.95.3 Done emptytree emerge, same results :( I tried restoring from the previous dump file, then with a fresh one. Segfault both times.
dump-0.4.31 has just been released in portage. If you are still around and willing to test the new version, please let me know. I still don't have any problems doing a dump/restore.
Still segfaults !!! ?????
I cannot get the software to act up. Have you filed a bug report on the dump.sourceforge.net site? One more thought... you said that you were re-merging zlib at one point... even though you would need to re-merge bzip2 if compression was the problem. It seems to be segfaulting rather early in the execution of restore so maybe it just cannot uncompress the bz2 file? emerge rsync, emerge bzip2???
I've re-merged bzip2 and dump - no change. Since the executables are static I can't really see why it happens. However, since my attention was drawn to http://old.lwn.net/2001/0503/a/lt-dump.php3 I've started using tar instead. I will be happy to test any suggestions you might come up with, though. Thanks for trying to help . . .
I just emailed the author and pointed him to the post by Linus Torvalds. If/When I get a response I will post back here on this bug report.
Please check this page out... http://www.pocnet.net/hobby/computer/dump.html This link was given to me by the author of dump. These are the "safest" scenarios -------------------------------- If dumping a device, unmount it. If dumping a directory, mount it read-only. If you can, test your dumps and restores like this and let me know if you still have problems.
Thanks for the link Nick, the info makes sense to me, no perfect solution anywhere - however at the moment I am obliged to use tar. I don't think there is anything to test that I haven't already tried, and the data is (are) guaranteed static. Since you cannot reproduce the behaviour, and no one else has reported it or commented here, it looks very much like I have a sneaky mismatch somewhere in my system. Hopefully at some point stuff will be updated and it will start working again . . .
To do an entire rebuild of your system you can do an... emerge --emptytree world That's pretty much the best you can do on a live running system to recompile everything. Or you can boot off a gentoo iso, mount your filesystems, and re- bootstrap the system to get the cleanest installation of packages. Would you like me to keep the bug report open?
If it's just me, then you might as well, I suppose. Thanks anyway!
star-1.5_alpha06 has been added to portage. It is currently masked. But if you are interested in installing the new version of star, (which dump uses), I encourage you to unmask it and test it and then re-install dump. If you could let me know if the dump and restore stops segfaulting with this new version that would be great. :)
