Could not start download: Operation not supported

[george1421]

I’ve got the e6440 on my network and they deploy fine with FOG.

Not related to the e5440, make sure for dhcp option 66 you enter the IP ADDRESS of the fog server not the name. Some pxe boot loaders are pretty dumb and do not do dns resolution correctly.

It sounds like you entered the right value for dhcp option 67, that should be undionly.kpxe with no path or spaces on either side.

As for the system it sounds like you have that right too. Legacy mode, secure boot off and you need to enable the legacy rom.

[Sebastian Roth]

Tom’s hint on the “console” command playing up on this machine sounds like a pretty good guess to me. I had this just a couple of days ago…

[bmcgovern]

All,
Sorry about the delay in answer

@george1421 : It was set to the IP address of the server already.
@tom-elliott : I’m looking at the bootmenu.class.php file and I’ve found three instances of the word console it’s part of “consoleblank” for the first 2 and in the second it’s part of a print function. I’m fairly new to this, how do I comment out php files, and if it’s part of something else would I literally comment out just the part with console? Sorry for the total newb question.

[bmcgovern]

@wayne-workman

Here is the picture of error

[Sebastian Roth]

In PHP you use two slashes to comment. Should look like this (version 1.2.0 we are talking, right?!?):

                print "cpair --foreground 7 --background 2 2\n";
                //print "console --picture $this->booturl/ipxe/bg.png --left 100 --right 80\n";
                if (!$this->hiddenmenu)

BUT… Now that I see the error I changed my mind. As we don’t even see it sending a request to get default.ipxe via TFTP I really wonder if it’s a console issue. Are you able to download default.ipxe from your Windows client (same as you tried with undionly.kpxe)??

Ahh well. I just remembered that older versions of iPXE had issues with ‘spanning tree enabled’ switches. Sounds a bit like you are running into this here. Enable port fast setting for the client’s switch port and see if it makes any difference.

If not you can still go ahead, install tcpdump on your FOG server. Then start it up like this: tcpdump -i eth0 -w ipxe-issue.pcap. Then start your client and stop tcpdump with Ctrl+c as soon as you see the error. Upload the PCAP file and I will have a look.

[bmcgovern]

@Sebastian-Roth

Here is the pcap file I created.

https://www.dropbox.com/s/edh4595a609ly4j/ipxce-issue.pcap?dl=0

**Edit - Sorry that I couldn’t just upload it, no matter how fast I did it, the file is just to large to upload to the forum directly.

[Sebastian Roth]

Your DHCP setting seams kind of special! I see two DHCP servers answering the inital DHCP discovery from the client (x.y.32.10 and x.y.32.65). Only the first one is offering PXE filename and answers the DHCP request from the client with an ACK. Whereas both offer different IP addresses to the client. Just as a reminder, DHCP goes like this: Client: DHCP discover, server: DHCP offer, client: DHCP request, server: DHCP ACK. So what is x.y.32.65 doing??

This is the first DHCP communication from the clients PXE ROM. Then it properly downloads undionly.kpxe via TFTP which then goes for the next round of DHCP as it should. Again, both DHCP servers answer with an offer, client sends request but this time only x.x.32.65 sends an ACK (first round only x.x.32.10 did).

After that I don’t see any TFTP traffic. Probably iPXE got confused as x.x.32.65 is not offering PXE information (next-server, filename).

One possible solution would be to use the new iPXE binary which has a different script embedded and does not do the second round of DHCP on most machines:

cd /tftpboot
sudo mv undionly.kpxe undionly.kpxe.orig
wget -O undionly.kpxe "http://sourceforge.net/p/freeghost/code/HEAD/tree/trunk/packages/tftp/undionly.kpxe?format=raw"

Then try again. But anyway it would be wise to “cleanup” your environment and make sure about only one DHCP server answering or make them both offering the same information.

[bmcgovern]

@Sebastian-Roth

Thank you so much for having me download the new binary that seems to have gotten me into the FOG bootloader, if I’m really quick I can use it, however if I wait for more than a few seconds I get kicked out of it and get the message “Invalid partition table!” I was however able to register my first PC and i’m about to start creating an image of it. Any idea how I can keep it from erroring out though?

Again, thanks for all the help.

[Sebastian Roth]

You are welcome! AFAIK the default menu entry (registered or unregistered) is to boot from the local hard drive if there is no capture/deploy task scheduled for this host. There are different ways (called exit types) to go “back” and boot from the hard drive. In FOG 1.2.0 this can be configured (for all hosts) within FOG Configuration -> FOG Settings … sorry don’t have a 1.2.0 installation handy here right now but I am sure you’ll find it. Something about exit type with options like SAN, GRUB and another one. Just try different ones and see if it boots up your machine from HD properly.

Again: Why do you have two DHCP servers in your environment which both offer different IP addresses to the client(s)?? Is it windows server or ISC-dhcp? Why does only ever one seam to answer the DHCP requests while both jump in on DHCP discovery??

[Tom Elliott]

@Sebastian-Roth for help the three exit types were sanboot, grub, and exit. Sanboot is ipxe’s way of getting first hard drive which appears at bios memory address of 0x80. It’s not always a workable method, so the grub exit type was brought in which can find or use an HDD. In 1.2.0 it always assumes the first disk is hd0. Exit does what it sounds like, it exits back to the bios for handling what to boot next.