@leonjv The FOG 1.5.9 installer was not smart enough to check for an exiting DB and tried to use whatever it considered right. This was fixed in the latest dev-branch version (github commit). You can wait for the next release or use the dev-branch version.
@george1421 Hi, I`m sorry , i have attached wrong info and screenshot with video. It was a result of my attempts to boot from .tgz ubuntu which i found in an old sysadmin files, which very like a foreman tools.
@thebaz The number of times someone has upgraded the OS of their FOG server and broken FOG is a lot. So many that it prompted me to write this article about five years ago. The article is still valid. My advice is to not upgrade the OS of your FOG server, unless it’s in a VM and you take a snapshot before hand. If it’s not in a VM, your safest choice is to migrate.
@george1421 Hey George, sorry I didn’t reply yesterday. I did get everything running successfully. Captured an image and deploying image right now! Appreciate all your help! Not sure how to mark this is as solved but its working!
Actually I was wondering if it was feasible to install the client before capturing/deploying
That is how you typically would do that in the windows world. From a windows perspective the fog client is installed then the service is set to disabled. At the end of the winsetup process windows calls a batch file called setupcomplete.cmd that is used to issue the commands to the fog client to startup on every reboot. The issue with windows is as soon as the fog client starts it will start executing its tasks. If windows oobe/winsetup is still doing their bits the fog client may reboot the computer without oobe being done, thus creating a botched install. Linux first boot is nothing like windows, so it may be OK to leave the linux fog client configured to auto start at each reboot.
This is a mode for partclone when it can’t determine the format of the disk, this is a default mode when no other disk format filters exist, such as with LVM. In linux terms partclone uses dd (disk dump) format to image the disk. This is the slowest and largest format since it copies all disk blocks. Partclone might change to this format if it detects and encrypted drive where it can’t read the partition information because its encrypted.
That was totally it! I was confusing myself with the /images directory for tftp. After changing the command to match the /tftpboot directory everything works perfectly. Thanks for your help!
Having to copy the image to a machine and back again would be an extra unneccesary step since we already have the image ready to go.
Yeah I can see what you mean. Understood.
If you want to use FOG for this (e.g. because you like the multicast feature) you will need to start investigating the image format and see if you can make it work. We are open to help you find the right track but it’s up to you to actually figure it out.
FOG supports so called RAW image type with uses partclone.dd not (plain) dd. While I have used both extensively I never tried to deploy an image with dd that was created with partclone.dd or vice versa. Don’t think it’ll work but I am not sure. If it doesn’t then you might hack the bash script doing the deployment to just use dd (code reference).
@untouchedwagons Well I just copy&pasted this stuff. Now looking at the parameters again I think this part is not right: ... nfsroot=/${fog-ip}:/images/os... (remove the slash after the equal sign I would say)
