Re: bin/56643: problem with restore(8)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/56643; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Paul Goyette <paul%whooppee.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: bin/56643: problem with restore(8)
Date: Tue, 25 Jan 2022 05:12:46 +0700

     Date:        Mon, 24 Jan 2022 20:35:01 +0000 (UTC)
     From:        Paul Goyette <paul%whooppee.com@localhost>
     Message-ID:  <20220124203501.9EE431A923A%mollari.NetBSD.org@localhost>
 
   |  Is there some possibility of debug-printf()s to see details of which
   |  input file is being processed, so we can dump the on-disk structures
   |  from the input volume?
 
 With or without that, you need to start with a "bad" dump output file that
 is stable (no re-generating it for every run ... especially not using
 /var whose contents are likely to be different every time).
 
 Ideally the smallest dump you can come up with which exhibits the
 problem (since the issue is apparently with dump, once you have that
 image, restore should fail on it every time, no matter how or where run).
 
 Then either debug added to restore, or perhaps just running it with -i
 instead of -r, might allow the "bad" whatever it is to be located,
 and perhaps then it will be possible to examine the relevant data in
 the dump file to find out what has gone wrong.
 
 Perhaps even running restore under gdb with a breakpoint on the code
 that issues that error might work.
 
 But the bad dump image is where all this starts (if necessary, that could
 be exported for someone else to examine, if you get nowhere with it).
 
 kre