@fry_p Your current efforts has not gone to waste. When the other method is proven, you will just move your patched fog.mag.reg to the fog server postinits directory and add in the postinit scripts to copy it over each time. What you have created to day will work just fine moving forward, you just won’t have to unpack and repack the inits after each change.

@darkrelic said in installing now everthing is updated Failed!:

@george1421 that solution works thank you

(Lucky guesser) == George 😉

@george1421

Thanks ill create a checkpoint before i do the upgrade any way but ill give it a go today.

thanks

@Junkhacker Thanks!! I do a lot of monkey-see-monkey-do stuff. So I assume I did what others did to make this work. I applied the chmod -R 777 stuff as well. I checked the NFS services and it’s running.

I can’t say I am troubleshooting because I am applying “fixes” I found through this tread. i know, I know, that’s scary.

I will follow your advice and create a new thread. I suspect some will point me to this thread for resolution but let’s see what happens.

Thank you Tom! Good to know! It is okay for me 🙂

@Wayne-Workman I suspect this problem happens during “reinstall”.

as a root user I can get in but I need to enter root before the command

also from 1.3.0 to 1.3.5

Hi Andreas thanks

Is there a Tutorial somewhere. At least i want to clone into VirtualBox, so i only need a vdi-file from the img-file.

@Tom-Elliott
No, no need an intermediate switch. If I turn-off spanning tree, yes I need to put a intermediate switch, but if it’s on, it’s working.

@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.