Lähettäjä: Peter Duffy Päiväys: Vastaanottaja: DNG Aihe: [DNG] virtualbox
Sorry, this isn't specific to devuan (although it's involved
indirectly) - I'm really just looking for thoughts and comments on a
problem which has been driving me insane for the last few weeks.
I'm trying to replicate a setup of several fairly old linux/mysql
systems, as part of a project to upgrade them to devuan. I was trying
to use virtualbox VMs to do the replication (virtualbox 6.1.32). First
VM was ubuntu 14 and percona mysql 5.6.37; second VM was devuan
chimaera and percona mysql 5.6.37. Each VM had 32g RAM, 1 CPU core and
500g disk. I had a copy of the database from one of the original
systems (gzipped output from mysqldump) and the first step was to load
it into the first VM. That was when the problems started.
Loading the dump just consisted of "gunzip -c <file> | mysql
<credentials and options>" - I've done it successfully on many systems
before now. This time, the mysql client kept choking, with complaints
that the input contained binary zeroes. That's not supposed to happen -
mysqldump is supposed to output a file consisting of valid SQL
statements and comments, designed to be poured straight back into mysql
(I've never had a problem with it before now). 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. I then wrote a little
prog to scan for binary zeros, and ran it on both files: not there in
the one done on the physical box; there in the one done on the VM.
After tearing my hair over this for over a week and getting nowhere, I
decided to ditch the idea of using virtualbox VMs, dug out some old
retired boxes, set them up to match the VMs, and tried the load on the
first one again. This time, no problems (apart from the fact that the
load takes forever).
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.
Has anyone else ever experienced anything else even remotely similar?
I've not been able to find anything relevant on google. 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?