That is actually not enabled. I guess I should have specified rebooting when there is a task, like changing the host name, or something. The reason I ask is that I logged in to some of my lab machines today to install some software that couldn’t be deployed. The machines all rebooted within a few minutes of logging in. The local Fog log showed that Fog was attempting to join the machines to the domain, but they had all been imaged 2 days ago.

Is it possible for a Fog task to get “stuck” in a queue? I read this thread: [url]http://fogproject.org/forum/threads/fog-client-weirdness.11942/#post-38669[/url] that seems to point in that direction. There have been many task false starts in the past week or two, where the task was cancelled before being completed.

Where does the actual mysql db for Fog reside?

Is there a setting somewhere to prevent Fog from rebooting a machine if there is a user currently logged in? I’ve looked and haven’t been able to find anything.

Thanks,

Many thanks, Tom. I’ll give it a try.

What is the link to that folder, Tom?

That looks like it did the trick, Tom. Tested with and without a task and it booted as expected. This will make the rest of the week (and semester) much easier. Many thanks.

Tom,

I would certainly appreciate your assistance. There are several more labs to image this week and entering the tftp server ip address on each machine multiple times is not ideal. The server address is 10.58.11.55. I am using the undionly.kpxe that you suggested last week (link above). Attached is a pic of the error message if the server is incorrectly entered.

This is puzzling to me, also, as this issue only cropped up once last week while I was testing various kernels and it wouldn’t boot anyway.

[url=“/_imported_xf_attachments/1/1602_IMG_20150112_170252892_HDR.jpg?:”]IMG_20150112_170252892_HDR.jpg[/url]

Fog 1.2 under Ubuntu 13.10 with a proxy dhcp server. After some tweaking, this install seems to be working perfectly with one exception. After the initial pxe boot, there is a prompt to enter the ip address of the tftp server (pic attached). Entering the address allows the boot process to continue.

This did not happen with the kernels we previously tested in Fog 1.2 or with any kernel in Fog .32.

I am using the [B]undionly.kpxe[/B] from [B][I][url]http://svn.code.sf.net/p/freeghost/code/trunk/packages/tftp[/url][/I][/B], as suggested by Tom Elliott. This boots our 790s and 7010s.

I’ve looked everywhere I can think of to plug in the server address, but to no avail. Below are some of the config files for the server.

Not sure where else to check. TE suggested building a custom undionly.kpxe, but I’d like to see about an easier solution, if one exists, before opening that can of worms.

All help/suggestions appreciated.

[U][B]default.ipxe[/B][/U]
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
params
param mac0 ${net0/mac}
param arch ${arch}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain [url]http://10.58.11.55/fog/service/ipxe/boot.php##params[/url]

[U][B]ltsp.conf[/B][/U]

if port=0 is not commented out, we lose internet connectivity on the fog server,

but all server functions work

port=0

log-dhcp

enable-tftp

tftp-root=/tftpboot
dhcp-boot=undionly.0,10.58.11.55

dhcp-option=17,/images

dhcp-option=vendor:PXEClient,6,2b

dhcp-no-override
pxe-prompt=“Press F8 for boot menu”, 3
pxe-service=X86PC, “Boot from network”, undionly

pxe-service=X86PC, “Boot from local hard disk”, 0

pxe-service=x86PC, “Install windows from RIS server”, 1

dhcp-range=10.58.11.55,proxy

dhcp-range=192.168.0.20,192.168.0.250,8h

dhcp-host=00:20:e0:3b:13:af,10.160.31.111,client111,infinite

[U][B]tftpd-hpa[/B][/U]
sleep 30

/etc/default/tftpd-hpa

FOG Modified version

TFTP_USERNAME=“root”
TFTP_DIRECTORY=“/tftpboot”
TFTP_ADDRESS=“10.58.11.55:69”
TFTP_OPTIONS=“-s”

[url=“/_imported_xf_attachments/1/1601_IMG_20150112_135614954_HDR.jpg?:”]IMG_20150112_135614954_HDR.jpg[/url]

Is it possible to roll my own using the kernel that is working for me now?

I tried the edit and restarting dnsmasq, but the tftp server prompt persists, even after several reboots. Should the change be immediately evident, or does it take some time?

Do any services need to be restarted after changing the ltsp.conf file?

We are using dnsmasq. The /etc/ltsp.conf file shows: “dhcp-boot=undionly.0,xx.xx.xx.xx”.

Tom,

I just tried the undionly.kpxe from the trunk files and it appears to work, except that I had to manually enter the tftp server address before the multicast would start. I’ve seen that with one other kernel I tried this morning. Any idea about that?

I downloaded the latest undionly.kpxe from [url]http://svn.code.sf.net/p/freeghost/code/tags/1.2.0/packages/tftp/[/url] and it SEEMS to be working on both the 790s and 7010s. Both types of machine will now boot to a task or the Fog menu reliably.

BUT there is another issue: When there is an active task, such as an image being deployed to one machine, no other machine, 790 or 7010, will boot past the /default.ipxe… (see pic) part of the process. They will error out right there until the task is completed, and then they will boot to the Fog menu. Any ideas about that?

[url=“/_imported_xf_attachments/1/1598_IMG_20150109_122017650.jpg?:”]IMG_20150109_122017650.jpg[/url]

I’m using Fog 1.2 on Ubuntu 13.10 with a proxy DHCP server. My Dell 790 machines will randomly error out (see pic) OR boot into a task. I tried to multicast to 6 machines last night: 3 of them errored out and 3 of them got to the grey download screen (2 had to be rebooted a couple of times because they errored out at first). I am using the undionly.kpxe.INTEL kernel right now.

[url=“/_imported_xf_attachments/1/1597_IMG_20150109_090943343.jpg?:”]IMG_20150109_090943343.jpg[/url]

Update:

I prepped and uploaded an image from another 790 after defragging and doing fixparts. This image is currently deploying to 790. Issue may be solved.

It was still doing the task completed too soon. This morning, just for fun, I deployed a 7010 image (these are working fine) to a 790. It is currently imaging as expected. This points to something wrong with the original 790 image. I’m not sure what to do to rectify this. The 790 image was created by doing a fresh install of Win 7 which wiped the partitions and formatted the disk before installation. What do you suggest?

Still no luck. After defragging, running chkdisk, running fixparts, and re-uploading, the image still won’t deploy. Any ideas on where to look next?

I had that problem yesterday (different problems today). Look in /var/www/fog/lib/fog for Config.class.php.

As for the freezing issue, I defragged the disk and then did an upload debug to run fixparts on the disk. I’m no expert, but that’s what worked for me.

First time I tried, it didn’t work. Did fixparts /dev/sda and wrote the new MBR. Uploaded image fine, but deployment did not work. Same issue as before with the task “completing” with no errors.

Going to try again and see if it works this time.

Thanks for the lightning-fast reply, Tom. Would that be doing the fixparts /dev/sda1 and then writing the MBR with ‘w’?