Posts made by Mastriani

@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.

@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.

@Tom-Elliott said in Using dumb switch to troubleshoot imaging, network related:

@Mastriani The UDP issues might have come up due to 0.29. The NFS mount was not using the TCP proto (of which it does now).

Mr. Elliott,

Does FOG use jumbo frames? Fixed rate, negotiated, or not relevant?

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

@Mastriani When you’re ready, send me an IM. The forums are too slow for this sort of help.

FOG server is Ubuntu 14.04 LTS, match version on disc, or not relevant?

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

I’ll also be looking at some of the same stuff that George already touched on. And I’ll of course be using the same “near to far” thing he was talking about, this is just how to properly troubleshoot.

iperf and ethtool installed on FOG server, temporary interruption for educator request, will setup the laptop on the same switch with live disc, shortly.

@george1421 said in Using dumb switch to troubleshoot imaging, network related:

@Mastriani Well the 755 to 390s are not the most powerful systems but they should not take 30 minutes to image either.

When you run you test, please try to get an accurate time to deploy and the actual image size. That way we can calculate the true throughput. The number from part clone is a bit deceiving.

The compression value is a scale from 0 (no compression) to 9 (maximum compression). That also means:
0 = maximum file size on the FOG server and over the network but images faster since the client doesn’t need to decompress the image.
9 = smaller file size on the FOG server and network but images slower since the client must squeeze all of the air possible out of the image to capture and deploy it.

5 is a middle of the road between larger file and higher cpu requirements on the client.

FOG server and client machine on same switch. Image capture started at 10:28 a.m. EDT
Dell OptiPlex 780
Dual Core
4Gb PC3 DDR RAM
GbE Broadcom NIC, 1 Gb/s as per device manager
34.3 Gb image
Started: 2.8 Gb/s, 10 mins. into capture, speed degraded to 1 Gb/s, 11%, if the partclone measurement is believable.
20 mins, 620Mb/s, 18%
30 mins, 450Mb/s, 39%
40 mins, 395Mb/s, 49%
50 mins, 325Mb/s, 57%
60 mins, 315Mb/s, 61%
70 mins, 295Mb/s, 65%
80 mins, 272Mb/s, 69%
90 mins, 261Mb/s, 72%
100 mins, 250Mb/s, 77%
110 mins, 237Mb/s, 81%
120 mins, 223Mb/s, 88%
130 mins, 215Mb/s, 93%
140 mins, 222Mb/s, 97%
148 mins, 209Mb/s, 100%
Total time: 2 hr, 31 mins, 34.3 Gbs transferred, 12:59 p.m. EDT

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

I’ll also be looking at some of the same stuff that George already touched on. And I’ll of course be using the same “near to far” thing he was talking about, this is just how to properly troubleshoot.

I will most certainly appreciate the learning process and your time.

@Tom-Elliott said in Using dumb switch to troubleshoot imaging, network related:

@Mastriani The UDP issues might have come up due to 0.29. The NFS mount was not using the TCP proto (of which it does now).

The current servers are clean install of FOG 1.0.2 / Ubuntu 14.04 LTS, because other members of the team had targeted the old server as being the issue, as opposed to the change-over of network hardware. It was a post hoc ergo propter hock situation, having also migrated from FOG .32 / Ubuntu 10.04 to FOG 1.0.1 / Ubuntu 12.04. This was done during the network hardware change-over.

I doubted the correlation as causation, the only issue with 12.04, (appears to be fairly common), was installing the Unity desktop environment. Which was later removed and replaced with LXDE, preferable to my mind.

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

@Mastriani Stop down-talking yourself.

apt-get install iperf ethtool -y

apt-get is Ubuntu’s preferred package manager. There is also apt and dpkg

install is one of many commands to do. There is also remove and others.

iperf and ethtool are package names.

-y means do whatever needs done to just install it and don’t ask for permission, this is my permission here.

Fedora 24’s package manager is dnf but the rest is the same. In CentOS 7, it’s yum. In Arch Linux, it’s pacman

Objectively, better down than up, and this is 3 years of frustration speaking, having attempted to learn and resolve this solo. I will post back when the necessary conditions have been met. Thank you.

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

There is no need to reformat. You can use a Live Linux disk, meaning you boot from a CD or USB drive, and run the OS completely from that, without ever changing the contents of your local HDD. See this for more information: https://www.ubuntu.com/download/desktop/try-ubuntu-before-you-install

Now a days I default to using Linux to solve any sort of problem that isn’t specifically a Windows problem, just because I’ve become so accustomed to the tools available to Linux. If you’re into high quality Information Technology / Computer Science software at a low price, Linux IS the literal jackpot.

Thank you Mr. Workman, understood. I will burn a disc in the morning. Because of my ignorance, how then do I “install” iperf and ethtool functionally, or is this all accomplished via virtual environment? Yes, my moron is showing currently.

@george1421 said in Using dumb switch to troubleshoot imaging, network related:

igmp snooping is only used if you are using multicasting. We are only talking about unicast image deployment, Right?

Yes, unicast only, the IGMP comment was just for reference. I am attempting to be as inclusive as possible with anything that your team might deem relevant, or not and helping to refine the possible scope.