@SlimJim Did you get to test this on a release candidate installation? Should be working there already.

I’d say adjust the /opt/fog/.fogsettings file and let the fog installer handle configuring DHCP (It is solid, I’ve done a lot of work on that part of the installer). You’ll probably need to install dhcp-server before hand though.

@tom-elliott said in FOG, what can and can't it do?:

I feel I must add the primary reason you won’t see a “central repository” for OS images lies down with the very simplistic case of licensing.

If there were a “central” repository, um, can you imagine the legal issues that would no doubt-ably ensue? Managing a repository itself would be extremely difficult, but licensing - especially in commercial OS’s - would be a nightmare.

Ultimately, while it would - from a purely technical standpoint - be possible to create a (very very very) generic set of OS’s that could be used by many, this would not come with your organizations set of software. (Admittedly vague in that you could automate some of the software layout with snapins.) This again is purely technical. Yes, it “could” be done. No, it most likely will not be done.

I could, however, understand central repo for OS’s that don’t require licensing (only one I can think of would be linux though) but even then you’re dealing with one person’s preferences for the layout of the OS vs. what might actually be required and/or more suitable to your environment.

OS-Images - generally available and upgradable with snapins (kinda) is the idea behind docker.com…

@wayne-workman hyphen was needed for legacy client

Ok thanks.

You could do something like a batch file

@echo off reg add xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Then add that into your snap ins and deploy it!

Thanks.
It is solved.

@jjcjr With your concerns then the remote site will need to have a stand alone storage node, just for the reason you cited. If the master node is unreachable then imaging isn’t possible.

What you are asking for is not currently available in fog (what I’ve been calling a multi master node setup. I’ve personally had a feature request in for this for over 2 years). The developers have just added a restful api interface that was on the roadmap to provide what you are asking. But its not there just yet.

With your current setup, you only need to export from the master node and import into the remote node when you have a new image definition. If you update an existing image definition, the new files will be replicated to the remote fog server and nothing else is needed. This is how I run my multi-master fog setup.

@predator On the web console, what does it say is the assigned image for that host?

@wayne-workman Yeah, I was trying to address an issue I was seeing the wrong way. It would be much cleaner to just do a split horizon dns to address the issue.

@bendrajamss Why did you post here? How does this relate to fog?

@george1421 said in Error for create image:

OK so the question is what is in the 4th physical partition on that hard drive. FOS is reporting the structure is incorrect. If you take a similar system and try to capture it do you get the same error?
My idea is that this hard drive has a problem in its partition layout. The operating system doesn’t appear to have an issue with it, but when its cloned partclone isn’t happy

I did not have time to do this test
I will do it Monday and I will inform you
Thank you and good we

@tom-elliott Thanks Tom, this said i will give 1.5 a try.

Regards X23

@Rafafele Change the image type of that image to “Multiple Partition Image - All Disks” (ID 3)…

Well you can start with the wiki page: https://wiki.fogproject.org/wiki/index.php?title=Include_any_ISO_in_the_FOG_Bootmenu

And here is an older document, but the concepts still apply. There is no need to hack the php code any more since you can edit the pxe boot menu inside the fog web gui now. https://wiki.fogproject.org/wiki/index.php/Advanced_Boot_Menu_Configuration_options

@russkil said in Is there a control list of what you can expect fog to do?:

One question that does spring to mind tho is with fog does it change the host name of a machine in fog would that take effect at the time of boot or at the time of reimaging?

The FOG Client (if installed) will also enforce hostnames. If you change the hostname in the web interface, the FOG Client will make the change on the remote system. If the hostname on the remote system gets changed, the FOG Client will re-set it to what you have defined in the web interface. If the system is also domain-joined, the FOG Client will also rename the computer’s object in Active Directory too.

@Bob-Henderson Thanks for the tip, I am sorry to have nothing to offer but we are a startup wich means that every single penny comes out of our pocket and things are going bad down here in Brazil so… I appealed to the “ecofriendly” therm because it’s the very core of our startup and how FOG is a linux-based project I thought it would be in the same ecosystem where people are used to help each other for some cause or sympathize for the idea and etcetera, explore your technichal habilities was not my intention.
I will take a look on theese other projects, thank you again.

The iPXE boot loop is kinda strange. I think I’ve never seen this! Why was default.ipxe missing in the first place. How did you get it back? Can you please post the content of that file here in the forum. You should find this text file in /tftpboot/default.ipxe on youf FOG server (192.169.250.100).

@Tom-Elliott Yes

@Jarl2.0 If you are using zStd capture speed will be much slower than deploy speed. That is the nature of the compression tool. With gzip you don’t get as good of compression ratio or deploy speeds, but capture and deploy are similar in speed. For Zstd 11-13 is probably a pretty good range to stay in.