I’m perhaps a little unusual in that all of my ‘customers’ are vehicle based laptops rather than desktops. Add to this that I’m not allowed to make any sort of connection to the company LAN (which sports very potent network access control anyway) and I have to have FOG on an isolated network.

At home though for my sandpit system like yourself I’m running pfSense on a repurposed Watchguard appliance with it doing the dhcp and tftp stuff.

I really expected that a reboot of the FOG server would have cleared the dhcp leases. We live and learn…

Cheers
Robin

Why does a small crisis only ever happen when you have 200 or so machines to image and a looming deadline ?

Had a ‘brown afterburner’ moment today when my production FOG server (Ubuntu 12.04 LTS ‘Alternate’ 64 bit / Fog 1.2 stable release with FOG doing the dhcp and tftp serving) all of a sudden just decided it wasn’t going to hand out any more IP addresses thank you very much. All the services were running happily and a restart didn’t clear the problem.

It turned out to be that the dhcpd.conf file had a very limited scope - just 25 addresses, and a default lease time of around 7 days. The scope was probably my fault because I’d set the IP address of the Fog server to something daft - 192.168.1.75 instead of something more sensible like 192.168.1.10, but the very odd thing was that rebooting the server didn’t seem to release the previously offered dhcp leases ? Wierd. Editing the dhcpd.conf file to more sensible numbers has fixed the issue.

Anyway, just in case this helps somebody in future…

Cheers
Robin

Hi Tom,

Confirmed, it is now working nicely.

Thanks for your assistance, I can’t imagine ever getting this sort of speedy response even from a paid support contract… you’re a star

Hi Tom,

I’ve just run the update for SVN 2754 and as you thought, no change. Are there any particular logs I can send you that might help in tracking the bug ?

Kind Regards,
Robin

I installed the SVN 2732 release and have now found that when a client starts up a disc surface test session it displays a message “* Unable to find a suitable Storage Node for transfer!” repeatedly. SVN 2749 seems to do the same thing too.

Previous to SVN 2732 installation everything was OK. All of the config settings appear to be as they were before. It’s only my sandpit system so not causing me grief for production.

In case it’s relevant, this system has dualled network adapters as the default interface, set up as bond0, and two hdds in software raid 1 mounted at boot as /images

Any ideas ?

Cheers
Robin

Edit - Sorry, just realised I should have posted this in the Bugs section - apologies, please move as you see fit :oops:

Working nicely on Fog v1.2 stable release, SVN 2094:

Note that we have Secureboot / UEFI disabled and CSM enabled in the bios…

[LIST]
[]Panasonic Toughpad FZ-G1 tablet pc
[]Intel QM77 Express chipset
[]PXE version - default
[]Kernel - default
[]Date November 2014
[]Image type - Single disk, multiple partition (Win 8.1 Ent. 64 bit)
[/LIST]
Cheers
Robin

Most odd, I’ve been using Fog for about 6 years now and have never seen anything like that. Perhaps something went wrong when the database schema was being set up ?

I’d try a reinstall. Failing that over to one of the clever people on the forum

Cheers
Robin

Confirmed, reports are OK now using SVN 2725. I was seeing the same problem as Ray when I tested earlier.

Cheers
Robin

Hi Sher,

Go to Image Management > Create New Image and you’ll see the fields that you need to set. In there there is one called Operating system where you click on the dropdown and set the type appropriately. For Windows 7 (irrespective of 32 or 64 bit) you’ll need to set this to type 5.

HTH

Cheers
Robin

I must be going blind - can’t see any links to a .pdf (or any link in fact) on the first post naaceer ?