@ryanxplosion Is it a big deal since you just reinstalled to try Debian?

I’ve had far fewer issues with it.

@Olduser I would use Debian 8. Easier to setup and I’ve found FOG goes on seamless where as Ubuntu fusses some.

Maybe it’s just me, but I’ve had more issues with Ubuntu that I ever have Debian.

@Tom-Elliott Same. I’ve been working on snapins today all day.

@Olduser Right, like @george1421 was saying 1.3.0 will do both for you.

Do you have a spare machine that you can put FOG on? Maybe one of those nice new 9020s That way you can build one and if it works, then you can be on your way and retire the 790 and if it doesn’t, you still have your old FOG server.

I’d be happy to help you through getting the new one setup.

I would suggest that you move to 1.3.0 and the latest RC. It’s going to be much faster and much more reliable that your current setup. A 790 is plenty to run it.

I saw /untitled/ and thought you might want to match the others naming scheme for continuity.

It does work though.

URL is misnamed (page too) I believe.

@Tom-Elliott I am an idiot, I totally misread 3000M.

I have no clue where I got 3MB.

Sorry Tom. Thank you.

This makes things a lot easier.

@Tom-Elliott Okay cool. So do or do not need to change a setting to allow it to be more than 3MB? Sorry, confused by which installer you’re referring to.

I’m trying to do individualized snap in deployment for my network where I have a master base image and then the individual apps that they need are installed via group snap in deployment.

So far I haven’t hit an issue, but I just got started. Is there a way or reason not to increase the snap in size to something greater?

@Tom-Elliott Okay, looks like it’s good now.

Still a couple of the same errors in the error.log, but only 3 or 4 now on each PXE boot and the CPU only hit’s 25%ish instead of 100% now.

Thanks Tom

@Tom-Elliott Sure, will do.

Server

• FOG Version: 1.3.0 RC-20
• OS: Debian 8 jessie

Description

FOG server CPU usage spikes to 100% from apache2. First I thought this was from WOL, but then I disabled that, canceled the image, and tested it again. The CPU spikes to 100% seemingly right before it goes into PXE boot and during until it hits the FOG splash screen.

No images are being deployed out and nothing is communicating with the FOG server besides the initial PXE boot.

[Tue Nov 08 15:10:08.857937 2016] [:error] [pid 23934] [client 10.4.200.150:36655] PHP Fatal error:  Uncaught exception 'Exception' with message 'Invalid MAC Address!' in /var/www/fog/lib/fog/wakeonlan.class.php:54\nStack trace:\n#0 /var/www/fog/lib/fog/fogpage.class.php(3150): WakeOnLan->send()\n#1 /var/www/fog/lib/fog/fogpagemanager.class.php(252): FOGPage->wakeEmUp()\n#2 /var/www/fog/management/index.php(49): FOGPageManager->render()\n#3 {main}\n  thrown in /var/www/fog/lib/fog/wakeonlan.class.php on line 54

I’ve got about 2000 of these sitting in my apache2 log. The image deploys fine and it doesn’t give me an error PC side, but it doesn’t seem right that it’s spiking to 100% on an i5 CPU w/8GB RAM.

Thanks guys

What are you trying to image to?

@george1421 Ah yes, I did read over that one a bit! I finally got it figured out, but I didn’t end up using MDT. Very thorough.

@Tom-Elliott Yep, it’s working extremely well. Thank you for helping me (and writing a piece of code for me!).

@george1421 Sounds great, that’d be amazing! All of the past places that I’ve worked at (I’m in contact with them after I left) will appreciate the write up. They’ve been wanting to get master images rolling at their school districts (one being ~1,000 PCs), but never have gotten to get them up and running.

@george1421 @Tom-Elliott @Quazz Okay, it looks like it worked! Amazing!

You guys are simply the best devs/mods/team ever.

Although I forgot to disable FOG Client in my sysprepped image, I fixed and and will be double testing again. It went through the section without a hitch though.

@george1421 No problem.

That would be nice though. I had to jump through a few threads (which is a given sometimes!) and the wiki page for Auto Installing drivers didn’t seem as robust as the scripts that I had found.

But that’s how progress and the process work. One problem at a time and always improving.

@Tom-Elliott So this goes into fog.postdownload alone or conjoined with the previous script from ntfs-3g -o force,rw $part /ntfs down?

@Quazz My scripts currently:

#!/bin/sh
## This file serves as a starting point to call your custom postimaging scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post download scripts are
#. ${postdownpath}<SCRIPTNAME>

