Chad

Hmmm, I'd think you would have to mount an external share and change the path to the mountpoint. >This Page< goes through the process of adding a second HDD and mounting /images on it. You should be able to re-use the latter part of the process to automount to a share. Chad

Is the node the "Master" for your storage group? According to the forums, multicasting always takes place from the master node >Link to post<

Thanks for that, I'll stick to our current way of having the deployed image sysprepped just the once.

Rather than deploying to each hardware type, installing drivers and re-sysprep/upload again, we identify which drivers are required and add them into the driver store in main "clean" image with: pnputil –a \*.inf We then sysprep and upload this to a deployable image. We're coming from XP ways of working where running sysprep against an image multiple times is generally accepted to be Not Good - it may not be a problem under W7 but this has worked for us so far. Chad

Glad you got it going! The error codes reported back in the log could be definitely be clearer - it's not exactly an "Unknown error" when you can google and it tells you it means it's a logon failure. I'll perhaps submit a patch to clarify the "unknown" ones. Note that if you want to increase the size of the fog.log file throughout your entire estate, you can upload a tweaked config.ini to the FOG server under FOG Settings/client updater and the clients will pull it down as an update. Cheers, Chad

It took me a few tries to get it working too but I have no issues now. I updated the FOG wiki a while back to clarify the format of the fields (e.g. username needs to be domain\username, domain name needs to be in FQDN format) so if they all look good, the next port of call would be the fog.log file. Many of the errors trapped in this don't have a friendly text explanation though. I found a few more explained after searching for "JoinDomainOrWorkgroup" which is the call used to join the domian. Have a look at one of the replies near the bottom of this post for an explanation of a few more of the numeric codes. Good luck!

Do you have anything in the OU field in FOG? If it's populated and a computer object already exists for that PC then you'll get an error on joining the domain. It works fine if there's not already a computer object though. If you look in the fog.log on a failing PC it should give you an error code. You might need to increase the log size first as it over writes itself quite quickly - change the entry in c:\program files\fog\etc\config.ini If you're getting an error 2224 (this is what you get when the OU field is populated and a computer object already exists) then there's a fix which I linked to a few posts above. HTH... Chad

I've used RIS, WDS and FOG but not MDT/SCCM. I'd also say FOG is the better of those I've tried - it's far more flexible and not having to have physical access to the target PCs (provided you can WOL them) is great. We've a single XP image working on about 20 different models from 3-4 manufacturers. The base image has the standard software installed and this is supplemented via snapins or GPO deployed software targeted to specific groups of PCs. Currently building a W7 image which is also working nicely across various models once you import any necessary drivers into the driver store on the master image.

Have you had a look in the /var/log/apache2/error.log - any pointers in there?

I can see exactly where Bart21 is coming from in asking if you selected a Normal or Storage Node install - Storage Nodes present you with a blank screen from the web browser. FOG will "remember" which install you initially chose though so it may be worth checking the content of your /var/www/fog/management/index.php from the console of the server. If it contains: Then it thinks it's a storage node. The "remembered" settings are in /opt/fog/.fogsettings so you can delete this file prior to a reinstall to ensure it asks all the questions again. You don't necessarily have to remove your MySQL root pw - just ensure you enter it into these files after the fog install: /var/www/fog/commons/config.php (values MYSQL_USERNAME and MYSQL_PASSWORD) and the services file: /opt/fog/service/etc/config.php (again, MYSQL_USERNAME and MYSQL_PASSWORD) It's worth sticking with as it's a great piece of software when up and running. Chad

Something else to consider - if your drivers are in the form of an installer (with a silent option) you couldlook at the possibility of deploying them as a FOG snapin. You can assign the snapin to a group containing the required target model/hardware type and they'll get installed automatically once imaged. The host search facility has been extended in 0.30 to include some of the hardware fields to make creating such groups easier. There's also a patch for 0.29 adding the same functionality, and for showing some of the hardware fields on the host list page.

