@smccloud Ok as long as you have it going, but seeing the error probably would have made me suggest that you install the dev-branch which supports debian 11 and ubuntu 20.10. But working is working…

I still think there is value in upgrading to the dev-branch to get support for imaging 20H2 and later images. The dev-branch is on 1.5.9.114 or later as of today.

I would also recommend that you install the latest FOS Linux kernels 5.10.x that is done under the Web UI->FOG Configuration->Kernel update. Just be aware if you update the kernel now and then install 1.5.9.114 you will need to redownload the 5.10.x series of kernels.

@george1421 Found the fix and got the servers updated. Thank you guys for your time!

@george1421 No worries, I was just curious! I think you’ve given me all the information I’ve needed. I appreciate your response time and assistance!:)

@luiztpd The rebuilding ipxe tutorial is here: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

Make sure you have the latest FOS Linux kernel -> Web UI->Fog Configuration-> Kernel update. You will want 5.10.x series of kernels for both x64 and x32 systems.

Lastly you can update to the dev branch (suggested if you need to deploy Win10 20H2 or later versions of windows) to get the fixes for those OS’) all you need to do is change into the git repository you downloaded then do the following:

git pull git checkout dev-branch git pull cd bin ./installfog.sh

That will update your fog install to the pre-release version of 1.5.10. That release is stable and will most likely be what 1.5.10 will be released as.

Now when 1.5.10 is released you will need to switch back to the master branch this way.

git pull git checkout master git pull cd bin ./installfog.sh

@ericdelpozo OK I understand your troubles and your idea.

I have one question. Are these computers both bios (legacy) and uefi or are they all bois or all uefi. uefi based computers are easier to boot via usb. But we can make it work both ways.

@george1421

Thanks for some advise what to look and search for. I will dig into CCTK for sure. I unserstand there are many things to do and there is no time 🙂 Good Luck and Thanks !!!

Thanks @george1421, will look into this especially the USB to ethernet (will have to purchase though).

@george1421 I will go ahead and start off with changing the root and the admin passwords. Those are the two that I was really wanting to change. Thank you for your time!

@george1421 said in Does FOG use or install the log4s?:

I do see two CVE alerts from 2018 and 2006 regarding log4net

Thanks George for bringing this up. We might look into updating or even removing log4net from the fog-client.

@george1421 That worked! I added the two additional tables to the export command and the “test” host was imported.

@brakcounty said in Newly captured images are being owned by "root" instead of "fogproject":

Well all of my other images in /images are owned by fogproject:root. If this isn’t a problem then I’ll leave it alone.

That’s done when you re-run the FOG installer. Just don’t worry about it. They’ll work either way.

@pamadmax Its great that you have it solved. Intermittent communications would also cause this pattern.

Just to clarify the point a bit about dual dhcp servers. If your fog server is on the same imaging network and its “the dhcp server” for your imaging network, then you don’t need a dhcp-relay service listening on this subnet. Actually you should clearly not have it listening on this subnet. You can have the dhcp-relay service on your router, that’s fine, but not listening on the imaging network’s vlan.

The issue is this, if the dhcp-relay service IS listening on the imaging subnet, the relay service will relay the dhcp request to your main server. With the FOG dhcp server also listening there is a chance that your pxe booting computer will get two OFFERS. One from your FOG server and one from the dhcp-relay service as a proxy for your primary dhcp server, hence the comment about 2 dhcp servers.

You have it worked out, so that is all that really matter here. Good going on finding the problem. I’m sure that misconfiguration on the LAG trunk was causing other strange issues on your network too.

@Pilar Please post pictures of the configuration in the web UI.

@Pilar There is no place to check. Re-running the installer script should correct all the permissions for you. Though you seem to have modified your storage setup a lot now and I am not sure the installer script will take care of this.

Of which directories do you want to know the permissions?

Same here, please give this topic a proper headline!

@Pilar You probably want to add this to the other topic: https://forums.fogproject.org/topic/15911/without-master-node

Why several postings with seemingly the same question? As well you might change the heading of this topic to match it’s contents!

@sigit FOG is a one to many bare metal imaging solution. I don’t think that fits your requirements about updates and patches. PDQ Deploy and Inventory might be a good fit for that bit. FOG does have a snap in function (application deployment) that can be connected to image deployment, but its not really a stand alone solution.

With inventory it can scan for installed software and then you can create policies and have pdq deploy enforce those policies.

Also you could look into chocolatey https://chocolatey.org/ for patch/ application deployment if you wanted to stay in the FOSS user space.

In any case for a non-domain environment you will need to have a consistent admin user account across all non-domain computers for the above solutions.

@mikael1909 While I haven’t tried these specific boot disks. I don’t read russian at all, but it looks like these boot images are windows pe based. You should be able to get them to boot.

What have you tried so far?

What errors do you see? If you post a picture of the error it might help debug the problem.

@george1421 thanks for the quick answer.

I’m aware that the power of FOG is in the multicast deploy. But I have to say that I tested it with 25-30 capture tasks in parallel, and if you have the hardware+infrastucture, it works like a charm 🙂
I already have the registrations, image definitions, groups etc., but I won’t do it on scheduled basis, only on manual basis.
My only problem is the lot of clicks which I have to do, if I want to do it manually:) That’s why I asked this question here.

I will have a look at the Powershell API, it will probably/hopefully solve my problem 🙂

Thanks!

Yepp, I have the same problem, I see the status only after a few minutes, when the text gets “streched”. If there is a solution, it would be nice to know:)

We have an “easy” solution for this. We are using a NAS (a Syno in our case) to store the images, and we enabled the recycle bin. When the image is overwritten by FOG, the old one goes in to the recycle bin of the Syno (#recycle). Depending on the filestore size(we have around 32TB), number of hosts, size of the images and the size of the recycle bin, you can have the “history” for a few days.
The images are renamed in the #recycle of the Syno(e.g. d1p4_1.img or d1p4_5.img) and if you need an older image, you just copy it back, and rename it.(e.g. d1p4.img )
We can go back in this way, for 5-6 copies, in your case it would be 5-6 days.
I hope it helps.