. ${postdownpath}fog.drivers

and

#!/bin/bash
ceol=`tput el`;
manu=`dmidecode -s system-manufacturer`;
case $manu in
    [Ll][Ee][Nn][Oo][Vv][Oo])
        machine=$(dmidecode -s system-version)
        ;;
    *[Dd][Ee][Ll][Ll]*)
        machine=$(dmidecode -s system-product-name) #pruduct is typo, just realized sorry :(
        ;;
    *)
        machine=$(dmidecode -s system-product-name) # Technically, we can remove the dell one as it's the "default"
        ;;
esac
[[ -z $machine ]] && return #assuming you want it to break if it is not lenovo or dell?
machine="${machine%"${machine##*[![:space:]]}"}" #Removes Trailing Spaces
system64="/ntfs/Windows/SysWOW64/regedit.exe" # sloppy detect if 64bit or not
[[ ! -f $system64 ]] && setarch="x86" || setarch="x64"
#############################################
#this is not section necessary needed, it's just to make the path "human readable"
#rather than using osid for filepath
case $osid in
    5) osn="Win7" ;;
    6) osn="Win8" ;;
    7) osn="Win8.1" ;;
    9) osn="Win10" ;;
esac
#############################################
dots "Preparing Drivers"
# below creates local folder on imaged pc
# this can be anywhere you want just remember
# to make sure it matches throughout!
clientdriverpath="/ntfs/Windows/DRV"
remotedriverpath="/images/drivers/$osn/$machine"
[[ ! -d $clientdriverpath ]] && mkdir -p "$clientdriverpath" >/dev/null 2>&1
echo -n "In Progress"
#there's 3 ways you could handle this,
#driver cab file, extracted driver files or both
#so on the server put extracted driver files to match below folder tree
#i.e. Model Latitude E5410, Windows 7 x86 image would be:
#/fog/Drivers/Win7/Latitude E5410/x86
echo
echo "rsync -aqz \"$remotedriverpath\" \"$clientdriverpath\""
echo
rsync -aqz "$remotedriverpath" "$clientdriverpath"
[[ ! $? -eq 0 ]] && handleError "Failed to download driver information"

debugPause
#if you wanted to use driver.cab use this line below.
#i.e. /fog/Drivers/Win7/Latitude E5410/E5410-Win7-A07-KTT4G.CAB
#cabextract -d "$clientdriverpath" "$remotedriverpath/*.CAB" >/dev/null 2>&1

#if you wanted to mix both cab and extracted use these:
#rsync -aqz --exclude='*.CAB' "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1
#[[ ! $? -eq 0 ]] && handleError "Failed to sync cab and non-cab drivers"
#cabextract -d "$clientdriverpath" "$remotedriverpath/*.CAB" >/dev/null 2>&1
#[[ ! $? -eq 0 ]] && handleError "Failed to extract cab files"
#this next bit adds driver location on pc to devicepath in registry (so sysprep uses it to reference)
# remember to make devicepath= match the path you've used locally
#also do not remove %SystemRoot%\inf
#and to add more locations just use ; in between each location
regfile="/ntfs/Windows/System32/config/SOFTWARE"
key="\Microsoft\Windows\CurrentVersion\DevicePath"
devpath="%SystemRoot%\inf;%SystemRoot%\DRV";
reged -e "$regfile" &>/dev/null <<EOFREG
ed $key
$devpath
q
y
EOFREG
echo -e "\b\b\b\b\b\b\b\b\b\b\b${ceol}Done"; # this just removes "In Progress and replaces it with done :-)"

@george1421 said in fog.drivers script will not run correctly in postdownloadscripts:

@THEMCV OK what I think I would do at this point is insert a debug pause after the error generator.

#/fog/Drivers/Win7/Latitude E5410/x86
rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1
[[! $? -eq 0]] && handleError "Failed to download driver information"

debugPause

After the handleError line after the rsync.

Then go back and schedule a deployment to this computer but pick the debug deployment checkbox.

Then pxe boot the target computer. It will print out a bunch of text but drop you to a command prompt. From there key in fog This will single step you through the deployment process. When you get to the point of the error press crtl-C to exit the installer script. This will leave you at a linux command prompt. From there we should be able to check the disk size and what not.

Okay, done. running the command df I get:

Filesystem                   1K-blocks                Used        Available      Use%      Mounted on
/dev/root                        99459               99440              0         100          / 
10.4.200.150://images/        464307200             215944192        224754688    50          /images

I will run @Tom-Elliot’s code and report back.