On Thu, Nov 26, 2020 at 11:12:45 +0100, Stefan G. Weichinger wrote:
> Am 25.11.20 um 22:39 schrieb Debra S Baddorf:
>
> >>the theory is good, sure. I will test the restore aside from amrecover
> >>tomorrow.
> >
> >
> >If so, remember to ???throw out??? the first block of the file, which will
> >choke the zip program.
> >dd -skip=1 etc
>
> I was able to amrestore correctly .. no "-r", no skipping.
(Did you try this while the real pigz binary was in place, or only after
you replaced it with "gzip"?)
On Thu, Nov 26, 2020 at 08:48:02 +0100, Stefan G. Weichinger wrote:
> But guess what I did already ...
>
> # cp /usr/bin/pigz /usr/bin/pigz-original
>
> # cp /usr/bin/gzip /usr/bin/pigz
>
> # amrecover ....
>
> works :-P
Since you have a workaround now I don't know how much more effort you
want to spend on this, but if you do want to investigate further you
could try replacing /usr/bin/pigz with a shell script wrapper which
calls pigz-original but writes some debugging messages, etc. to a log
file before and after invoking pigz-original, and exits with a "success"
status. Basically just trying to see if there is any fussing you can do
to how pigz is invoked or how the exit status is processed which changes
the overall behavior of amrestore-calling-pigz.
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
