@Tom-Elliott said in Failure in Capturing an image:
@ismith-hpu But the machine, indeed, does have an OS on the disk? I can only assume the -a0 is a part of the problem. I don’t know what the argument is doing for the 0.3.12 version of partclone.
It’s to ensure compatibility with 0.2.89 images, allowing them to be deployed with 0.3.12.
0.2.89 had a broken checksum system, so we force it disabled on 0.3.12 in order to allow those images a normal deployment. It’s also faster and slightly smaller images, certainly not complaining about that part.
It is curious that 0.3.12 doesn’t seem to work in this instance, though I wonder if a non-resizable (not raw) capture has been tried?
I captured the image off the original machine.
I then deployed to 4 others.
They are all new machines fresh out of the box, same settings.
I set the boot order to have the m2 drive first above the network boot.
If I remove the the network boot from the boot order, the PC will not boot.
If I boot to fog and then select boot from hard disk, it boots right to windows, no problem.
@jmeyer There is no real check. At the moment we install mariadb on fresh installs but stick to mysql on upgrades (which is set in /opt/fog/.fogsettings) because Ubuntu does not properly migrate your database from mysql to mariadb yet (while Debian has long ago).
@TaTa Well this maybe a bug then if you have two different installs with the same settings and they are acting differently. Its possible that something external to the plugin has changed causing the plugin to act poorly. If I remember correctly the ldap plugin logged messages to the FOG log file, but I don’t remember which one at the moment.
