@riko with this error, it appears to be a software error on the target computer’s hard drive. Clonezilla and FOG uses the same disk cloning engine called partclone. I found this answer on the clonezilla site: http://drbl.org/faq/fine-print.php?path=./2_System/108_bitmap_free_count_err.faq#108_bitmap_free_count_err.faq

It says:
"You should make sure the file system integrity is OK before you save it as an image, i.e. the file system is unmounted cleanly. If you want to check and repair the file system, you can run “fsck” on GNU/Linux or ‘chkdsk /f’, ‘chkdsk /p /r’ on MS Windows. For GNU/Linux file system, e.g. ext4, reiserfs, you can also check option “-fsck-src-part-y” when you save an image. "

FOG will only replicate with storage nodes in its group. Each group must have a master FOG node, and then X number of storage nodes.

If your storage node is in a different storage group than your master FOG node no replication will happen.

Use the replication controls on the images to control what gets sent to the storage nodes from the master node.

You will probably want to use the location plugin to direct the appropriate clients to the storage node vs the master node.

Problems resolved. Capturing and deploying images works successfully. I believe I had a bad image and mismatched settings (UEFI/BIOS). Thank you for your input Wayne/George, it will definitely help me moving forward.

@george1421 After further troubleshooting, we determined that the issue was due to a bad sector on the hd. Moved to a different HD and the system worked like a champ. Thanks George for assisting in finding that little blurb about faulty sectors during the timeout

@george1421 The switch we were using also had a network connection connected to it. So when I pulled the connection, instead of using the IP address we used localhost.

@Tom-Elliott I’m afraid this hasn’t worked. Still getting the cannot remove old partition error.

thanks dude 🙂

@Tom-Elliott 0_1490369943984_upload-3da12f01-d939-4c92-ab1b-f05b259561fc

Here is the box I missed if anyone is following

@Tom-Elliott
yes

Take your time, as I have learned to solve it for me is not urgent. You told me if i think it needs further investigation, let it be posted in separate thread, so i did 🙂

@michaeloberg use the Git method here to upgrade: https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
No it shouldn’t mess up your current installation. If you want it to break your current setup, just let me know and I will show you how.

Ok guys : it’s solved!!!

The issue was due to the chipset selection…
I finally tried on a default VM hosted on an Ubuntu for testing (maybe it was the virtualbox /windows version causing the issue) and it launched the fog pxe environment.
So I changed to the same settings on my windows host and that was fine…

I hope it would help if someone has the same situation.

Thank you all!!

I installed the last stable version of fog (1.3.5) and find it awesome: the improvements since the 0.32 are really great!!

I don’t know (and don’t want) to make software developement but I’d like to help about french translation (if you need it) when my windiws 10 migration will be done. Tell/contact me if you want 🙂

Thread solved.

Found the issue.

The maxClients field was being scanned for. This only allowed a “maxClients” of between 1 and 9999. The idea for this range was to get nodes that were not set to 0 max clients. I was trying to make the sql handle the return, but this would imply some form of array to search for. I just moved the check to look if it is less than 1.

Here is an better pic… Yes I will update tonight.!

0_1490310548304_rsz_20170321_135330 (1).jpg

@george1421 I think we can mark this as solved. This conditional test works very well. I ended up using the MAC address for this and then creating a separate menu for each iso.
Example: In fog.local parameters
iseq ${net0/mac} f4:4d:30:65:23:94 && goto fog.Ubuntu-16 ||
iseq ${net0/mac} 00:30:1b:82:d2:d2 && goto fog.Gparted ||

Thanks,
Scott

@oraniko sweet. See just a little knowledge (where to look) grants great power.

We keep “scheduled” tasks listed so you have a sort of record of actions and their “activity” from a scheduled standpoint.

@george1421 I have ran this like before start installation. mount -o remount,exec /tmp