Chainloading Failed on All Models on 5 different servers

[Tom Elliott]

What is output if you go to:

http://10.10.31.25/fog/service/ipxe/boot.php?mac=<mac_address_ofsystem_registered> and press enter?

You’ll notice the syntax is nearly identical to @george1421 but this time implicitely calling what I imagine is the url data is being routed to.

If you can please also post the output of:

cat /tftpboot/default.ipxe

[Kris Phillips]

Tom,

My original post has the version. Its 5956. The “Version provided by this revision” is the FOG agent for the client PC’s I’m referring to. I didn’t figure it applied, since we’re talking about imaging and not the FOG agent.

The output of the HTTP request you gave me is what I posted earlier. Are you asking me to do it again or something with a different host?
I’ve looked at the command 2-3 times and it looks exactly the same as what was asked of me to post earlier.

Here is the output of my default.ipxe:

#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param product ${product}
param manufacturer ${product}
param ipxever ${version}
param filename ${filename}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain http://10.10.31.25/fog/service/ipxe/boot.php##params

[Wayne Workman]

@Kris-Phillips said in Chainloading Failed on All Models on 5 different servers:

If a machine doesn’t have a default image assigned to it, it gives the chainloading failed message. However, when I go into the host on the web UI and assign a default image to it, it no longer has this issue.

Because of that, I’m moving this to bug reports. Can @Moderators or @Testers confirm please? It should be simple and quick. I’m unable to at the moment.

[Tom Elliott]

@Wayne-Workman this is only happening because a task was created ?

[Tom Elliott]

You say in the latest version but you’re running 5956?

[Tom Elliott]

I’m assuming by “Version 5956” you’re referring to the SVN Revision number which would mean the version of FOG You’re running now is 1.3.0-RC-11.

That said, this should prevent further issues:

https://github.com/FOGProject/fogproject/commit/0c4e91464d340665feaea1bc2ffb7fc2ee5c2031

[Kris Phillips]

@Tom-Elliott Thanks! I’ll pull the latest SVN and see how it does. Should be able to report back on Monday whether this change fixes it or not.

[EDIT]

Just tried pulling from the SVN and it still says I’m on the current version. I’ll wait until Monday to try and pull again, as I’m assuming there is a bit of a delay in this getting pushed to the SVN.

[Tom Elliott]

@Kris-Phillips When I’m referring to working-RC-12 (Or any working for that matter), it’s not pushed immediately to the “base” repositories. This is because we’re in RC Cycles. So what I’m working on will not be just used for the whole. If you NEED to see this working, you can install but I’d recommend against it because the methodology in use is more or less an attempt to limit the confusion of how one person is working while another is not.

[Wayne Workman]

I just tried to confirm this bug, I am using RC-11 at home, I unassigned the image from a computer and then booted it up, it booted to the network fine and then exited to the HDD just fine.

I’m not doubting what you’re saying happened, but it’s probably something else. What else did you change besides the image?

[Kris Phillips]

@Wayne-Workman
Not sure how its working for you. I upgrades 5 different imaging servers and they all have the same problem. The only thing that I change is unassigning the image. I remove the default image, it breaks. I reassign it, it works again. I can replicated this several times with several different hosts. I’d be happy to dig if someone has any idea where it could be happening. We are working around it for now, though.