@Chris-Shipley said in Manually copy image between FOG hosts:

but the graphic still shows /images as the Image Path and FTP Path.

You would just update those via the web interface. The installer doesn’t touch much of anything in the DB, it’ll add a new node for you, and make sure you’re node’s FTP credentials are correct, that’s all it does to the DB for an existing setup - and of course it updates the db schema if necessary. It doesn’t do anything beyond this because there’s no way to know what the admin’s intentions are, or what unique setup there may be. For instance, you might have 3 or even 12 nodes defined all on one server, all with a different path. Imagine the disaster if the installer was programmed to just ‘correct’ all of those for you…

What @Jbob said has been outlined here for a few months: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_of_hosts_when_building_new_server

That’s probably one of our more important wiki articles.

@Joe-Gill said in Windows 7 Sysprep Blackscreen:

@george1421

Beautiful! Thanks!! I’ll give that a try. I did find a good wiki on sysprepping with fog but it didn’t mention disabling service.

Cheers,

Joe

Please post that link so I can work on that article.

#wiki

If you can script it, snapins can deploy it generally.

That said, group policy would be the better choice. Snapins fill in the gaps that group policy doesn’t do, or doesn’t do well.

For me, I use snapins for one-time script deployment and for software deployment. I use fog for these things instead of group policy because with fog it’s aggressive instead of passive, and I can see progress easily in task management, and to not clutter my group policy needlessly.

Of course snapins can do much, much more. What you use them for is up to you.

@george1421 said in Fog server offline:

cd /image/dev should be cd /images/dev

If you are positive you are in /images/dev then key in rm -rf /images/dev/* and it will purge all files and folders in that folder. Then run the df -h command again and see if you have any free space on the /dev/sda1 partition.

After running George’s command to delete everything in that directory, execute these commands to recreate the .mntcheck file that is required in that directory.
touch /images/dev/.mntcheck;chmod 777 /images/dev/.mntcheck

I downloaded Ubuntu 12 Server x64 and am installing it on a VM right now.

I’m only doing this because I thought it’d be fun lol.

It always takes me a minute to use the basic interface in the server edition of Ubuntu to setup volume groups and partitions, and to ensure there’s a separated /images partition.

I’ll see how the trunk install goes after it’s installed.

This was an idea I had rattling around in my head for a few weeks now.

If we could raise enough cash initially, we can buy used devices for select people to test with (devs, mods), and once we’ve collected all the information we need, and have made all the adjustments we need, and created all the documentation we need, we could just sell the device at the same price a couple weeks later and have the cash go back into the pot for another device.

@K.Hays Notifying a few folks that might be able to help.

@Tom-Elliott
@Sebastian-Roth
@Wolfbane8653
@cspence

OP had AntiVirus installing inside SetupComplete.cmd before the FOG Client was re-enabled and started. The specific AntiVirus installation caused a reboot, which left the SetupComplete.cmd un-finished, and therefore all these other problems happened.

Consider building a snapin for the AntiVirus, which will auto-queue for any computer that is told to image and has the snapin associated with it, and the snapin will deploy after imaging is completed.

@cschneider.tech For the record, the instructions in the wiki do work, many people have used them before.

Also a side note - DNSMASQ will only work with BIOS type firmware.

Many machines today are shipping with UEFI enabled by default. UEFI type firmware is indeed the future, but other technologies that are built around firmware haven’t totally caught up yet. DNSMASQ is one of them.

If you require UEFI network booting, I’m afraid you will be forced to change your DHCP setup. If BIOS will work for you, then you may use DNSMASQ just fine.

Are you using the new fog client?

@kwetiaw I’m linking threads that deal with the Surface Pro 4 here for you to read through. All of the below threads are marked as solved. As George already said, I’d like to compile all of this information into a single #wiki article, but I don’t have a SP4 to test with. I will be out for several days after tonight.

https://forums.fogproject.org/topic/6515/surface-pro-4-won-t-get-to-registration-menu

https://forums.fogproject.org/topic/8181/surface-pro-4-image-capture

https://forums.fogproject.org/topic/7660/surface-pro-4-on-7977

https://forums.fogproject.org/topic/7353/surface-pro-4-unable-to-image

https://forums.fogproject.org/topic/8323/several-problems-with-surface-pro-4

@Sebastian-Roth said in Ubuntu 14.04 LTS, Fog 1.2 multicast not working:

I am just wondering which interface you specified when installing??

FOG 1.2.0 doesn’t change the DB’s interface settings from the default eth0, even if you specify something different during installation. FOG Trunk does though.

I’d say 8 hours.

@Tom-Elliott The Web Interface should not allow a value beyond the maximum to be stored.

In the end - really, truly - it should be whatever the Admin wants it to be. It’s integers on a monitor - what does it matter to anyone else if I want mine to be 30 seconds, and John Doe wants his to be 8 hours? I don’t care about what John Doe is doing, he’s a sys-admin doing what he thinks is best for his environment, for his use case.

I would say no more than 8 hours allowed for any setting - because beyond that and you’re approaching tasks not getting done by the next day.

I say - set a maximum of like 8 hours for each field, but set the defaults to something reasonable, I like what they are now - the defaults are reasonable.

@kwetiaw if you would please be so kind, we want some more information about that adapter.

idk if that USB boot stick you have can do debug or not - but if it can or you can get to the CLI somehow, please run this command and give us the output:
lspci

That will tell us what exact chipset that adapter is using and will be extremely helpful to us and others.

@RipAU said in Apache2 for fog vhost - failed - Trying to update Trunk:

These are the files that after the update the server complains about though… ?

Yes, they are. Here a while back, the locations of these files were changed. Used to be it was /opt/fog/.ssl I think?? And now it’s /opt/fog/snapins/ssl and I’m wondering if something went wrong with the moving around.

Do you know what version of fog trunk you came from? I’d like to try to replicate if I can.

@VincentJ said in AD Join Not Functioning (Code 87):

Do you have windows 10 machines, with the anniversary update applied, running with successful domain joins? (Version 1607)

We’ve been using the new fog client since Win7.

We’ve used it for Win Vista, Win7, 8, 8.1, and Win10 Enterprise and Win10 LTSB. It works fine.

A large portion of FOG’s community base uses the new client to join Windows to a domain, it’s probably the largest selling-point of the fog client. It’s solid. 19 times out of 20, it’s a configuration issue - like how you’re configuring the settings. the other 1 out of 20, is Active Directory issues or DNS issues or image issues. I don’t have enough fingers and toes to count how many threads the forums have had about domain joining problems, and were due to the above mentioned issues.

I have been looking at the domain join scripts, do you use the netapi32.dll NetJoinDomain because the client is unable to run Powershell commands?

The client uses that because that’s how it’s done on windows, this is how windows does it when you join manually.

---

Where is the host you’re trying to join? Is it on a different subnet? Can you just elaborate more about the setup, maybe something will stick out? Also - just experiment. Does domain joining not work in just one location? All locations? For a certain image? On a certain switch? On a certain subnet? On a certain version of Windows?

@george1421 I prefer /etc/sysconfig/network-scripts/ifcfg-xxx now after I learned more. Before that yes I clung to the cli graphical tool for dear life.

@mageta52 You’re overcomplicating it. Set a static address for the fog server prior to installation. When you put it on an isolated network after installation, it will retain that IP, it will continue using that IP - and your isolated network will use the same subnet mask and range as the one it was on prior.

FOG sets a ton of settings based on the IP - it’s written in many, many places during the installation. While it’s possible to change all these (and I’ve done it before), I wouldn’t recommend it to the newcomer.