Posts made by ArchFan

@Tom-Elliott Sounds good Tom, just let me know when you’re ready and I’ll connect you. I don’t think we’re imaging anything for a while - we just deployed a few dozen replacements

That indeed seems odd. I’ve tried with and without the Debian updates, neither seemed to have any effect on the 500 error either. If you have any time in the near future, I can get you connected if you want to take a look. Otherwise I’ll just revert again and settle for the older version

So I’ve attempted to update to the latest git version twice (different versions) since starting over with a new VM. Unfortunately each time I update, I go back to the HTTP 500 error. I reverted to a snapshot the last time, but I’d really like to apply the latest updates. Any suggestions?

Apache logs attached[ FogApacheLog.txt

I ended up just creating a VM, moving the .fogsettings, postdownloadscripts, and driver files to the new VM and then uploading an updated image. It needed virtualized anyway so I could free up the hardware for something else. Thanks for the help guys

@Malos No, it was just blank

@Wayne-Workman Here’s the contents of both directories

@Wayne-Workman Alright. I do have a backup that would probably at least get us close to the current setup. I need to virtualize it anyway, so I may just re-create the entire server from scratch and copy the files I need. Maybe if I just do a Debian 8 install, copy the .fogsettings file, postdownloadscripts, and image that’ll be a quicker job. I’ve just been doing quick images, so we have no hosts in the DB other than the VM I use to upload images

I can get to the default apache page if that helps any. Attempting to go to the <ip>/fog/management page, it tries to redirect to the schema updater which fails to load

@Wayne-Workman Just checked and both are running. I also restarted the machine too with no effect. It’s Debian 7 x64. I haven’t made any other changes other than the FOG update

The forum keeps rejecting my log post, classifying it as spam. I’ve attached the logserror.log access.log

I upgraded from SVN 3783 to the latest SVN today and the web interface ceased functioning after the update - It’s trying to get to the schema update page, but it’s blank. I then updated to the latest git release, but it had no effect on the issue. It looks like it’s an HTTP 500 error. I’ve tried multiple browsers and clearing cache, cookies, etc - no effect. I’ve included Apache logs below - I’d really appreciate any insight

It doesn’t appear to affect operation at all, but when running the resize test as part of an image upload, I get the following error message:

Feeling pretty discouraged at the moment

My postdownloadscript works perfectly unless I use variables, at which point it no longer works. You can see a few of the things I’ve attempted and commented out. Even using ${postdownloadpath} doesn’t seem to work - I can only call my postdownload script if I specify the absolute path. My cabs are in /images/drivers/Win7/. So for the Optiplex 9020M, the location is /images/drivers/Win7/Optiplex 9020M/*.CAB - I’ve also tried Optiplex9020M - still doesn’t work. I’m on Rev 3606, Debian 7

The only things in /images/postdownloadscripts are fog.postdownload and driverinstall.sh. Permissions on both are 777

Contents of fog.postdownload:

#!/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>
#. ${postdownloadpath}driverinstall.sh
. /images/postdownloadscripts/driverinstall.sh

Contents of driverinstall.sh:

#!/bin/sh

#This script was adapted from Lee Rowlett's fog.drivers postdownload script (https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-$
#This script assumes your image has been modified to look in C:\Windows\Drivers in addition to the default location for Windows drivers (http://technet.microsoft.com/$
#Make sure this script is called from your fog.postdownload file by adding ${postdownloadpath}/driverinstall.sh to the /images/postdownloadscripts/fog.postdownload fi$
mkdir /ntfs &>/dev/null; #Create new directory called ntfs and supress any system or error messages
mount.ntfs-3g /dev/sda2 /ntfs; #Mount the NTFS Windows OS partition to the new ntfs directory
machine=`dmidecode -s system-product-name`; #Get the model name of the computer being imaged
#machine=$(dmidecode -s system-product-name)
#machine=$(echo $machine | tr -d ' ') #Remove the trailing spaces from the model info
#Get the OS version info and set it equal to the osn variable for later use
#if [ $osid == "5" ]; then
osn="Win7"
#elif [ $osid == "6" ]; then
#osn="Win8"
#elif [ $osid == "7" ]; then
#osn="Win8.1"
#fi
#osn="Win7"
mkdir /ntfs/Windows/Drivers &>/dev/null; #Create the C:\Windows\Drivers directory and supress any system or error messages
echo -e "Extracting Drivers..."; #Tell the user that FOG is extracting the drivers within C:\Windows\Drivers
#cabextract -d /ntfs/Windows/Drivers "/images/drivers/$osn/Optiplex9020M/9020M-Win7-A04-JG7GH.CAB" &>/dev/null;
cabextract -d /ntfs/Windows/Drivers "/images/drivers/$osn/$machine"/*.CAB &>/dev/null
echo -e "DONE!"; #Tell the user that FOG has finished copying the drivers and finish the imaging process

@Tom-Elliott said:

@ArchFan I don’t think so. Not on the server. The client/host during imaging or in the init process itself, yes, the server no.

Gotcha - I’ve had some other issues getting it to work as intended, so it probably wasn’t an issue after all. Thanks Tom

@cml said:

@ArchFan
Under: /images/postdownloadscripts/
Name: driverinstall.sh

Just make sure you call the script from fog.postdownload

${postdownloadpath}/driverinstall.sh

Shouldn’t entering echo ${postdownloadpath}/driverinstall.sh on the server output /images/postdownloadscripts/driverinstall.sh, or no? I was having some issues at first and ended up putting the absolute path to rule that out as an issue

@Lee-Rowlett said:

#!/bin/sh

ceol=tput el;
machine=dmidecode -s system-product-name;
machine=“${machine%”${machine##[![:space:]]}“}” #Removes Trailing Space
if [ $osid == “5” ]; then
osn=“Win7”
elif [ $osid == “6” ]; then
osn=“Win8”
elif [ $osid == “7” ]; then
osn=“Win8.1”
fi
dots “Downloading Drivers”;
mkdir /ntfs/Windows/DRV &>/dev/null;
echo -n “In Progress”;
cabextract -d /ntfs/Windows/DRV “/fog/Drivers/$osn/${machine}”/.CAB &>/dev/null;
echo -e “\b\b\b\b\b\b\b\b\b\b\b${ceol}Done”;
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

code above will do what you want - change the paths to match your environment or wherever you want to store the cabs but using code example above. you’d put a copy of the cab into /fog/Drivers/Win7/OptiPlex 7010 for example then it will extract the cab and drivers will be installed during sysprep… shouldn’t need any postscripts

@Lee-Rowlett - Where is it this script is supposed to be placed on the server and its name?

Unfortunately I just experienced the same error on rev 3494, same as OP - Wheezy 7.8 x64. Let me know if I can provide any logs or other info

I’d probably start by updating your undionly.kpxe file to the newest one Tom has on his website ([url]https://mastacontrola.com/ipxe/latest/[/url]) or trying another iPXE boot file and see if you can get one of the machines you’re having issues with to boot. Instructions can be found here: [url]http://www.fogproject.org/wiki/index.php/Building_undionly.kpxe#Use_other_undionly_or_ipxe_files[/url]. By default you’re probably using undionly.kpxe, but there are other files located in /tftpboot on the FOG server that you could try to see if that resolves the issue with other ROMs. I take the symbolic link approach for testing to avoid having to deal with the DHCP options. For example, to try booting undionly.kpxe.INTEL, you would:

[code]
cd /tftpboot
mv undionly.kpxe{,.ORIG}
ln -s undionly.kpxe.INTEL undionly.kpxe
[/code]

to go back to the original undionly.kpxe if none of the other files work, just do the following to revert the changes
[code]
rm undionly.kpxe
mv undionly.kpxe.ORIG undionly.kpxe
[/code]

You may find that there’s no common boot file that all machines will boot from, so things get complicated from there. It’s about experimenting to find out what works

Is this issue isolated to specific models of computers? And if they support (U)EFI booting, is Secure Boot off and legacy boot enabled?

[quote=“Simon33, post: 39125, member: 27154”]Oh, it’s a Netgear CG3100D-2 with an integral cable modem.[/quote]

I could be wrong, but I don’t see any way of getting PXE to work over that modem/router combo - they’re not really made to do PXE whereas business/commercial grade networking gear is. Is this just something you’re using at home? If so, you could create an isolated network where the FOG server handles DHCP for imaging and is connected directly to a switch. You can then just connect the machines you wish to image to the switch for imaging. Used commercial switches with gigabit ports (Cisco, etc) can be found on eBay - I picked up a D-Link DGS-1248T for ~$50 shipped. You’d have to connect the FOG server to the internet to run OS updates or upgrade FOG. Someone else may be able to help you with another solution

[url]http://www.fogproject.org/wiki/index.php/FOG_on_an_Isolated_Network[/url]