When I Multicast I See that the Status Percentage makes no sense. Does anyone know how to fix this?

Also, make sure rpcbind and nfs services are running. Through more searching, it sounds like it could be the NFS service isn’t running. Try running:

/etc/init.d/nfs restart

If it fails, check your rpcbind service and make sure it’s running.

Your commands may vary differently based on the OS you’re running the fog server from.

[quote=“darkapec, post: 14184, member: 11250”]Are you saying I should leave [CODE] ltsp/i386/boot/vmlinuz[/CODE] completely out or does that need to be replaced by something else?[/quote]

Yes, I think Your menu option should look like this:

[FONT=Consolas]LABEL LTSP
MENU LABEL LTSP 12.04 x32
KERNEL ltsp/i386/boot/linux.c32
APPEND initrd=ltsp/i386/boot/initrd.img ro quiet splash[/FONT]
[FONT=Consolas] [/FONT]
[FONT=Consolas]If that still doesn’t work, try:[/FONT]
[FONT=Consolas]LABEL LTSP
MENU LABEL LTSP 12.04 x32
KERNEL ltsp/i386/boot/vmlinuz
APPEND initrd=ltsp/i386/boot/initrd.img ro quiet splash[/FONT]

Is fog service running on the system? Double check that the fog client is installed and see if that helps you out.

Do do this go to the webpage:

[url]http://<your-fog-server-ip>/fog/client[/url] and download and install the client on the machine. Then try deploying the snap-in.

So I have been experimenting with limiting the TFTP block size to 1024 but I don’t think it is working. The way I am testing is this: I am observing a normal PXE boot with WireShark and looking at the size.

What I did in an attempt to limit the block size was this:

Edit [FONT=Times New Roman]/etc/default/tftpd-hpa and include [/FONT][FONT=Times New Roman]“-B 1024” under the OPTIONS line so the entire tftpd-hpa file looks like this:[/FONT]

[CODE]# /etc/default/tftpd-hpa

TFTP_USERNAME=“root”
TFTP_DIRECTORY=“/tftpboot”
TFTP_ADDRESS=“0.0.0.0:69”
TFTP_OPTIONS=“-s -B 1024”
[/CODE]

What am I missing?

I think it is a hash for the pass instead of displaying the real password.

The wrong pass was the same problem for me but not showing in the error you got.

Nice to know, that the problem is solved now 😉

Also, if it keeps being deployed, check your /tftpboot/pxelinux.cfg folder. If there are no tasks, you should only have the default file. Chances are, and I’m only guessing, you’ve got a file that is representing that system’s mac address in the format of 01-XX-XX-XX-XX-XX-XX where the X’s correspond with your systems mac address. Delete this file and you should no longer have this issue.

Thank you,

I’ve found that any time I’ve had the hdparm: ioctl 0x304 failed: Inappropriate ioctl for device issue, it’s not necessarily a driver issue, though it could very well be one. However, check your PXE file.

Make sure that the web part of the pxe server: does not look like this:
10.0.7.1/fog

Make sure you add the trailing slash otherwise you’ll see this issue.

On the same note, make sure your FOG Settings Page :
FOG Configuration (? Circle Icon) -> FOG Settings -> Web Server section -> Web Root also has the trailing slash as this is used to create the boot file for the hosts when tasks are setup.

Hopefully this helps.
[COLOR=#000000]10.0.7.1/fog/[/COLOR]

SOLVED: Changing the multicast queue size from 10 to an arbitrary number, then back to 10 corrected the issue.

Hi am_vd5,

Make sure that the disk to which you deploy the image is equal or greater in size as the disk from which you upload it.
The ideal situation is to prepare an image in the smallest disk you have so later you can deploy it to bigger disks, because if you prepare the image in a quite large disk you will not be able to deploy it to smaller disks.

Hi, surender!
The reason why you are getting that error is because PXE needs to extract the .iso to the physical memory, so if you don’t have enough memory it won’t work. In this case, you would need 3 Gb RAM to extract 2.7 Gb windows.iso.

[quote=“Blackbook, post: 14121, member: 2681”]Just revisited this - I set up a brand new ubuntu desktop and installed nothing but Fog on it - I reformatted the problem laptop and did nothing but put 1 txt document on desktop. I also reset the toshiba bios.

To check fog was working, I took a working laptop and did a quick host, an upload, and a deploy all successfully.

I then took the problem laptop, managed to get the PXE to boot to fog menu, did a ‘quick host’ first time, completed an upload (to a new image file) first time also, went to deploy it - and it got stuck at the same place as the video. Just dispays a ‘#’ when it should go to the blue screen.

I’m about to throw it all out the window.[/quote]

we had a problem child machine we just chose an older kernel for fog and magicly it worked… Our problem child was a Brand New Dell Vostro 2420 brand new out of box one Deployed fine the other we had to change to an older kernel to get to it deploy… Same Bios versions and Ethernet Firmware versions. Identical hardware. Go figure. we stepped back all the way to the 2637 kernel. Hope that helps?

Leroy check this thread out: [B][url]http://fogproject.org/forum/threads/ftp-connection-to-storage-server-has-failed.556/[/url] [/B]

if you upgraded to a recent revision of Ubuntu, you may need to manually start the service after a reboot.

The ESXi hosts that the virtual FOG server resides on are connected to a storage unit (15k disks with SSD cache) via multiple 10gbit iSCSI. The hosts connect back to the user network via multiple gigabit paths each. It is only FOG that has a problem with speeds, as other servers (Windows) are crazy quick. I’ve also used VMXnet3 as the adapter on the FOG server, enabling theoretical 10gig networking. There is no problem with downloading an image from the FOG server to a physical machine, only uploading from an ESXi virtual machine to the FOG server. Random.

Like James-Driver says, it is something to do with the drivers in the FOG kernel.

It’s still there, maybe someone with some expertise can help, I imagine a setting got wonked somewhere.

I just wanted to make sure you had the client installed and set up on the server for the actions 🙂