Just updated to 1.1.1 due to other issues, I’ll retry on the newer build when i get a chance.

Hi guys,

I ran a 1.0.1 full registration w/ image task which failed. The issue that caused it had been fixed in a later release so i went ahead and updated to 1.1.1

Now my problem is as follows.

When i did the above registration task and it failed, it created a device in fog. That device cannot be removed, or edited (allows into edit but update never works, doesn’t even show the host name in there).

I tried entering the data for it manually, but it doesn’t work. Clicking update just takes it to a message that says “[FONT=Ubuntu][COLOR=#555555]No user history data found!” Clicking delete takes it to the remove page, where i hit remove and the following appears in the address bar, but nothing happens.[/COLOR][/FONT]

[FONT=Ubuntu][COLOR=#555555]http:\SERVERIP\fog/management/index.php?node=host&sub=delete&id=0[/COLOR][/FONT]

[FONT=Ubuntu][COLOR=#555555]Obviously, the registration task somehow created a device with no ID field in the database. Assuming that the page code uses that key field to perform the delete, it is unable to find the entry correctly.[/COLOR][/FONT]

[FONT=Ubuntu][COLOR=#555555]How can i get rid of this?[/COLOR][/FONT]

I’ve only been able to test it so far on 2 different models.

HP DC5750s = works
HP DC7900s = fails as described

Yes, i do get a download prompt.

It is set as memtest.bin

When trying to pull up Memtest from the 1.0.1 default boot menu the screen freezes at:

Loading boot sector… Booting…

Finally managed to get around to looking at those switches. Disabled Spanning Tree Protocol, and they now boot correctly.

Thanks Tom.

So, you’re saying that the issue would only appear when a PXE booting device using Undionly.kpxe is directly attached to a managed switch with STP enabled. And that adding an unmanaged, Non-STP switch as an intermediary between the PC and the managed switch can prevent the problem because iPXE communicates directly with the switch for DHCP? Therefore since the PC is not “directly” communicating with a switch that has STP enabled, there is less delay establishing a connection with the DHCP server.

Now, I will admit that i do notice a shorter time to pick up DHCP when i have the intermediary switch in place, but i never realized that switches had anything to do with DHCP packets and requests other than routing them to the correct ports.

I won’t be able to get on those switches until possibly friday due to our DR testing schedule, but i’ll be sure to let you know what happens. I know we haven’t done much if any customizing to those managed switches from their default state, so STP being enabled is certainly possible.

[quote=“Tom Elliott, post: 29104, member: 7271”]In reference to the “twirling” you’re experiencing, do your switches have STP enabled on them? Do you have an option for portfast on these switches?

Being connected to the 10/100 doesn’t really mean anything, it simply means it can receive the dhcp request from ipxe. If you take out all managed switches and connect directly to the FOG server, does all work as expected at 1gb?

This will let you know if it’s a 10/100->1000 problem. I run gig switches on all my tests, and don’t experience the boot loop issue. (BTW for all, the boot loop is intentional kind of).

Doing this won’t necessarily be easy, but I suppose, if you could for DHCP, connect your FOG Server, Client test system, and DHCP server to the same switch. Start off easy and use a “dummy” switch preferably rated for 1GB.

This will, again, determine if it’s truly the undionly OR if something’s on your network not sending the DHCP back in time.[/quote]

Hey Tom, I’ll see what i can do about running them all through a single unmanaged gigabit, but i doubt i’ll be able to do that without significant network disruption. Nearly everything runs through those 2 Dell powerconnects.

What i can do at the moment, is try an un-managed gigabit capable switch in place of the 10/100 C-net.
I’ll also have the Network admin check the managed switches for STP and portfast.

Keep in mind however this issue never came up while using .32.33 to image well over 100 pc’s this spring for our Win-7 roll out. We’ve had no changes to our network infrastructure since then. Those 100+ PC’s were loading through with no issues up until i updated FOG to 1.0.1 .

Appx 25 of the machines mentioned are in this office, i have not verified that all of the PC’s in this office are effected. I have not updated the DHCP PXE image name at our other 14 branch offices as of yet as that’s just way too many “OMG my computer won’t boot” phone calls every morning lol. Each office has it’s own subnet (10.X.0.x) and Local DHCP server.

All in all, i’ve imaged and installed 80 DC7900’s, and 80+ DC5750’s since january using fog .32 before the update with no issues like i’m describing here. A PXE\STP issue would have reared it’s ugly head already.

I’m certainly not complaining, Fog has already saved me hundreds of hours of work, lol, I just want to give you as much info as i can since i’ll be pretty busy today with DR testing.

When connected to the 10/100 switch everything functions as well as can be expected. They boot just fine right into the menu and then on to windows.

Not that it’s necessarily relevant yet, but it locks up at “loading boot sector… booting…” when trying to do a memtest. Let’s not trouble Tom with other issues here until we can get everyone to the menu first

However bump up the speed to 1gb, (by removing the 10/100 switch) and it, picks up DHCP, goes to configuring, twirls there for a bit, then flashes an error message which i can’t read, because it instantly reboots.