Posts made by JLE

Wireshark data posted privately. Some info about the data:
The problematic client is getting a dhcp address successfully of 10.241.96.20. (It says it for PXE and I can see it pop up on the DHCP server.)
I let the capture run from a computer right beside (also on the same vlan and switch) . The capture ran for two loops of “no configuration methods succeeded”. There are a lot of TCP retransmissions coming from the fog server.

To simplify matters early on I unplugged 3 of the members of the fog’s NIC team so it only has one right now and I am pretty sure the capture caught the tail end of a computer lab imaging.

I see the “malformed” dhcp packets, but I have no idea what is causing them… aside from laughing at their name I am reading up on the topic.

@george1421 Yeah, I know. I will still make that diagram outlining the problem as best I can and post it along with some wireshark data. I tried digging through some capture data following the dhcp discovery/offer/request/acknowledge and they were all there for client and all of the numbers looked good.

Sweet deal. I updated to the latest trunk build, set the boot file on the dhcp server to the 10 second ipxe.kpxe file and now everything boots.

Is there an easy way for me to adjust that delay? Say…make it 5 seconds?

Something else I noticed:

The computers that were continuously failing with “no configuration method succeeded” were filling up the DHCP lease with bad address entries…

I tried pinging those IPs from everything I could just to make sure they’re not static on something (nothing should be outside of the management vlan here).

Another weird thing is that now that I am using the 10s delay to boot they do not fill up the dhcp scope anymore with bad addresses. They even get the old IP that was otherwise “bad” in the previous case. ?.?

I checked on the switch’s config files. Portfast is enabled globally as is the spanning-tree mode (rapid-pvstp). I have found something else out that seems a little odd to me. On the machines that are giving this error, when it gets to the “hit s to enter the shell” part I can do that, give iPXE a static IP, and then ping the DHCP server just fine.

Also, while turning on one of these machines and watching in the DHCP leases on the server I can indeed see that it does create the lease - but the odd thing is that by the time it gets to “no configuration methods succeeded” the lease is gone from the server.

@george1421 I am going to put together a detailed diagram complete with configs and network info and maybe something will jump out. I’ll probably toss that up on Spiceworks too.

@george1421 Well we still have some kind of problem.

I am working with one machine now to try and solve it. It keeps getting the “no configuration methods succeeded message”. Placing the D-Link switch in between it and the cisco switch fixes the problem.

I traced the physical port back to the switch to be 100% and then logged in and check the settings. It is part of vlan 300 with the stp mode set to rpsvt. It has portfast enabled.

It definitely seems like the switch is taking too long. Portfast is supposed to immediately put the port into a state of forwarding according to everything I have read but this PC flies right through the menu with a D-Link switch in place…

To complicate matters, when the D-Link is not in place there isn’t a 100% failure rate - it succeeds some times.

Does anyone have any ideas on what I could check next? For the time being I am reading up on c2960x stacks and STP, but I am considering just turning it off completely on something. Maybe make a new VLAN, turn STP off for it, set the switches to it in order to deploy my images and then revert back to normal afterwards.

@george1421 Well, I think I have it figured out. Thanks for the kick in the right direction. The problem was apparently that the primary stp root for vlan 300 was a completely different switch in a different building. I set the main switch here in this building (where vlan 300 is anyways) to be the primary root and so far every one I’ve tested works. I am about to image a few labs so that will be the real test.

@george1421 Just put a little 5 port D-Link in place and rebooted the computer a few times. It has not failed yet. The computers in this room are connected to the second member of a 2960x cisco stack. The stack master has spanning-tree mode set to rapid. I guess I will try to make sure that each member also has the spanning-tree mode set that way? I thought that the master would set it for all.

I ran this command after it failed and am now trying to track down why there is such a high RXE value.

Server

• FOG Version:1.5.0-RC-2
  OS: CentOS 7

Client

• Service Version: 11.12
• OS: Windows 10

Description

Random computers give this error when you turn them on.
This is not an extremely pressing issue as a few reboot cycles always seems to fix it, but it would be nice to know what is causing it.

Here’s some info about the setup:
1.) All Dell Optiplex 990s
2.) All latest BIOS versions.
3.) All in the same LAN (vlan 300)
4.) All set to legacy boot with NIC at the top, then HDD
5.) Spanning-tree is set to rapid mode on all switches. (c2960x)

There seems to be no pattern to the error - the same computer can successfully boot and then the very next time give this error. Then you can restart that one and it will succeed the next time. This leads me to believe it might be something network related and not a FOG setting? Any ideas on what I could check?

@sebastian-roth Hmm. I definitely do not reinstall anything after sysprep. I run .\sysprep /generalize /oobe /unattend /shutdown and then capture. I have the fog service set to manual with recovery options set to restart it. After the images are deployed the batch file does a net start fogservice and then they join the domain.

I have custom slideshow backgrounds, screensaver, theme settings, specific programs installed, visual effects ‘adjusted to best performance’, specific services disabled, etc on my images and they apply to all future users.

Here is the process by which I do it:

