@craig-stephens Please provide the full replication log you find in /var/log/fog/... on your master server.

@Quazz The error message is definitely thrown by glibc: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/dl-osinfo.h;hb=ef4e158c736d067304164c3daa763e4f425af248#l44

@Quazz said in Very slow cloning speed on specific model:

edit: perhaps here https://github.com/Thomas-Tsai/partclone/blob/master/fail-mbr/compile-mbr.sh
It might accidentally call system GCC which might use a newer glibc version, thus causing the mismatch?

Hmm interesting idea!! Looking at this for a bit I can’t think of how this could make partclone hit the wall. The messge “Broken pipe” usually means that the program feeding the pipe crashed. In this case pigz. Though this should actually compile against the proper buildroot glibc (older version): https://github.com/FOGProject/fos/blob/master/Buildroot/package/pigz/pigz.mk

@gusto This is run on your Proxmox server console???

@renanserrou In the error log posted we see:

Error multiple hosts returned for list of mac addresses

You seem to have different hosts using the same MAC address (usually one as primary MAC and others as additional MACs). See here on how to find those in the database: https://forums.fogproject.org/topic/8448/response-error-multiple-hosts-returned-for-list-of-mac-addresses

@marted said in FOG Client cannot communicate with the server (token.data missing):

Middleware::Communication URL: http://192.168.149.43/fog/management/index.php?sub=requestClientInfo&mac=C8:CB:B8:0C:DA:CE|18:CF:5E:89:39:23|1A:CF:5E:89:39:23|1A:CF:5E:89:31:23|18:CF:5E:07:83:5B||00:00:00:00:00:00:00:E0&newService&json
...
Middleware::Response Invalid MAC address format

This is the important information from the log as I see it. Maybe this helps? https://forums.fogproject.org/topic/13095/response-invalid-mac-address-format-windows-7-client

@dylan123 We have seen this “late” message of “kernel too old” already and I still have no idea how it can happen that late in the process. When you leave the init parameter off it uses the current init file which shouldn’t be capable to play with the 4.9.51 kernel and ends in a Kernel panic. That’s understandable. But why the heck do we see the “kernel too old” when it already booted all the way into FOS and started cloning? @Quazz Any ideas?

Is you image set to “Partclone zstd” or “Partclone grip”??

@thennessey said in Error Trying to Restore GPT Partition Tables:

I swapped out the files in the google drive link for the ones that are associated with the win10UEFItest image that I originally had questions about.

I see you swapped those out (numbers in the files are different) but I still cannot reproduce the issue as reported. The numbers seem ok and I can deploy using those files to a 100 GB size VM disk perfectly fine…

@jcargile I am not sure yet but from my point of view it’s very likely we can make this work. Rename a couple of files and maybe do a bit of converting…

Please run the following commands and post output here:

cat Images/<IMAGENAME>/guid
cat Images/<IMAGENAME>/schema
cat Images/<IMAGENAME>/hd0/table

@gusto Don’t run the command within the fog-server but on your proxmox host after you have tried to destroy it. Make sure you use the right VM ID. It might not be 111 anymore if you keep destroying and re-creating it.