Hi Shaker, welcome to the forums!

It sounds like the integrated NIC on 3 of your newer motherboards are not compatible with the Fog kernels you are trying to use. Have you tried any of the 3.3 or 3.4 kernels?

The RTL8111 seems to use the same linux drivers as the RTL8168, and have been around since 2008, so a kernel somewhere should support them.

If not, you can customize your kernel for Fog by using steps similar to those I followed and documented in: [url]http://fogproject.org/forum/threads/compiling-a-custom-kernel-for-acer-iconia-tab-copied-from-old-forums.216/[/url]

If the configurator already has a section for the RTL8111 or RTL8168, then it’s as easy as overwriting the files in the source tree and recompiling the kernel.

I read an article about this today while troubleshooting some TFTP boot problems across subnets. The problem I think has to do with the VPN encapsulation pushing the packet size over the limit during the PXE tftp transfer.

Check out: [url]http://copilotco.com/mail-archives/ltsp.2008/msg00620.html[/url]

I’ll summarize the answer:
[QUOTE]It turns out that the whole issue was the block size of the tftp transfer. For some reason when transferring from a booted pc or a pxe LAN boot this is not an issue. However, when transferring during a VPN pxe boot it is. I have no idea why, but I had to use the -B option in my tftp line in inetd.conf and assign a block size of 1024. Once I restarted inetd the pxe VPN worked. Unfortunately it take over an hour to transfer the files and mount the file system. So…although the transfer problem has been fixed I am back to the drawing board with my LTSP deployment method.[/QUOTE]

I have updated the WIKI article: [url]http://www.fogproject.org/wiki/index.php/Clamav[/url]

I need to get back to school and verify the steps I took, but it’s enough to get you on the right track.

I’ve updated the WIKI article on using Fog + ProxyDHCP (LTSP and dnsmasq) with information on running across multiple subnets.

Hey everyone,

I’m wondering who out there has modified, customized, or expanded their Fog server setup so it’s not just out of box Fog.

Have you added more items to the boot menu? What can you boot to with Fog?

Have you changed the Web UI to be more helpful or have more tricks?

Did you modify the kernel or init to do something special?

Thanks for letting us know.

The options you choose depend on if you are trying to backup the entire mysql server, or just the Fog database.

Here is a pretty good tutorial: [url]http://www.thegeekstuff.com/2008/09/backup-and-restore-mysql-database-using-mysqldump/[/url]

Basics:
[B]backup:[/B][COLOR=#111111][FONT=Consolas] # mysqldump -u root -p[root_password] [database_name] > dumpfilename.sql[/FONT][/COLOR]
[B]restore:[/B][FONT=Consolas][COLOR=#111111]# mysql -u root -p[root_password] [database_name] < dumpfilename.sql[/COLOR][/FONT]

Single database:
[COLOR=#111111][FONT=Consolas]# mysqldump -u root -p[root_password] [database_name] > dumpfilename.sql[/FONT][/COLOR]

Multiple databases:
[COLOR=#111111][FONT=Consolas]# [B]mysqldump -u root -ptmppassword --databases database1 database2 > dumpfilename.sql[/B][/FONT][/COLOR]

Single Table:
[COLOR=#111111][FONT=Consolas]# [/FONT][/COLOR][B]mysqldump -u root -ptmppassword databasename tablename > /tmp/dumpfilename.sql[/B]

[quote=“Lonnie Gaither, post: 3683, member: 1189”]Thanks for the input Chad. That’s probably how I SHOULD have done it, but I basically just re-ran the setup so it would recreate the /tftpboot folder and contents. It basically kept all of my settings intact, except that I may have had to reset the main FOG user password.[B] The only other thing I had to do was update the Kernel, so I just installed the newest one (3.3.3) and all seems to be working fine[/B].

-=Lon=-[/quote]

would the bolded content have anything to do with your video changes?

have you tried to image in debug mode and see if you get more information?

Did you set the next-server and filename options in DHCP?

most likely. if you are going through a proxy or web filter, you might try using ftp, https, or sneakernet.

I just found the md5 hash info on the sourceforge download page. You have to click the cirlce with the [I]i [/I] in it to view details. the hash matches what I posted. You can check yours by doing
[CODE]md5sum fog_0.32.tar.gz[/CODE] and see what you get.

for my download: md5sum = 45b323d4150690b9c1aa8288c33830c9 fog_0.32.tar.gz

just try to gunzip it, then untar it.

[CODE]gunzip fog_0.32.tar.gz[/CODE]

should give you fog_0.32.tar file

[CODE]tar xzvf fog_0.32.tar[/CODE]

should untar to the current working directory.

did you FogCrypt your password?

For the default domain name, I use the fully qualified domain name (fqdn), ex: mydomain.com
I leave the OU blank.
For the user name, I use the netbios domain name, which is the same as the first part of the fqdn, but you can use the fqdn also, PLUS my domain name.
For the password, it’s the user’s password FogCrypted.

It works for windows xp and windows 7 pro 32 and 64 bit.

We are running Windows Server 2008 R2 as our domain controllers, if that makes any difference.

Export your database using mysqldump.
reinstall fog
import your database using mysql
That should get you mostly there. There might be a password somewhere that needs updating but wait until you get an error before you go changing anything.

silly question, but did you try to download the file again. Maybe your tarball is corrupt. check the size and if a MD5 hash is provided on the download site, you can check that also.

I have given up trying to get windows 7 to work with the resizable image type. I use the multiple partition - single disk. It still compresses the image and only stores actual data, so if a full load uses 70GB in windows, the image is around 50GB on the server.

according to Intel’s website, the Intel 82579LM gigabit LAN controller should use the e1000e driver in linux. I was scouting around the net and saw where the e1000e driver added support for the 82579LM chipset back in November of 2010. It might be worth downloading the driver source files from Intel and recompiling your kernel overwriting the old source files with the new ones.

I started to edit the clamav wiki article, but it wasn’t flowing right so I am trying to figure it out. Too busy with end of the school year stuff at the moment, but be patient and I’ll have some specifics up near the end of May/beginning of June

sounds like the kernel does not have the proper drivers for that network card. Have you tried a newer kernel through your kernel updates page? You can also try older kernels, and kitchensink kernels which have support for a wide array of devices.