Bug#360104: mondo: cannot restore from .iso image on hard drive

2006-09-27 Thread Andree Leidenfrost
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

2006-09-26 Thread Norman Ramsey
  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

2006-04-16 Thread Andree Leidenfrost
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

2006-04-09 Thread Norman Ramsey
  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]