Hi Bob, thanks for that. I have been wondering about trying kvm instead
of virtualbox, and I might still try it. The original dump has now
imported clean into mysql 5.6.37 on the physical ubuntu 14 box which I
set up - apart from anything else, that is deeply reassuring, as I was
starting to wonder if there was something wrong on the original system!

I did wonder if it might be a memory problem - but I would have thought
that gunzip would have just borked, and there would have been something
in the dmesg output. There didn't seem to be. 

At least it's looking as though I can complete the basic emulation of
the original systems - provided that I can find enough old boxes :(

On Tue, 2022-10-18 at 16:49 -0600, Bob Proulx via Dng wrote:
> Peter Duffy wrote:
> > Loading the dump just consisted of "gunzip -c <file> | mysql
> > ...
> > This time, the mysql client kept choking, with complaints
> > that the input contained binary zeroes.
> > ...
> > I tried gunzipping the file on the VM, and on a separate physical
> > box with the same version of gunzip, then comparing the md5sums of
> > the files: original - md5sum matches; unzipped file - md5sums
> > didn't
> > match.
>
> Just to summarize then this really has nothing to do with mysql or
> mariadb but can be reduced to a corruption problem either with data
> going into gzip or being produced from gzip.
>
> > At the moment, what seems to be inescapable is that gunzipping
> > files in
> > linux on virtualbox VMs can in some cases cause file corruption.
> > Given
> > that the identical procedure works on a physical box, it seems to
> > exclude gzip itself, the shell (bash), the file system, and the
> > kernel.
> > The only thing which seems to be left is virtualbox itself.
>
> The first thing I worried about would be if the gunzip has enough
> memory to run and complete the action.  And also if there is enough
> disk space in the mysql backend storage.  There is little error
> detection in gzip and GIGO garbage-in-garbage-out applies to it.  I
> would also double check that the input files are identical between
> the
> two cases too.
>
> Since I would be worried about having enough memory I would check the
> system log /var/log/syslog looking for OOM events.  The Out Of Memory
> Killer might have gotten involved.  That would be bad.
>
> > Has anyone else ever experienced anything else even remotely
> > similar?
> > I've not been able to find anything relevant on google.
>
> Over the years have seen things as simple as a bad SATA cable produce
> data corruption reading data off of disks.  Have seen bad RAM dimms
> corrupt blocks of memory, since ECC RAM is rare these days.
>
> You are asking if something crazy is possible all I can respond with
> is that yes it is possible for crazy things to happen and produce
> bizarre behavior.  That can make debugging difficult.  But so far
> there doesn't seem to be quite enough evidence to show that something
> that deep is happening.  Not yet anyway.
>
> But it seems you have a reproducible test case.  That's good.  That
> the gunzip < file | md5sum produces the wrong result is much simpler.
>
> > Also - has anyone any preferences for virtualisation under linux:
> > what seems to be the most reliable from the range of available
> > tools
> > to do it?
>
> I thought Linux KVM has pretty much taken over the virtualization
> world on Linux.  Mostly using libvirt and virt-manager.
>
> > Thoughts would be most welcome!
>
> Good luck!
> Bob
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng