[SIZE=3][FONT=arial][COLOR=#222222]Missed a Step:[/COLOR][/FONT][/SIZE]
[SIZE=3][FONT=arial][COLOR=#222222][FONT=Tahoma][COLOR=#141414][SIZE=13px]Secure Boot > Disable, Apply[/SIZE][/COLOR][/FONT]
[FONT=Tahoma][COLOR=#141414][SIZE=13px]General > Advanced Boot Options > Enable Legacy[/SIZE][/COLOR][/FONT]
[FONT=Tahoma][COLOR=#141414][SIZE=13px]Exit, Restart, Re-Enter Bios[/SIZE][/COLOR][/FONT]
[FONT=Tahoma][COLOR=#141414][SIZE=13px]Boot Sequence > Switch to Legacy > Move NIC to top.[/SIZE][/COLOR][/FONT][/COLOR][/FONT][/SIZE]
[SIZE=3][FONT=arial][COLOR=#222222][FONT=Tahoma][COLOR=#141414][SIZE=13px]***System Configuration > Integrated NIC > Enabled with PXE[/SIZE][/COLOR][/FONT][/COLOR][/FONT][/SIZE]

Should have posted my notes to the bios as it took me a while to figure out how to switch the bios to legacy mode on the Opti 3010:

Secure Boot > Disable, Apply
General > Advanced Boot Options > Enable Legacy
Exit, Restart, Re-Enter Bios
Boot Sequence > Switch to Legacy > Move NIC to top.

Pat

Thanks for the help bishoptf.

The key to this for us on these 3010 was getting the GPT partition table switched to MSDOS using gparted. With that, I captured the image on both a 0.32 test fog server with bishops kernel, but also on our production 0.27 install (we still have 0.27 as we have it set up with a multi-subnet distributed fog storage config - there is some 0.31 component patched in, but I can’t remember what)…anyhow…the kernel on the 0.27 is an “older one” not sure what version. Kernel size is 4,606,848.

The 3010 Windows 8 image we’re deploying is ~30GB and the upload took just under 30 minutes on a 100 mbps switch.

Pat

@bishoptf - are you using the chainloading solution on the 3010s, or can you get successful pxe boot without that?

Thanks, Pat

Thanks for the update Stephen…interested to try it out.

Wondering where to start looking for my issue with this.

Right now I’m working at one of the “remote locations” (it’s summer vacation for the schools). I’ve uploaded a new image from a machine, but what I am finding is that the Upload process is pushing the image files over to the “main location”, however when I try to pull it down to another client with a “deploy”, the target client is looking for it here in the remote location.

In both cases, the hosts are configured to be at the “remote location”, but the image upload is not saving to the remote storage node. I can copy it easy enough, but I would like to save as much time as possible.

Is this by design? Or did I miss a step?

Thanks, Pat

As a tech support professional my self, I love it when people write back to say that they’ve solved their own problem:

apt-get install tftpd-hpa

I was wrong to assume that fog (0.31) was installing tftpd for me.

We now have fog joy once again!

Just an added note…

I do have a symlink set up for var/lib/tftpboot -> /tftpboot

Pat

Thanks Lee, that solved it, the next time I ran the rsync it worked.

Now this thread may take a turn, and not fit the category, but here goes.

This remote site: Ubuntu 10.10 on bare metal…seems to refuse to run tftpd. I’ve looked at various other threads and sites, and have concluded that:
ps ax | grep tftpd
should show me that the tftpd process is running (or perhaps in.tftpd) at any case I do not see it.
Further a command of:
tftp RemoteServerIP get pxelinux.0
From even a windows client, should cause a file transfer to initiate, but all I get is “Connect Request Failed”

From my understanding it is the fog install that installs / starts tftpd service, so I re-ran the setup. With the rsync command and tftpboot/pxelinux.0, re-running install throws error about that being in a read only state…so I umount, then re-run ./installfog.sh, but still no joy, I cannot connect to the tftp service, nor see a tftpd process running on my remote site.

What did I miss here?

Thanks, Pat

Hello - I’m working on re-implementing the “location patch” with Multiple TFTP servers for different lan segments.

When I get to this command on one of my remote nodes:

[CODE]$ rsync -rv 192.168.1.29::tftpboot/ /tftpboot

receiving file list … done
boot.txt
memdisk
pxelinux.0
vesamenu.c32
fog/bg.legacy.png
fog/bg.png
fog/images/init.gz
rsync: stat “/tftpboot/pxelinux.cfg” failed: Stale NFS file handle (116)
fog/kernel/bzImage
fog/memtest/memtest
pxelinux.cfg/

sent 39350 bytes received 26796 bytes 132292.00 bytes/sec
total size is 18179419 speedup is 274.84
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1526) [generator=3.0.7]
[/CODE]

I’ve done some searching for “Stale NFS file handle (116)” but not getting any clear answer to the issue.

Remote site: Ubuntu 10.10, Fog 0.31 on bare metal
Master: Ubuntu 8.04.3 LTS on ESXi

Where to start troubleshooting this one?

Thanks, Pat

Hey Lee - glad to see you are still active. Had to rebuild my setup her in Montana as my ESxi host ran into a disk controller problem and we weren’t able to salvage the drives…of course we didn’t have a backup…luckily though because of my year old install of this patch we had copies of all of the images on the 2 remote nodes.

Question is this, when you say “[B][SIZE=3]patched for 0.31” [/SIZE][/B]it sounds safe to assume that we don’t yet want to update to 0.32?

Stephen your Portable storage node sounds like a cool idea…we only use fog a couple of times a year so the effort of building a Fog storage node (even on a VM) at our remote sites seems like extra effort. May have to try it out.
Thanks, Pat