Posts made by Ben Warfield

I’d like to believe that and it really does appear to be a network issue. But what I don’t understand is the issue started happening immediately after the update.

2 weeks ago I was on r2961 and imaged the lab without a problem. This week I updated to r3287 and this problem appears. Nothing else changed - no switch configurations, no dhcp server changes. The only variable that changed here is the revision of fog.

I think tomorrow I’ll fire up another virtual server and install r2961. I’d like to have that running and temporarily point dhcp option 66 to the new server just to (hopefully)prove or deny that the network is still functioning correctly. I’ll let you know what I find.

Test done - realtek.pxe and realtek.kpxe both do the same thing - link down, network starting, and then link up.

[QUOTE]Take one of the problem computers, move it to a known-good port in another part of the building. Preferably one that’s not connected to the same switch that the other 60 are on.[/QUOTE]

I did that earlier too, guess I forgot to mention that. Problem computer in Building A, moved to another room on another switch, same behavior.

[QUOTE]Grab a computer that works fine, one from another part of building A.
Take it to where those 60 machines are (the problem ones) and plug it in using one of their network ports.[/QUOTE]

I did try this earlier - that computer works fine on the same port as the problem computer. It’s so weird - like, everything points to it being a switch port issue, but then I take another machine to that same port and it’s okay.

[QUOTE]Also a thing to try is using the realtek.pxe file. There was an issue with rtl8169 cards with the eeprom that caused all kinds of weird issues.[/QUOTE]

I’ll give this a try hopefully soon. Both of those labs are full at the moment with classes.

I think we’ll need Tom to answer that one… I’m not sure what the relation is between all the *pxe files.

Yep - Here’s a TCPDump
[url]https://www.dropbox.com/s/exn3ol2ro9dhxad/FogDebugTask.pcap?dl=0[/url]

Fog Server: 10.162.1.212
Client loading debug task: 10.162.30.58

Two fog storage nodes at 10.162.1.71 and 10.162.1.72

[QUOTE]But these 60 machines having the same problem are behind the same point when they’re having the issue?[/QUOTE]

Yes. I’m just trying to think of anything else that may have changed… I haven’t logged into the switches in a long time, dhcp hasn’t been modified at all, anything else I might not be thinking of?

I just noticed something else… See the picture attached. It says starting network before the link is up. Seems a bit backwards to me, but is there a reason I’m missing?

[url=“/_imported_xf_attachments/1/1918_Debug.PNG?:”]Debug.PNG[/url]

No rogue DHCPs that I can see. I did a wireshark on a dhcp renewal and only got an offer from our known dhcp server.
The wireshark in debug mode really doesn’t show much, it’s mostly just TCP segments when it’s downloading the kernel.
I’m ruling out the patch cable because there are 60 machines with this same issue.

Hmm that’s a thought. I don’t have a hub, but I can set up a monitor session on the switch. Give me about 10 minutes and I’ll upload a capture file.

Right, that’s sort of what it looks like to me. It’s almost like it needs to grab an IP a second time before imaging and that’s where it fails.

All buildings share one common fog server. That server has been updated to the latest revison, so I can’t go back and check 2961 very easily. The computer in question is what I was moving back and forth. In building A, I have the problem where it doesn’t get the IP in the debug. I disconnect it, walk across the parking lot to building B, plug it back in, and it works perfectly.

Ok, new info - it might be/probably is a network issue on our end of things. The same style machine works in another building. So I took one machine from the problem lab to this other building and it works there as well.

Spanning tree portfast is enabled everywhere. But thinking this through now, I imaged that lab fine 3 weeks ago on SVN 2961 without issue. There haven’t been any changes on the network switches or anything as far as that goes. Is it possible that the timeout between link down and link up was shortened?

Here they are:

Video of debug task: [media=youtube]wOMm6Lmj7XI[/media]
Video of imaging task: [media=youtube]TUhRb1vYP7U[/media]

Sure. I have turned that on and see a whole lot of info fly by before it gets to [root@fogclient /]#
What specifically are you looking for, or is there a way for me to copy all that from the client and send to you?

Latest SVN still has the same issue

I’ll give it a try tomorrow when I’m back at work. Thanks!

They are a Lenovo M72e Tiny. The NIC is onboard.
I was on SVN 2961 before this and they worked fine there, if that gives you any reference point.

I don’t seem to be able to do much in debug mode either, the machine doesn’t get an IP and can’t talk to fog at that point.

Of interesting note while I’m in the client system info section… I chose option 2 for IP Information. My network adapter is named enp3s0 and there is no IP associated with it. And when I choose option 5 to ping a host, that fails with sendto: network is unreachable.
I’ll give the debug a go and see what I get.

It looks good.

This computer appears to be compatible with FOG
Network…Pass
Disk…Pass

I’ve got a weird issue going on. Fog SVN 3281, Ubuntu 12.04. Deploying an image works fine on most stations, but on a certain type of machine it never starts. I had to take a video of the screen and play it back to catch what’s going on because it happens to fast, but basically it gets to the screen where it’s checking things. It says Checking OS…Win7, checking cpu cores…2, Send method…NFS, Attempting to send Inventor… and then after that point, it does something that looks like you’re holding down the enter key. The screen is all black and there’s a white cursor in the bottom left hand corner. If I press a letter, I see it flash by and go up off the top of the screen - just as if I was holding enter in a terminal screen.

It definitely appears to be an issue with this certain group of machines as imaging works fine elsewhere. The only thing that comes to mind is to change the boot loader, so I’ve tried undionly.kpxe and undionly.kkpxe but they both exhibit the same behavior. I’m not even sure if that’s a good place to start, but thought it might be worth a try.

Any ideas?