Thanks Tom, this does appear credible and test is in order; will provide feedback:

[CODE]ip dhcp pool <name>
network <ip of network> <subnet mask>
bootfile BStrap\X86pc\BStrap.0
next-server <ip of PXE Server>
default-router <network default gateway>
netbios-name-server <one or more ip adresses>
option 43 hex <hex values obtained from PXE Forced Mode Utility>
option 66 ascii “name of PXE Server”
option 60 ascii “PXEClient”
dns-server <one or more ip addresses>
option 150 <ip of PXE Server>
domain-name <domain name>
[/CODE]

[FONT=Arial][COLOR=#333333]Hi everyone,[/COLOR][/FONT]
[FONT=Arial][COLOR=#333333]This is defenitely NOT a FOG problem but I hoped someone here may have faced the same issue. Fine the IOS can’t accept raw option 67 specified directly as part of the scope configuration with the name of the boot file and instead TAC suggests to use “bootfile xxx.bin” to do the same thing but it is NOT the same!! Please![/COLOR][/FONT]
[FONT=Arial][COLOR=#333333] You will see one Microsoft and one Cisco examples attached.[/COLOR][/FONT]
[FONT=Arial][COLOR=#333333]Hello? Option 67 is missing on the Cisco side; yes the bootfile is present with a correct value but PXE booting clients need option 67 in order to extract the name of the file to be used during the TFTP bootstrap process.[/COLOR][/FONT]
[FONT=Arial][COLOR=#333333]So what is the conclusion here? That no one can use Cisco’s IOS implementation of DHCP server in order to properly bootstrap PXE clients? Do tell me that I missed something
[/COLOR][/FONT]
[FONT=Arial][COLOR=#333333]Thank you everyone! [/COLOR][/FONT]
[FONT=Arial][COLOR=#333333][ATTACH]1643[/ATTACH][ATTACH]1644[/ATTACH] [/COLOR][/FONT]

[url=“/_imported_xf_attachments/1/1643_cisco-dhcp.png?:”]cisco-dhcp.png[/url][url=“/_imported_xf_attachments/1/1644_microsoft-dhcp.png?:”]microsoft-dhcp.png[/url]

worked for me; here is the line:

[CODE]date.timezone = America/Los_Angeles[/CODE]

No go with undionly.kpxe on HP Desk Pro 400 G1 - Core i5; part number J6D33UT#ABA. PXE boot get’s stuck at “configuring …” and after about 20 seconds the PC reboots.

[url=“/_imported_xf_attachments/1/1618_2015-01-21 12.19.13.jpg?:”]2015-01-21 12.19.13.jpg[/url]

Working with both undionly.kpxe and undionly.kkpxe; FOG 1.2.0 stock kernel; HP Pro Book 4510s part FN068UT#ABA

FYI: undionly.kkpxe worked for me on HP Pro Book 4520s part WH333UT#ABA. I was getting the iPXE initializing stuck message with undionly.kpxe

Phew I was hoping for an answer like that! Thank you Wolfbane8653!

Hi everyone,

I noticed that now FOG 1.2.0 uses Partclone 0.2.69; does that mean one must redo all prior images? (I am hoping here the answer is no because that will lock us into FOG 0.x pretty much forever)

It used to be that before 1.x one can simply copy the images from the old FOG server; then copy the images table and voila – all worked very well.

Is that no longer possible?

When I say copy the images I mean grab each image directory and rsync it onto the new physical FOG server /images directory:

[CODE]total 12520888
-rwxrwxrwx 1 root root 512 Mar 28 2012 d1.mbr
-rwxrwxrwx 1 root root 8519124 Mar 28 2012 d1p1.img
-rwxrwxrwx 1 root root 12812860149 Mar 28 2012 d1p2.img
[/CODE]

[quote=“panthersfan25, post: 32133, member: 24585”]They are identical computers, set up exactly the same from top to bottom. I did notice that on the web management the [SIZE=4][B]bandwidth meter[/B][/SIZE] on the receiving end is really bouncing around from around 11 to 0 back to 11 back to 0 and I checked the eth0 drops and it is showing 45405, that seems extremely high, could that be causing the issue maybe a corrupted image?[/quote]

I also noticed an issue with Bandwidth – mine doesn’t show any activity at all. I am running 1.2.0

Yes it is. I did testing with local tftp in order to eliminate that variable and further discovered that NFS copy, too has a major performance issue. I couldn’t find your e-mail address ping me off-site and would love to setup VPN sites (I have spare ASAs laying around) and we can have a decent test bed.

Hi everyone,

While back there was a long discussion about one’s inability to use FOG across VPN connected sites and ultimately it had to do with the tftp implementation and packet size; clearly a networking issue. Suggestions were circulated as to adjust the tftp server largest block size (at daemon start-up command line parameters) but I don’t believe an official remedy was ever achieved (do correct me if I am wrong here).

So I wanted to ping the community to see whether this issue is possibly no longer a problem with the newest version of FOG or whether a concrete remedy was discovered?

Thank you

Thx [SIZE=12px]Junkhacker; I’m on 0.32 in this case; after some testing I think the message “compression level…” may not be credible; if when it says NONE the imager clearly uses compression since the final *.img file is nowhere near the actual partition used up space. Could there be some truth to that?[/SIZE]

Hi Tom, so on another install I did follow the guide above; now the begining of the file looks like this:

[CODE]#!/bin/sh

PIGZ_COMP=“-9”;
RUN_CHKDSK=“”;
HOSTNAME_EARLY=“0”;
[/CODE]

However during an upload the blue screen still says Compression level… None

Is there another place to enable compression per-se which is an independent setting from the level of compression?

Thx

Works! Thank you very much!

Hi everyone,

Is it me or am I using an old SVN:

svn checkout svn://svn.code.sf.net/p/freeghost/code/trunk

I get “svn: generic failure”

I tried from two separate Ubuntu boxes. I am using svn, version 1.6.17 (r1128011)
compiled Jun 26 2013, 20:44:02
Thanks
~B

Thanks Tom, where is
[QUOTE]FOG Boot Settings tab in FOG Settings[/QUOTE]

Apologies if this is a stupid question; I will be happy to post screen shot. I am running 0.32

On image compression I found this super helpful post:

[SIZE=4][B][COLOR=#3b3b3b][FONT=League Gothic][SIZE=35px][URL=‘http://uberamd.com/post/22125061841/disable-gzip-image-compression-in-fog-for-faster-image’][COLOR=#0581d2]Disable GZIP Image Compression in FOG for Faster Image Creation[/COLOR][/URL][/SIZE][/FONT][/COLOR][/B][/SIZE]

[FONT=Helvetica Neue][COLOR=#333333]Recently I changed the software the imaging server at work uses from Clonezilla to FOG. There were many reasons for the change such as a better web interface, image deployment queue, etc however one of the main things I was looking forward to was storage nodes which allows for distribution of images across multiple servers to extend storage.

Deploying the FOG server was easy enough, however one of the first things I noticed was that image creation (uploading a new image to the server) was incredibly slow in comparison to image deployment. Image creation would take nearly 2 hours while image deployment would take about 25 minutes. This frustrated me to no end as we were doing this over gigabit and it wasn’t utilizing hardly any of the pipe on image creation. A quick glance at the screen told me why: FOG automatically assumes you want to GZIP the image. This means a smaller image, but a drastically increased image creation time since the system needs to compress the data it is sending.

I searched high and low through the config files for a way to disable GZIP compression, but found nothing. Eventually I figured out how to disable the compression, however doing so was not well documented at all. Enter this post which will hopefully help others solve the same problem I ran into.

Simply follow these steps (type these commands in your Linux terminal, you may need to be root or sudo to run some of these):

[FONT=Courier New]cp /tftpboot/fog/images/init.gz /tmp/init.gz
cd /tmp
gunzip init.gz
mkdir tmpMnt
mount -o loop /tmp/init /tmp/tmpMnt[/FONT]

Now using your favorite linux command line editor open the file /tmp/tmpMnt/bin/fog and find and replace all instances of -z1 with -z0. To do that with VIM do the following:

[FONT=Courier New]vim /tmp/tmpMnt/bin/fog
:%s/z1/z0/
:wq[/FONT]

Once you have replaced all -z1 with -z0 we need to recompress and replace your old init.gz file:

[FONT=Courier New]cd /tmp
umount /tmp/tmpMnt
gzip -9 init
cp /tftpboot/fog/images/init.gz /tftpboot/fog/images/init.gz.old
cp -f init.gz /tftpboot/fog/images/init.gz[/FONT]

Thats it. Now you have disabled compression upon image creation and you should notice a VERY large drop in image creation time! FOG does provide a script that assists in editing the init.gz file, HOWEVER the script requires you to have Nautilus installed (aka GNOME) and how many people really run a GUI on a server? Not many.[/COLOR][/FONT]

Yes it did; thank you!

I back all of the images to another FOG server using rsync; worked very well via crontabs

[CODE]sudo rsync -azvv -e ssh root@192.168.248.113:/images/HP* /images/[/CODE]

You have to ssh at least ONCE to the source FOG so that the certificate gets added; then it works with no interaction

My bad; collecting the info you asked for and will post detailed version on both