The restart is coded into the hostnamechanger.dll You can edit and recompile this (instructions are on the FOG Wiki - it's the same file you change the encryption key in) - there are 2 instances of "restartComputer()" which you'd want to look at. Chad

I submitted a fix for this to the FOG site: Fix for 2224 Error when joining Domain This involves modifying the hostnamechanger.dll file. This is the same file you modify with your password encryption key, full instructions or how to edit this are on the FOG wiki.

Also check out "MySysprep", I use this in conjunction with sysprep driver scanner. This handles different HALs which makes a universal image that much easier to deploy to differing hardware. What I do is image up the master image before it's ever sysprepped every time it's updated, then copy in the "sysprep" folder containing all the drivers from a network share and run sysprep driverscanner and MySysprep. Once this finishes and shuts down, image this up as the deployable image. The sysprep folder gets deleted once the deployment/sysprep process finishes so the drivers get removed. For new hardware we deploy this image and see what hardware is missing. I then do a "search in files" for the PCI/hardware vendor codes in an extracted copy of all the drivers from driverpacks.net and add the appropriate driver folder into the sysprep/drivers folder on the network share. Then to update the deployable image, image down the master image, copy in the updated sysprep folder and re-run sysprep driver scanner/mysysprep to update it to support the new hardware. Once done, upload this as the new deployable image. It may seem a bit unnecessary to maintain 2 copies of the image (before and after sysprep) but I prefer to keep my master template as clean as possible (i.e. never sysprepped!). Chad

As morganw said, I'd agree it's likely a kernel issue. The latest one seems to have added framebuffer support - one model I have now displays the fog stuff in a small corner of the screen which is set to a high resolution. There are also a lot of "error" messages which fly past which I think can safely be ignored, though are a little worrying at first. I think they're to do with probing vendor specific hardware which complains when it sees another manufacturer's system. Roll back to the last 0.29 KS release and you'll probably be OK. I'm not sure if the new kernel provided the multi-CPU detection for quicker uploads, so you may lose this enhancement.

I've worked around the issue by making the following changes: Create an entry in the SQL table globalsettings called FOG_PXE_BOOT_IMAGE_UPLOAD , setting category "TFTP Server". this will now appear on the FOG Settings page. I gave it the value fog/images/init030.gz - after having copied the init.gz from the 0.30 release to /tftpboot/fog/images/ with this name. Note I have the init.gz from 0.29 as the "default" init.gz file in this folder. Then in /var/www/fog/commons I edited functions.include.php and found where it creates a PXE upload job. Instead of getting the init.gz filename from FOG_PXE_BOOT_IMAGE I told it to use FOG_PXE_BOOT_IMAGE_UPLOAD This results in uploads using the init.gz from 0.30, and downloads still use the init.gz from 0.29. Result: Downloads are nice and fast using the 0.29 init.gz and 0.30 kernel, and uploads are nice and fast using pigz and the 0.30 kernel. Hacky, but it works - and until the download speed issues with the 0.30 init.gz are resolved it'll do for me. Cheers, Chad

The 40min one I had was a core 2 Duo E8400 @ 3.00GHz in a new out of the box HP DC8000. Even the aging old GX520s were only taking 8 mins or so! My first thought was the kernel too, seeing as it provides the NIC driver, but I'd already been using the 0.30 kernel on FOG 0.29 prior to upgrading and it was the fastest combination I'd used thus far. I had a quick scan through the fog script in the init.gz and the only changes I could really see related to using parallel gzip client side when uploading - the download stuff looks unchanged. Strange... and odd that other folk have seen no such issues - but as you say, that could be down to client side CPUs.

Morganw, As per previous messages I've already rolled back the init.gz to the 0.29 version and am still using the FOG 0.30 kernel. It's the new busybox init.gz which causes the speed issues - the 0.29 version is much faster. But the speed problem doesn't seem to affect all users...

DISTRIB_ID=Ubuntu DISTRIB_RELEASE=10.10 DISTRIB_CODENAME=maverick DISTRIB_DESCRIPTION="Ubuntu 10.10" I should have stayed with the LTS server edition I think.

What OS are you running FOG on? I wonder if the slow speed with 0.30 is distro related...

What speed NICs do you have, Cools? I'm pulling down 6Gb in under 2 mins on Lenovos, same image takes about 5min on Dell GX520s (all 1Gb NICs). With the 0.30 upgrade, these became something like 8min and one model (I forget which) went to nearer 40mins Chad

Hi John, I'm on Ubuntu too: Look in /tftpboot/fog/images/ and you'll see a file called init.gz rename this to something else: (these commands assume you have appropriate access rights) mv /tftpboot/fog/images/init.gz /tftpboot/fog/images/init030.gz Then copy in the init.gz from your 0.29 version. If you still have the 0.29 archive decompressed on your Ubuntu box it'll probably be in your opt/fog-setup directory: cp /opt/fog-setup/fog_0.29/packages/tftp/fog/images/init.gz /tftpboot/fog/images/ After I did this I got my download speed back. I didn't bother downgrading the kernel as it seems OK with the 0.30 one (though it's quite verbose in spurious error messages which can seemingly be ignored). The only downside is slower upload speeds again, but I'd sooner have quicker downloads as we do far more of those! HTH, Chad

I've found deploying images to PCs with 0.30 is a lot slower than when I was using 0.29 and the latest (0.30) kernel. Has anybody else played with this yet? After some experimentation I replaced the 0.30 init.gz with the one from 0.29 and my image times are really fast again, so it's something to do with the new busybox init.gz but I've not had time to hunt it down further yet.

Ours is about 3.5Gb on the server, 7Gb ish when on the clients but it's just XP, Office and some stuff like acrobat reader. The image is pretty universal, running on various models of Dells, HPs and Lenovos - desktops, laptops and netbooks. The drivers are added in specific to the models and put in the sysprep folder so they're deleted once sysprep has done its stuff.

I think the auto-registration was dropped as laptops connected via wireless would register the wireless MAC address as the primary MAC. When it came to PXE booting, the LAN MAC wouldn't be registered against the device so it would appear as an unknown client. The new version has the facility to capture additional MACs and store them against a single host, but requires that registration is done via PXE to ensure the LAN MAC is captured as the primary one. If you have OCS inventory I have written a FOG plug-in to import hosts from the OCS database, otherwise a simple script to capture the MAC address and hostname would be all you need to create a csv file to import. Chad