Bug#360104: mondo: cannot restore from .iso image on hard drive
Hi Norman, Thanks for getting back to me on this one! And sure, no worries, please feel free to open a new bug when more information transpires. Best regards, Andree On Tue, 2006-09-26 at 19:21 -0400, Norman Ramsey wrote: > > To tell you the truth, I'm a little bit at a loss about what to do here. > > Me, too. > > > Could you run two afio processes directly over two separate reasonably > > large directories (say a few hundred megs each) and then unpack the > > archives again and compare them to the originals? Also, if you could run > > memtest86 or something similar to verify that your RAM is ok that would > > also be good. > > I've done both of these things. No alerts. > > I think the best thing is for you to close this bug report, and next > summer when I am not teaching, perhaps I will try to reproduce the > problem. > > > > Norman -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#360104: mondo: cannot restore from .iso image on hard drive
> To tell you the truth, I'm a little bit at a loss about what to do here. Me, too. > Could you run two afio processes directly over two separate reasonably > large directories (say a few hundred megs each) and then unpack the > archives again and compare them to the originals? Also, if you could run > memtest86 or something similar to verify that your RAM is ok that would > also be good. I've done both of these things. No alerts. I think the best thing is for you to close this bug report, and next summer when I am not teaching, perhaps I will try to reproduce the problem. Norman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#360104: mondo: cannot restore from .iso image on hard drive
Hi Norman, To tell you the truth, I'm a little bit at a loss about what to do here. Whilst preparing the mindi-1.07-1 and mondo-2.07-1 packages I made intensive use of the verify feature because of the bugs you reported. I didn't find any problems at all (apart from verify not working via NFS, which I fixed, so the testing was definitely worth it). mondoarchive uses afio to create the actual archive files. The diffs you sent through via #360130 indicate to me that afio didn't create some of the archive files correctly. Could you run two afio processes directly over two separate reasonably large directories (say a few hundred megs each) and then unpack the archives again and compare them to the originals? Also, if you could run memtest86 or something similar to verify that your RAM is ok that would also be good. More comments inline below... On Sun, 2006-04-09 at 20:20 -0400, Norman Ramsey wrote: > > Hi Norman, > > > > [..] > > Andree, > > I'm embarrassed to say that I'm not sure I saved the .iso file --- and > even if I did, the hard drive with that .iso on it is now sitting in > the basement of my house. I see, no problem. > > Other than that, the above log is from a mondoarchive run. Could you > > send the log from the failed mondorestore run? > > All I have is the log file I sent you (with probably some later > archive/restore runs as well). Where should I be looking for the > mondorestore log? It is also /var/log/mondoarchive.log when mondorestore is run (confusing, I know). The log file you attached to #360130 contains actually both. For the restore it doesn't seem to indicate any errors though. Strange. > I apologize for sending in what may turn out to be a useless bug > report. Next time I do a backup, if anything goes wrong I will be > more careful to save evidence. (Though at present I'm a bit short of > space for 4GB files.) No worries, mondo is pretty powerful but if something goes wrong can be very hard to troubleshoot. > I do have a gentle comment---the log files are quite difficult to read > for those not already knowing how mondo works. It might be worth > investing some effort trying to make them more perspecuous. I feel your pain. It was certainly hard in the beginning for me, too. But believe it or not, it is actually quite useful the way it is because it is very detailed and makes it easy to match log events againstlines in the code. However, if you have concrete suggestions for how to improve things, I'm sure they will be openly considered. > One other thing you might find it helpful to know: during one of my > other restore attempts, my filesystem ran out of inodes. In this > case, mondo reports 'No space left on device', but of course df(1) > reports lots of blocks available. It might be worth putting a note in > mondo's documentation reminding people to check 'df -i'. Thanks for pointing this out. Appended to the wiki: http://openfacts.berlios.de/index-en.phtml?title=Mondorescue_FAQ > > Norman > Let's see whether doing the above tests shows anything new. Cheers, Andree -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#360104: mondo: cannot restore from .iso image on hard drive
> Hi Norman, > > Thank you for reporting this issue. > > I see in mondo-archive.log: > > [Main] libmondo-verify.c->verify_afioballs_on_CD#263: set = 219 > [Main] libmondo-verify.c->verify_an_afioball_from_CD#615: > Verifying /dtv2/tmp.mondo.25882/tmp.mondo.26014/cdrom/archives/219.afio.bz2 > [Main] libmondo-verify.c->verify_a_tarball#508: Verifying > fileset > '/dtv2/tmp.mondo.25882/tmp.mondo.26014/cdrom/archives/219.afio.bz2' > [Main] libmondo-verify.c->verify_a_tarball#541: > afio -r -P bzip2 > -Z /dtv2/tmp.mondo.25882/tmp.mondo.26014/cdrom/archives/219.afio.bz2 > >> /dtv2/tmp.mondo.25882/tmp.mondo.260 > $'/dtv2/tmp.mondo.25882/tmp.mondo.26014/cdrom/archives/219.afio.bz2' - > differences found > afio: / > > afio: / Input file = (stdin), output file = (stdout) > > afio: /usr/lib/libcdda_interface.so.0.9.8 > afio: / Data integrity error when decompressing. > > afio: /It is possible that the compressed file(s) have become corrupted. > > afio: /You can use the -tvv option to test integrity of such files. > > afio: /You can use the `bzip2recover' program to attempt to recover > > afio: /data from undamaged sections of corrupted files. > > and the same for set 348. > > Could you loop-mount the ISO image and test whether these files are in > fact corrupt by doing: > > bunzip -tvv 219.afio.bz2 > > and > > bunzip -tvv 348.afio.bz Andree, I'm embarrassed to say that I'm not sure I saved the .iso file --- and even if I did, the hard drive with that .iso on it is now sitting in the basement of my house. > Other than that, the above log is from a mondoarchive run. Could you > send the log from the failed mondorestore run? All I have is the log file I sent you (with probably some later archive/restore runs as well). Where should I be looking for the mondorestore log? I apologize for sending in what may turn out to be a useless bug report. Next time I do a backup, if anything goes wrong I will be more careful to save evidence. (Though at present I'm a bit short of space for 4GB files.) I do have a gentle comment---the log files are quite difficult to read for those not already knowing how mondo works. It might be worth investing some effort trying to make them more perspecuous. One other thing you might find it helpful to know: during one of my other restore attempts, my filesystem ran out of inodes. In this case, mondo reports 'No space left on device', but of course df(1) reports lots of blocks available. It might be worth putting a note in mondo's documentation reminding people to check 'df -i'. Norman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
