I have to be honest, it never occurred to me when I gave you the unattend.xml screenshot that you were missing the fog client from your builds… Couple of pieces of advice that I’m sure everyone will agree with to make life simple…

1. Use the FOG client… definitely use it… honestly it makes things sooooo easy to control from the FOG server then…

2. When you do use it, dont change a damn thing on it, you can turn off any of the functions server side from individual computers at will so just leave everything switched on.

3. When it asks for your server’s name or IP… just leave it blank and on your DNS server set up an alias for ‘fogserver’ to point to the real server name… that way when you come to upgrade your FOG server in the future, you dont need to mess about updating that on all your images. You simply modify the cname.

I’m going to try this out tomorrow, its a bit late in the day now to start getting into it so I’ll let you know how I get on. Thanks.

The files called by the mac addresses there… 01-etc-etc are individual machine names… If you have no active tasks in the task management window on the FOG page chances are they’ve somehow got stuck there. I had a problem like that myself that was simply resolved by deleting them. Dont delete the default file though or you wont see the menu ever again

Also check the pxelinux.cfg directory itself for odd or invalid permissions.

ls -l /tftpboot/pxelinux.*
should do it.

Just wondering if its anything to do with files being stuck in /tftpboot/pxelinux.cfg that cant be removed for some reason? Perhaps permissions changed on the directory or something like that. Perhaps I’m barking up the wrong tree, I dont know, but its the only thing that springs to mind at the moment…

Check /tftpboot/pxelinux.cfg for any other files other than ‘default’ and then check permissions of that directory… I use ubuntu 10.04 and fog 0.32, my permissions are as follows:

755 on the /tftpboot/pxelinux.cfg directory owned by fog:root
and 644 on /pxelinux.cfg/default owned by fog:root

I think you could simply put your commands into Microsoft-Windows-Shell-Setup_Neutral\FirstLogonCommands

I’ve included an image of my unattended.xml with the branch open for you to see.

[url=“/_imported_xf_attachments/0/302_Unattend.jpg?:”]Unattend.jpg[/url]

Does it help if you sysprep the image before you save it? I suspect that will fix the problems.

I think you’ll probably find that most of that is cached. Linux has a habit of using loads of ram for caching and then giving it back in chunks as needed. Perhaps someone with more of a grasp could explain it to you a little better… but I’m guessing that your RAM is probably not going to cause you and issues.

If you want to test that out though do some benchmarking with your images etc before and after dumping the cached memory… Try this simple little script I use on some of my servers for ejecting it…

#! /bin/bash
clear
echo MEM before cache clear up:
echo
free && sync && echo 3 > /proc/sys/vm/drop_caches
echo
echo MEM after cache clear up:
echo
free

Write the above into a text file with vi/nano/whatever and chmod +x the file then run. Sorry if that’s patronising in any way, I just dont know what level of experience you have.

I keep getting this occasionally as a machine images in the middle of the partition data delivery… anyone got any idea’s why this happens or how to avoid it?

It doesnt stop the build, it just makes the screen unreadable without special attention to details.

To give you specs etc… the server runs on Ubuntu 10.04LTS and it runs fog v0.32

The workstations all run SATA OCZ AGILITY2 SSDs on Intel chipsets.

Big fan of Dell I see… eurgh… but apart from that, really love this… do you plan on releasing the changes to us?

Just joking about the Dell stuff btw… kinda

Let us know what you come up with for the PXE boot menu wont you? I’m intrigued and interested in doing similar things.

There’s a right mixed bag of stuff going on here… hard to pinpoint problems of this nature. A thought did occur though as I was reading… what are the network interface cards on client end, and server end for that matter… and do you use any form of traffic management.

As a test, take a client machine and disable the onboard nic if thats what your using, and place in an alternative nic. Try to find one thats not the same chipset, purely so we can eliminate the nic as a cause. If the card in the server is the same you’ll need to change it also to test, and you’ll have to mess about with ip addresses etc in linux… but anyhow, should at very least eliminate it from possible causes. I have my suspicions that its not actually a software issue at least. The NICs is where I’d go looking first though.

So the disk is the common component here? You used it on the Dell and moved it to the new system when you tried that out?

To be honest, if you’re using only one disk to push images out and its a standard SATA3 drive, I’d be very surprised if you didnt see the data dip after a while, but its curious that when you stagger machines that it starts off well then dips on each. Is it dropping off at the same point no matter what machine or how many at once you’re trying to do? If thats the case I suspect the image is being cached as it would be normally in disk reads to RAM, and you’re hitting a limit somewhere… either with the drives ability to sustain pushing the data out, or the interface used etc…

Out of curiousity when you’re pushing an image out to machines, run top on the server and see what the processor is doing. Is it flat out?

From what I can see looking in /tftpboot/fog/kernel/bzImage the kernel version in the file says 2.6.39.1

I have never changed my default kernel since the original worked so well for me. Hope that helps.

You’d need to modify various things for that, probably best if someone who’s done it or uses fog like this helps.

From what I can see thinking about it, you’d need to make tftp recognise the second address as well as the first one, and you’d need to make sure your mysql and apache service was accessable from there too. I think its more of a linux service thing than actual fog. I’m sure its doable though. Sorry I cant be more specific or helpful but I’d rather let someone who can give you a conclusive answer take this one now we know what you’re trying to do

Not sure what you are trying to achieve. I do know that you can set a number of options during setup of fog initially… perhaps that’s what you are after? But you can pretty much just change settings in config.php anyhow to do that. Are you trying to simultaneously run more than one network adapter on different subnets or something?

Are you trying to configure a second interface on the system or do you already have that configured and want help with the fog side of things?

If its the former its probably better to get it listed in the linux problems section.

Anyhow, if its linux, it just needs configuring in the /etc/network/interfaces file and you can use vi or nano etc to edit that file.

Mine for instance contains:

The primary network interface

auto eth0
iface eth0 inet static
address 192.168.168.14
netmask 255.255.255.0
network 192.168.168.0
gateway 192.168.168.254
broadcast 192.168.168.255

Basically copy the config and repeat for eth1, eth2 etc for any additional cards. If you plan on putting a second IP on an already used card, the interface name would just become etth0:1 and so on.

Thats some real nice work there moss… great stuff. Love it.

As for the dhcp server issue with crossover cable… not tired this, but couldn’t you just configure it for a range of local ip’s and add the ethernet port as another scope? Wonder if that would be possible.

If you really want to use the RPi as a portable fog server and you can get it working, why do you really need their network? Just take a crossover cable out with you

Oh… I should add… for those of us who are old enough to have grown up in the 8 bit era of computing… doing this image with a RPi will feel like a 30 year leap back in time. You might also want to consider a tape recorder with a 300 baud interface

If I remember rightly, and I guess google/bing here is a good tool to use, I think udp port 7 needs opening between networks?

I dont think that the issue will be your network card being shared with other VMs as I have this setup and also a standalone fog storage server on a real platform that does nothing but fog. The storage node behaves the same way when in use. I wonder if its an ubuntu thing? Anyone with fog in use on another distro that would care to comment? Perhaps some of our redhat based friends? CentOS, Fedora etc?