1. Fresh install of Windows 10 (we use enterprise) I do this the very first time with the computer offline.
2. Once I am logged into windows as the default admin I then go to gpedit.msc and prevent the store from running so that no apps can update. (updating apps and the provisioning consequences were a massive pain for me so I just don’t mess with them)
3. Start customizing the profile how I want. Reconnect network.
4. Completely exhaust updates and install MAK key. Reboot a few times for good measure. Run chkdsk /f and then optimize the drive. Reboot a few more times. Also make sure that I’ve set power options like I want them.
5. Navigate to system32/sysprep, shift right click open elevated powershell
6. .\sysprep /generalize /oobe /unattend:<insert full path name to your unattend.xlm file here> /shutdown
7. Go queue a capture task up in FOG

I had this exact error message - also imaging windows 10 and also first time with new client, coming from legacy. For me this worked:

Through FOG GUI:
1.) Reset encryption data
2.) Put the FQDN in WITH the .net or whatever appendage (honeygroveisd.net) <-----works but -----> (honeygroveisd) did not.
3.) Clear out the OU container fields completely and leave it blank.

I made sure these settings were mirrored both in the group settings and in the global settings. After doing all of this it no longer gave me errors.

I highly doubt all of these were necessary but I was getting desperate

@defcon said in Unable to PXE boot on from different subnet:

On the subnet that is 10.80.x.x the Dell computer won’t PXE boot, but when I bring the computer physically on this network it boots just fine in PXE.

When you move this computer are you hooking it up to an entirely different switch? I recently ran into both of those errors you have posted a picture of. Here’s a checklist I’ve found that works for us:

Ip-helper address or dhcp-relays set up on each VLAN, and on each switch.
Spanning-Tree set to rapid-pvst (because of the switch model that we have.)
Portfast enabled.

Specifically with that bottom error I had to add all of the hosts to a new group (that I called Encryp Reset), go into the group general settings for that group - reset their encryption data. Deploy an image to the hosts again - got that same error again (no configuration methods succeeded) Then I rebooted the computer and upon the next cycle it worked just fine. I’ve had to do this maybe 50-60 times so far. Random Dell Optiplex 990s just seem to do it.

@Sebastian-Roth I changed the FOG server over to 255.255.240.0, the old subnet was from before vlans were implemented it just got passed over

Yep, that solved it. Routing was the whole problem. Option 3 on the DHCP server for Vlan 300 was indeed outside of the subnet for that scope. I pointed it to the SVI on the routing stack and everything is great. We now have FOG with vlans! Thanks guys.

Alright, I will check those IP settings on the different places on the fog server tomorrow. I will also move the fog server’s subnet to a /20 (which is where it is supposed to be based off it’s IP). I am amazed that so many pieces are working with it on the wrong subnet. I guess since FOG was on a larger /16 subnet and vlan 300 happen to be within a piece of it that some things worked.

@Sebastian-Roth When you say that “clients need to have a router address within their subnet” you just mean the ‘default gateway’ that’s handed out by the DHCP server right? Beyond that I would have no idea.

I will make this subnet change on the server and confirm the IP settings tomorrow and then report back.

I am at a loss.

Client’s info:
10.241.96.0/19 (Vlan 300)
DHCP tells these guys Option 66 (10.241.3.100) and Option 67 (undionly.kpxe)
These clients can ping the fog server, can get to the web console at the IP, can get through the fog boot menu - but show the above error when given an image task or when trying to register.

FOG Server info:
10.241.3.100/16
Single NIC with that above setting - I shut down the teaming to simplify for now.
Some values from the .fogsettings file:
ipaddress=10.241.3.100
routeraddress=10.241.3.9
dnsaddress=10.241.3.9

I am not even sure that dns address is important? Also I’ve seen a subnet field in other people’s .fogsettings but mine doesn’t even have one? Is that OK?

Should I set the routeraddress= to my dhcp/dns server (that is where it is now @ 10.241.3.9) – or should it be set to the switch stack that has IP routing enabled?

-Also I have disabled the firewall on the FOG server completely-

Server

• FOG Version: 1.5.0-RC-2
• OS: CentOS 7

I have been attacking this problem for awhile now but do not seem to be getting any closer to the solution. If any of you have any suggestions - I am willing to try them. I have attached an image at the very bottom describing the setup.

The problem is that I cannot image any computers that are not on the Native VLAN or on a Trunk port.
Spanning-tree mode is set to rapid, portfast is enabled on all links, and all vlans have an ip-helper address configured.
I can change the link between the client and the switch to Trunk or Native and fog will drop an image just fine.

I would like to get it working with vlans if possible – does anyone have it working in a multiple vlan environment?

Clients from any vlan can ping the fog server - but any client that isn’t on Native or a Trunk port will fail during an image (or registration) task with this error:

@george1421 Honestly I’m not sure. I did change it to ‘exit’ but then some computers were unable to start. GRUB, for whatever reason, is working with everything on the network. It is an all Dell network, various models from the 755 to 990 - all set up the same way.

Is there some other setting I would need to make after changing the FOG exit mode to ‘exit’?

Alright, figured out my issue. There is a setting under the BIOS that needed to be changed. Setting “Enable Boot Support” to off seems to have fixed the issue. With “Enable Boot Support” in the ON state, even with USB removed from the boot list iPXE was still exiting to the flashdrive. This was super frustrating because some of our document cameras double as a flashdrive. Screenshot attached of the BIOS setting.