@Wayne-Workman said in Using dumb switch to troubleshoot imaging, network related:

This was due to a known issue with the onboard NIC chipset the server had.

@Mastriani could you post the chipset model please? I forgot what it was.

Both of the Broadcom NIC’s used in Dell servers are an issue, what is now known thanks to your workup on my server Mr. Workman.

Broadcom NetXtreme 5721 Single Port Gigabit Ethernet NIC, is what is in mine.

Hands down, Fog, it’s development team and support professionals, are inarguably in a class of their own. My sincerest thanks and professional appreciation to all, Mr. Elliott, and a note of exceptional knowledge and top class support and effort to Mr. Workman.

There is in my estimation, none better. Were it that others in the IT community would take lessons from your organization and team. Well done.

@Wayne-Workman said in Using dumb switch to troubleshoot imaging, network related:

@Mastriani So, you put in another NIC, configured it, disabled the others, and the issue is solved?

Currently capturing a 40Gb image, total time less than 17 mins.

Yesterday, updated 2 labs of 30 machines each, in 2:45:00, from start to finish.

The Trunk version is smooth, intuitively easy, and scorching fast. All is well for a small rural district in SE Tennessee!

Well, except that it is SE Tennessee.

@Joseph-Hales Thank you sir, yes, it would appear that may be a best practice that has to be instated. Even though I regularly update images, at no more than 2 month cycle, it shouldn’t add much extra work to the process in total.

@Tom-Elliott Yes sir, I was just looking at that, having trouble understanding how it is utilized, unless it is a boot CD/DVD?

@george1421 That is massively appreciated, especially considering my lack of authority to control the environments for my equipment. Thank you very much sir, that is very much needed.

@Tom-Elliott

1. Came in, restarted UPS, checked status, gave it 2 hours to restore levels, in case of further outage. We still have crews working in county and 4 surrounding, likely will have more down.

2. Started Win DC, locked in boot options reboot cycle. Started hardware diagnostics, letting it go.

3. Started Ubuntu/Fog server, locked at lost/corrupted mbr message. Attempted 1 restart in case of anomalous behavior. Same outcome.

4. Ran the Ubuntu live CD, could not even mount sda1, (•sudo mount /dev/sda1 /mnt). Tried Boot-Repair, same outcome. “Assumed” it was pointless to go for more utilities/attempts … ?

@Tom-Elliott Thank you Mr. Elliott, I am not familiar with the operation of dd-rescue? Something you can link me to perhaps?

@Quazz Thank you, currently running diagnostics for RAM/RAID consistency, so I am thinking towards the next step.

Obviously, if the data isn’t retrievable, it’s an all new install of everything and level 0 start over. Hope that isn’t the outcome, so trying to plan for a better scenario.

@george1421 Thank you sir, yes I understand. It would be from a new drive with a new install of Ubuntu server.

I am looking for a best practices methodology to ensure my activities do not add to possibility of further corruption/damage.

@Tom-Elliott Thank you Mr. Elliott, and things to understand.

In a school district in a rural, morbidly economically depressed county.

Local electric cooperative is “good ole boy” style, and having had some investigation done, our “general” electrical delivery is off standard by 5 - 12% as a rule of operation, (ie. on 110 circuit, actually voltage can range 89 - 105 at any time tested). I definitely agree, it is a “shouldn’t ever happen” scenario, but dirty electric delivery shouldn’t ever happen either.

I have done what I can do with the available UPS and as much separation between mission critical devices and standard use, but there are quite simply too many things outside my domain and “above my pay grade”.

If I can recover the data, is there a best practices methodology you suggest?

Short run: in one of the states hammered over the weekend. Local substation must have superspiked/surged; Win DC, Fog, client machines are all showing corrupted/damaged/lost mbr, none fixable so far. Tried everything suggested Linux/Ubuntu for mbr fix/recovery, nothing but errors and no fix found.

So, if I pull the drive from the Fog server, drop it in a USB enclosure, is it possible to retrieve the images and import to the server with a fresh install? Inclusive of image definition files?

Or, am I clueless and it cannot be done?

@Wayne-Workman said in Using dumb switch to troubleshoot imaging, network related:

@Mastriani So, you put in another NIC, configured it, disabled the others, and the issue is solved?

Currently capturing a 40Gb image, total time less than 17 mins.

Yesterday, updated 2 labs of 30 machines each, in 2:45:00, from start to finish.

The Trunk version is smooth, intuitively easy, and scorching fast. All is well for a small rural district in SE Tennessee!

Well, except that it is SE Tennessee.